Free Surface Ship Flow

romainRH · April 10, 2015, 01:57

Well, as far as i understand local time stepping theory/algorithm, it is not possible to use it for any unsteady simulation (for now...)

Also which version of Foam are you using. Last time i checked it was not possible to run simulation with both waves and forward speed. Am i wrong ?

jojosaxo · April 21, 2015, 05:02

Sorry to come back again on this thread, I still have lot of issue with my calculations.
I try to simulate flow aroudn a ship hull with LTSInterFoam, everything looks find and stable and it suddenly diverges (see forces plot attached)
I'm using the fv Schemes and fvSolution files from the DTCHull tutorial. I've studied the BC wich are very close to those used in this tutorial.

What looks weird in the velocity fields is that I have high velocity spot close to the free surface at the bow of the boat and behind the boat (just abve the free surface).
Any hints to solve this????

Regards
Jordan

Sachin m · April 21, 2015, 08:34

romainRH,

I am using OpenFoam 2.3.1

jojosaxo · July 23, 2015, 07:58

Hi,
I have now issue with a DTMB5415 test case. I have made some test with relatively good results but I encounter some weird wave fields at low froud number.
I have unwanted wave in my domain. I tried to increase domain size, change BC, no real effect. I think I have reflexion of the waves downstream the hull, but what is really weird is the sort of wave I have in front of the boat (see attached pictures). I'm solving this problem with interFoam, so no fluid structure interaction. I attached two different set of BC if someone want have a look and tell me if anything is completely wrong about that.

Has anyone got the same problem? Or an idea o solve this?

Thanks a lot !!!

CFD-Palma · July 23, 2015, 15:54

Hi Jojosaxo,

I do not know if this will help, but when I had similar problems it was a matter of mesh.

Also, the interface from coarse to fine (refined) generates waves, I suggest using multi grading to avoid this effect.

Good lack,
Carlos.

jojosaxo · July 24, 2015, 03:10

Hi!
Thank you for your help! How did you solve this from a matter of mesh?
Here is a screenshot of the mesh at the level of the free surface! How would you change it?

gigliagarf · January 3, 2016, 10:32

Hello,

I've been working through learning about the DTChull case. I am trying to get volume refinements at the bow and transom and have surface refinement around the kelvin wake. I have created two searchablebox geometries and an stl file of the triangular kelvin wake. In addition I have the free surface refinement of the original DTCHull example, that I have adapted to fit my domain and water depth. It keeps throwing me errors. Is there something I should be doing differently? Should I be making the bow and transom refinements as stl and trim out the part of the bow that intersects the hull? How can I get these refinements to play nicely with each other? Does anyone have any tricks to getting intersecting refinement regions to work?

Thank you for your help!

/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2.4.0 |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object snappyHexMeshDict;
}

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

// Which of the steps to run
castellatedMesh true;
snap true;
addLayers true;

// Geometry. Definition of all surfaces. All surfaces are of class
// searchableSurface.
// Surfaces are used
// - to specify refinement for any mesh cell intersecting it
// - to specify refinement for any mesh cell inside/outside/near
// - to 'snap' the mesh boundary to the surface
geometry
{
DTC-scaled.stl
{
type triSurfaceMesh;
name hull;

patchInfo
{
type wall;
}
}
Kelvin-Wake.stl
{
type triSurfaceMesh;
name kelvin;

patchInfo
{
type wall;
}
}
bowrefinementBox
{
type searchableBox;
min (7.18401 -1 -0.149903);
max (10.0931 1 0.662375);
}
transomrefinementBox
{
type searchableBox;
min (-0.509046 -1.18756 -0.0440771);
max (1.71845 1.18756 0.475878);
}
};

// Settings for the castellatedMesh generation.
castellatedMeshControls
{

// Refinement parameters
// ~~~~~~~~~~~~~~~~~~~~~

// If local number of cells is >= maxLocalCells on any processor
// switches from from refinement followed by balancing
// (current method) to (weighted) balancing before refinement.
maxLocalCells 500000;

// Overall cell limit (approximately). Refinement will stop immediately
// upon reaching this number so a refinement level might not complete.
// Note that this is the number of cells before removing the part which
// is not 'visible' from the keepPoint. The final number of cells might
// actually be a lot less.
maxGlobalCells 2000000;

// The surface refinement loop might spend lots of iterations refining just a
// few cells. This setting will cause refinement to stop if <= minimumRefine
// are selected for refinement. Note: it will at least do one iteration
// (unless the number of cells to refine is 0)
minRefinementCells 0;

// Number of buffer layers between different levels.
// 1 means normal 2:1 refinement restriction, larger means slower
// refinement.
nCellsBetweenLevels 3;

// Explicit feature edge refinement
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

// Specifies a level for any cell intersected by its edges.
// This is a featureEdgeMesh, read from constant/triSurface for now.
features
(
{
file "DTC-scaled.eMesh";
level 0;
}
{
file "Kelvin-Wake.eMesh";
level 0;
}
);

// Surface based refinement
// ~~~~~~~~~~~~~~~~~~~~~~~~

// Specifies two levels for every surface. The first is the minimum level,
// every cell intersecting a surface gets refined up to the minimum level.
// The second level is the maximum level. Cells that 'see' multiple
// intersections where the intersections make an
// angle > resolveFeatureAngle get refined up to the maximum level.

refinementSurfaces
{
hull
{
// Surface-wise min and max refinement level
level (0 0);
}
kelvin
{
// Surface-wise min and max refinement level
level (0 0);
}
}

resolveFeatureAngle 45;

// Region-wise refinement
// ~~~~~~~~~~~~~~~~~~~~~~

// Specifies refinement level for cells in relation to a surface. One of
// three modes
// - distance. 'levels' specifies per distance to the surface the
// wanted refinement level. The distances need to be specified in
// descending order.
// - inside. 'levels' is only one entry and only the level is used. All
// cells inside the surface get refined up to the level. The surface
// needs to be closed for this to be possible.
// - outside. Same but cells outside.

refinementRegions
{
bowrefinementBox
{
mode inside;
levels ((4 4));
}
transomrefinementBox
{
mode inside;
levels ((4 4));
}
}

// Mesh selection
// ~~~~~~~~~~~~~~

// After refinement patches get added for all refinementSurfaces and
// all cells intersecting the surfaces get put into these patches. The
// section reachable from the locationInMesh is kept.
// NOTE: This point should never be on a face, always inside a cell, even
// after refinement.
locationInMesh (-2 -1 0);

// Whether any faceZones (as specified in the refinementSurfaces)
// are only on the boundary of corresponding cellZones or also allow
// free-standing zone faces. Not used if there are no faceZones.
allowFreeStandingZoneFaces true;
}

// Settings for the snapping.
snapControls
{
//- Number of patch smoothing iterations before finding correspondence
// to surface
nSmoothPatch 3;

//- Relative distance for points to be attracted by surface feature point
// or edge. True distance is this factor times local
// maximum edge length.
// tolerance 4.0;
tolerance 1.0;

//- Number of mesh displacement relaxation iterations.
nSolveIter 100;

//- Maximum number of snapping relaxation iterations. Should stop
// before upon reaching a correct mesh.
nRelaxIter 5;

nFeatureSnapIter 10;
}

// Settings for the layer addition.
addLayersControls
{
// Are the thickness parameters below relative to the undistorted
// size of the refined cell outside layer (true) or absolute sizes (false).
relativeSizes true;

// Per final patch (so not geometry!) the layer information
layers
{
hull
{
nSurfaceLayers 3;

}
}

// Expansion factor for layer mesh
expansionRatio 1.5;

// Wanted thickness of final added cell layer. If multiple layers
// is the thickness of the layer furthest away from the wall.
// Relative to undistorted size of cell outside layer.
// See relativeSizes parameter.
finalLayerThickness 0.7;

// Minimum thickness of cell layer. If for any reason layer
// cannot be above minThickness do not add layer.
// See relativeSizes parameter.
minThickness 0.25;

// If points get not extruded do nGrow layers of connected faces that are
// also not grown. This helps convergence of the layer addition process
// close to features.
// Note: changed(corrected) w.r.t 17x! (didn't do anything in 17x)
nGrow 0;

// Advanced settings

// When not to extrude surface. 0 is flat surface, 90 is when two faces
// are perpendicular
featureAngle 60;

// Maximum number of snapping relaxation iterations. Should stop
// before upon reaching a correct mesh.
nRelaxIter 5;

// Number of smoothing iterations of surface normals
nSmoothSurfaceNormals 1;

// Number of smoothing iterations of interior mesh movement direction
nSmoothNormals 3;

// Smooth layer thickness over surface patches
nSmoothThickness 10;

// Stop layer growth on highly warped cells
maxFaceThicknessRatio 0.5;

// Reduce layer growth where ratio thickness to medial
// distance is large
maxThicknessToMedialRatio 0.3;

// Angle used to pick up medial axis points
// Note: changed(corrected) w.r.t 17x! 90 degrees corresponds to 130 in 17x.
minMedianAxisAngle 90;

// Create buffer region for new layer terminations
nBufferCellsNoExtrude 0;

// Overall max number of layer addition iterations. The mesher will exit
// if it reaches this number of iterations; possibly with an illegal
// mesh.
nLayerIter 50;

// Max number of iterations after which relaxed meshQuality controls
// get used. Up to nRelaxIter it uses the settings in meshQualityControls,
// after nRelaxIter it uses the values in meshQualityControls::relaxed.
nRelaxedIter 20;
}

// Generic mesh quality settings. At any undoable phase these determine
// where to undo.
meshQualityControls
{
#include "meshQualityDict"
}

// Advanced

// Flags for optional output
// 0 : only write final meshes
// 1 : write intermediate meshes
// 2 : write volScalarField with cellLevel for postprocessing
// 4 : write current intersections as .obj files
debug 0;

// Merge tolerance. Is fraction of overall bounding box of initial mesh.
// Note: the write tolerance needs to be higher than this.
mergeTolerance 1E-6;

// ************************************************** *********************** //

XinRen · March 19, 2016, 21:26

Hi Juli, may i know how you get the results for your 3rd picture?

ktodorov · February 20, 2017, 02:46

Hello! I am running a case of the KVLCC2 tanker, but for some reason i can't make the mesh properly. I am posting in this thread, because it is related to ship cases. I use the DTC tutorial in OpenFOAM as a basis and modify it in order to be OK for my model. The iges file, from which i created the stl for OpenFOAM, was downloaded from the SIMMAN 2008 website. There were some problems with it, because it was filled with holes, which i tried to fill in using SALOME and sewing tool. Even after all this the stern looks strange and creates problems. Also the timestep continuity error for the pressure if enormously high as are the results for the forces too, but I believe it is due to the bad geometry. Here are the checkMesh results:

Code:

/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  4.1                                   |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
Build  : 4.1
Exec   : checkMesh
Date   : Feb 20 2017
Time   : 09:32:37
Host   : "kiril"
PID    : 10800
Case   : /home/kiril/OpenFOAM/kiril-4.1/run/tutorials/multiphase/interFoam/ras/KVLCC2
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Allowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create polyMesh for time = 0

Time = 0

Mesh stats
    points:           665441
    faces:            1890306
    internal faces:   1832629
    cells:            613100
    faces per cell:   6.07231
    boundary patches: 7
    point zones:      0
    face zones:       0
    cell zones:       0

Overall number of cells of each type:
    hexahedra:     573213
    prisms:        751
    wedges:        0
    pyramids:      0
    tet wedges:    0
    tetrahedra:    0
    polyhedra:     39136
    Breakdown of polyhedra by number of faces:
        faces   number of cells
            4   601
            5   495
            6   889
            7   32335
            9   4816

Checking topology...
    Boundary definition OK.
    Cell to face addressing OK.
    Point usage OK.
    Upper triangular ordering OK.
    Face vertices OK.
    Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces...
                   Patch    Faces   Points                  Surface topology
              atmosphere      798      860  ok (non-closed singly connected)
                   inlet     3724     3940  ok (non-closed singly connected)
                  outlet     3724     3940  ok (non-closed singly connected)
                  bottom      798      860  ok (non-closed singly connected)
                    side     8232     8471  ok (non-closed singly connected)
                midPlane    25335    26138  ok (non-closed singly connected)
                    hull    15066    16116  ok (non-closed singly connected)

Checking geometry...
    Overall domain bounding box (-26 -19 -16) (16 0 4)
    Mesh has 3 geometric (non-empty/wedge) directions (1 1 1)
    Mesh has 3 solution (non-empty) directions (1 1 1)
    Boundary openness (-1.54867e-15 -7.11445e-15 5.24695e-17) OK.
    Max cell openness = 3.33067e-16 OK.
    Max aspect ratio = 533.333 OK.
    Minimum face area = 9.62553e-06. Maximum face area = 1.00009.  Face area magnitudes OK.
    Min volume = 3.58877e-07. Max volume = 0.933497.  Total volume = 15957.7.  Cell volumes OK.
    Mesh non-orthogonality Max: 72.7177 average: 6.74227
   *Number of severely non-orthogonal (> 70 degrees) faces: 1058.
    Non-orthogonality check OK.
  <<Writing 1058 non-orthogonal faces to set nonOrthoFaces
    Face pyramids OK.
 ***Max skewness = 5.93339, 4 highly skew faces detected which may impair the quality of the results
  <<Writing 4 skew faces to set skewFaces
    Coupled point location match (average 0) OK.

Failed 1 mesh checks.

End

I am also uploading a few screenshots so you can see what the problem is exactly:
error_1.jpg

error_2.jpg

error_3.jpg

error_4.jpg

error_5.jpg

Thank you very much in advance!

Best regards,
Kiril Todorov

hlf4223355 · April 5, 2017, 16:06

Quote:

Originally Posted by egp

Francesco,

You can download the Wigley Hull example at http://idisk.mac.com/egpaterson-Public. Look for the file, wigley.tar.gz.

In naval architecture terminology, this problem is set up for the steady resistance problem, i.e., no motion, and no incident waves. However, I am currently working on these issues.

Eric

Hi Eric,

I`m investigating the problems you studied around ten years ago. I searched the internet and your work still looks most impressive.
It is possible to get your files, as it is not available to download now. My email is luofeng0515@hotmail.com. Many thanks

Best regards,
Luofeng

ktodorov · April 7, 2017, 06:56

Quote:

Originally Posted by ktodorov

Hello! I am running a case of the KVLCC2 tanker, but for some reason i can't make the mesh properly. I am posting in this thread, because it is related to ship cases. I use the DTC tutorial in OpenFOAM as a basis and modify it in order to be OK for my model. The iges file, from which i created the stl for OpenFOAM, was downloaded from the SIMMAN 2008 website. There were some problems with it, because it was filled with holes, which i tried to fill in using SALOME and sewing tool. Even after all this the stern looks strange and creates problems. Also the timestep continuity error for the pressure if enormously high as are the results for the forces too, but I believe it is due to the bad geometry. Here are the checkMesh results:

Code:

/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  4.1                                   |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
Build  : 4.1
Exec   : checkMesh
Date   : Feb 20 2017
Time   : 09:32:37
Host   : "kiril"
PID    : 10800
Case   : /home/kiril/OpenFOAM/kiril-4.1/run/tutorials/multiphase/interFoam/ras/KVLCC2
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Allowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create polyMesh for time = 0

Time = 0

Mesh stats
    points:           665441
    faces:            1890306
    internal faces:   1832629
    cells:            613100
    faces per cell:   6.07231
    boundary patches: 7
    point zones:      0
    face zones:       0
    cell zones:       0

Overall number of cells of each type:
    hexahedra:     573213
    prisms:        751
    wedges:        0
    pyramids:      0
    tet wedges:    0
    tetrahedra:    0
    polyhedra:     39136
    Breakdown of polyhedra by number of faces:
        faces   number of cells
            4   601
            5   495
            6   889
            7   32335
            9   4816

Checking topology...
    Boundary definition OK.
    Cell to face addressing OK.
    Point usage OK.
    Upper triangular ordering OK.
    Face vertices OK.
    Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces...
                   Patch    Faces   Points                  Surface topology
              atmosphere      798      860  ok (non-closed singly connected)
                   inlet     3724     3940  ok (non-closed singly connected)
                  outlet     3724     3940  ok (non-closed singly connected)
                  bottom      798      860  ok (non-closed singly connected)
                    side     8232     8471  ok (non-closed singly connected)
                midPlane    25335    26138  ok (non-closed singly connected)
                    hull    15066    16116  ok (non-closed singly connected)

Checking geometry...
    Overall domain bounding box (-26 -19 -16) (16 0 4)
    Mesh has 3 geometric (non-empty/wedge) directions (1 1 1)
    Mesh has 3 solution (non-empty) directions (1 1 1)
    Boundary openness (-1.54867e-15 -7.11445e-15 5.24695e-17) OK.
    Max cell openness = 3.33067e-16 OK.
    Max aspect ratio = 533.333 OK.
    Minimum face area = 9.62553e-06. Maximum face area = 1.00009.  Face area magnitudes OK.
    Min volume = 3.58877e-07. Max volume = 0.933497.  Total volume = 15957.7.  Cell volumes OK.
    Mesh non-orthogonality Max: 72.7177 average: 6.74227
   *Number of severely non-orthogonal (> 70 degrees) faces: 1058.
    Non-orthogonality check OK.
  <<Writing 1058 non-orthogonal faces to set nonOrthoFaces
    Face pyramids OK.
 ***Max skewness = 5.93339, 4 highly skew faces detected which may impair the quality of the results
  <<Writing 4 skew faces to set skewFaces
    Coupled point location match (average 0) OK.

Failed 1 mesh checks.

End

I am also uploading a few screenshots so you can see what the problem is exactly:
Attachment 54084

Attachment 54085

Attachment 54086

Attachment 54087

Attachment 54088

Thank you very much in advance!

Best regards,
Kiril Todorov

I fixed the problem by using another igs file, which was much easier to correct.

Fauster · October 20, 2017, 10:44

Dear Foamers,

I spent many weeks trying to get the good wave pattern (KIM measurements 2001) from KCS model.

I noticed that if the mesh are very elongated (see pictures attached mesh is around 1.5 M cells) the wave pattern is damped. Are you ok with that ? (In this paper http://www.academia.edu/28622908/THE...OURCE_OVERVIEW they achieve to get a wonderful wave pattern with a mesh very close to mine) How they do it ? The ratio near outlet is voluntary huge to avoid wave reflexion.

I tried another mesh strategy by using a refinement Box on the free surface (so cubic mesh and no elongation). The results in term of wave pattern seem better (less damping) but the cells number goes to 3 M.

Another problem I noticed is the behavior of the pressure coefficient. My pressure coefficient oscillate strongly (and reach positive values !!) (at least during 5000 iterations and sometimes more).

Is it possible to obtain reliable results with a cell number around 1.5 M (like in the study) ? What is the influence of shemes and solver settings ? What are the good boundaries conditions ? Actually I am using the same as DTC HULL tutorial :

alpha.water
inlet fixedValue
outlet : variableHeightFlowrate
top : inletOutlet
hull : zeroGradient
others : symmetry

U
inlet fixedValue
outlet : outletPhaseMeanVelocity
top : pressureInletOutletVelocity
hull : noSlip
others : symmetry

p_rgh
inlet fixedFluxPressure
outlet : fixedFluxPressure
top : totalPressure
hull : fixedFluxPressure
others : symmetry

nut
inlet calculated
outlet : calculated
top : calculated
hull : nutkWallFunction
others : symmetry

omega and k
inlet fixedValue
outlet : inletOutlet
top : inletOutlet
hull : nutkWallFunction or kqRWallFunction
others : symmetry

Thanks a lot for your help !

PS : I am using OF5 with LTSInterfoam (interFoam with localEuler scheme)
PPS : Here are my fvScheme and fvSolution files

Quote:

/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 4.1 |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
location "system";
object fvSolution;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

solvers
{
"alpha.water.*"
{
nAlphaCorr 3;
nAlphaSubCycles 1;
cAlpha 1;
icAlpha 0;

MULESCorr yes;
nLimiterIter 15;
alphaApplyPrevCorr yes;

solver smoothSolver;
smoother symGaussSeidel;
tolerance 1e-10;
relTol 0;
minIter 1;
}

"pcorr.*"
{
solver GAMG;

smoother DIC;

tolerance 1e-3;
relTol 0;
};

p_rgh
{
solver GAMG;

smoother DIC;

tolerance 5e-8;
relTol 0;
};

p_rghFinal
{
$p_rgh;
relTol 0;
}

"(U|k|omega).*"
{
solver smoothSolver;

smoother symGaussSeidel;
nSweeps 1;

tolerance 1e-7;
relTol 0;
minIter 1;
};
}

PIMPLE
{
momentumPredictor no;

nOuterCorrectors 2;
nCorrectors 2;
nNonOrthogonalCorrectors 0;

maxCo 10;
maxAlphaCo 5;

rDeltaTSmoothingCoeff 0.05;
rDeltaTDampingCoeff 0.5;
nAlphaSpreadIter 0;
nAlphaSweepIter 0;
maxDeltaT 1;
}

relaxationFactors
{
equations
{
".*" 1;
}
}

cache
{
grad(U);
}

Quote:

ddtSchemes
{
default localEuler;
}

gradSchemes
{
default Gauss linear;
limitedGrad cellLimited Gauss linear 1;
}

divSchemes
{
div(rhoPhi,U) Gauss linearUpwind grad(U);
div(phi,alpha) Gauss vanLeer;
div(phirb,alpha) Gauss linear;
div(phi,k) Gauss linearUpwind limitedGrad;
div(phi,omega) Gauss linearUpwind limitedGrad;
div(((rho*nuEff)*dev2(T(grad(U))))) Gauss linear;
}

laplacianSchemes
{
default Gauss linear corrected;
}

interpolationSchemes
{
default linear;
}

snGradSchemes
{
default corrected;
}

wallDist
{
method meshWave;
}

Fauster · November 16, 2017, 09:43

Hi everyone,

I changed my BC setup, mesh and also solver setting but it's also impossible to calculate the true kelvin wave pattern.

I tried to mesh the interface water/air with cell size of 5 mm but the wave pattern remains damped.

I tried interFoam without LTS option without success on the kelvin wave pattern. I also tried several schemes for alpha.water : linear, vanleer or interfaceCompression but no real influence on the results.

I changed the BC setup to the following (without success):

inlet, side, top and bottom as inlet for U, fixedFLuxPressure for p_rgh.
for outlet : fixedValue 0 for p_rgh and zeroGradient for U.

In all the cases the wave pattern is strongly damped behind the hull and no waves are calculated after x = -0.5/Lpp

EDIT : switch on the momentum predicator in the PISO loop improve the results. I am going to try with the last version of openFoam.com (17.06) wich provide an improved way to capture water/Air interface.

Any advices ?

Thanks

a.morang · January 21, 2018, 12:18

Fauster,

can you show the wave pattern?
can you show the mesh on the water plane?

thanks in advance,

Fauster · January 26, 2018, 05:02

Quote:

Originally Posted by a.morang

Fauster,

can you show the wave pattern?
can you show the mesh on the water plane?

thanks in advance,

I solved my problem and I got an flow pattern in perfect agreement with KIM measurements.

Since my last post I increased the calculation box and refined the number of cells in the longitudinal direction. I also noticed an important fact : it's important to avoid polyhedral cells near the free surface. This cells are created by the refineMesh operation for transitioning between two levels. From my experience this cells affect the result in a bad manner.

Fauster · March 12, 2018, 09:37

Dear Foamer,

I am still working on CFD for ship resistance and I would like to know your initialization strategy.

For example if I want to run a transient analysis with interfoam or interdymfoam case (like DTChull tutorial) I put at t = 0 sec the hull in a non zero velocity field. By doing this you creates a large wave at the bow and depending of the mesh you can produce numerical ventilation. Moreover if you have a 2DOF you will get significant accelerations and numerical instabilities.

Do you have an idea to avoid this behavior by having a smart strategy ?
Thanks in advance !
F

a.morang · March 12, 2018, 10:08

Quote:

Originally Posted by Fauster

Dear Foamer,

I am still working on CFD for ship resistance and I would like to know your initialization strategy.

For example if I want to run a transient analysis with interfoam or interdymfoam case (like DTChull tutorial) I put at t = 0 sec the hull in a non zero velocity field. By doing this you creates a large wave at the bow and depending of the mesh you can produce numerical ventilation. Moreover if you have a 2DOF you will get significant accelerations and numerical instabilities.

Do you have an idea to avoid this behavior by having a smart strategy ?
Thanks in advance !
F

If you do a dynamic simulation, you can run first an static one in order to avoid mesh displacement and high accelerations at the begining of the simulation. Another possibility is to increase the damping in the 2DoF options.

With the ventilation I can not help you, the only thing that I usually do is to use a variable time step based on the Courant number and I think that this improve ventilation, but maybe is my imagination... XD

Regards!

Fauster · March 13, 2018, 09:15

Quote:

Originally Posted by a.morang

If you do a dynamic simulation, you can run first an static one in order to avoid mesh displacement and high accelerations at the begining of the simulation. Another possibility is to increase the damping in the 2DoF options.

With the ventilation I can not help you, the only thing that I usually do is to use a variable time step based on the Courant number and I think that this improve ventilation, but maybe is my imagination... XD

Regards!

Yes running LTSinterFoam at first will improve the behavior. Do you know if there is a way to use potentialFoam for initialization ?

For the ventilation I found out that interfaceCompression BC is designed for avoiding numerical ventilation. On my last run it appears to be very promising.

Fauster · March 15, 2018, 10:17

Dear Foamer,

For all my hull resistance simulation the pressure coefficient shows large oscillations (as I described in a previous post). This behavior really slow down the time before reaching a quasy steady state.

I thought it came from the boundary condition used in the tutorials DTChull :

totaPressure for atmosphere
variableHeightFlowRate; for alpha @outlet
outletPhaseMeanVelocity; for U @Outlet

So I went back to more classical BC with fixedValue for p_rgh @outlet and zeroGradient for U and alpha (@outlet). The behavior is better and the convergence is reached quicker but I still have large pressure oscillation.

Is it possible that it comes from fvsolution settings ? (I used the same as the tutorial).

Has someone experienced the same thing ?

Thanks

Paul

sita · April 16, 2019, 10:13

Hi all,

I recently started using OpenFOAM (5.1-x on Scientific Linux cluster) for marine hydrodynamics applications. To start with I went through the DTC Hull tutorials that come with the standard installation, the interFoam and interDyMFoam ones.

Does anyone know whether there is some more information available about these tutorials, e.g. on how and why boundary condition types, solver settings, schemes, etc. were chosen?

I searched through this forum and on Google, but couldn't find much on these tutorials (most of the links posted here no longer work).

I'd greatly appreciate any help!
Thanks in advance,
Sita

January 3, 2016, 10:32	Snappyhexmesh for refinement on bow, transom, kelvin wake	#307
gigliagarf New Member Join Date: Oct 2014 Location: Lafayette, LA Posts: 18 Rep Power: 11	Hello, I've been working through learning about the DTChull case. I am trying to get volume refinements at the bow and transom and have surface refinement around the kelvin wake. I have created two searchablebox geometries and an stl file of the triangular kelvin wake. In addition I have the free surface refinement of the original DTCHull example, that I have adapted to fit my domain and water depth. It keeps throwing me errors. Is there something I should be doing differently? Should I be making the bow and transom refinements as stl and trim out the part of the bow that intersects the hull? How can I get these refinements to play nicely with each other? Does anyone have any tricks to getting intersecting refinement regions to work? Thank you for your help! /--------------------------------- C++ -----------------------------------\ \| ========= \| \| \| \\ / F ield \| OpenFOAM: The Open Source CFD Toolbox \| \| \\ / O peration \| Version: 2.4.0 \| \| \\ / A nd \| Web: www.OpenFOAM.org \| \| \\/ M anipulation \| \| \---------------------------------------------------------------------------/ FoamFile { version 2.0; format ascii; class dictionary; object snappyHexMeshDict; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // // Which of the steps to run castellatedMesh true; snap true; addLayers true; // Geometry. Definition of all surfaces. All surfaces are of class // searchableSurface. // Surfaces are used // - to specify refinement for any mesh cell intersecting it // - to specify refinement for any mesh cell inside/outside/near // - to 'snap' the mesh boundary to the surface geometry { DTC-scaled.stl { type triSurfaceMesh; name hull; patchInfo { type wall; } } Kelvin-Wake.stl { type triSurfaceMesh; name kelvin; patchInfo { type wall; } } bowrefinementBox { type searchableBox; min (7.18401 -1 -0.149903); max (10.0931 1 0.662375); } transomrefinementBox { type searchableBox; min (-0.509046 -1.18756 -0.0440771); max (1.71845 1.18756 0.475878); } }; // Settings for the castellatedMesh generation. castellatedMeshControls { // Refinement parameters // ~~~~~~~~~~~~~~~~~~~~~ // If local number of cells is >= maxLocalCells on any processor // switches from from refinement followed by balancing // (current method) to (weighted) balancing before refinement. maxLocalCells 500000; // Overall cell limit (approximately). Refinement will stop immediately // upon reaching this number so a refinement level might not complete. // Note that this is the number of cells before removing the part which // is not 'visible' from the keepPoint. The final number of cells might // actually be a lot less. maxGlobalCells 2000000; // The surface refinement loop might spend lots of iterations refining just a // few cells. This setting will cause refinement to stop if <= minimumRefine // are selected for refinement. Note: it will at least do one iteration // (unless the number of cells to refine is 0) minRefinementCells 0; // Number of buffer layers between different levels. // 1 means normal 2:1 refinement restriction, larger means slower // refinement. nCellsBetweenLevels 3; // Explicit feature edge refinement // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // Specifies a level for any cell intersected by its edges. // This is a featureEdgeMesh, read from constant/triSurface for now. features ( { file "DTC-scaled.eMesh"; level 0; } { file "Kelvin-Wake.eMesh"; level 0; } ); // Surface based refinement // ~~~~~~~~~~~~~~~~~~~~~~~~ // Specifies two levels for every surface. The first is the minimum level, // every cell intersecting a surface gets refined up to the minimum level. // The second level is the maximum level. Cells that 'see' multiple // intersections where the intersections make an // angle > resolveFeatureAngle get refined up to the maximum level. refinementSurfaces { hull { // Surface-wise min and max refinement level level (0 0); } kelvin { // Surface-wise min and max refinement level level (0 0); } } resolveFeatureAngle 45; // Region-wise refinement // ~~~~~~~~~~~~~~~~~~~~~~ // Specifies refinement level for cells in relation to a surface. One of // three modes // - distance. 'levels' specifies per distance to the surface the // wanted refinement level. The distances need to be specified in // descending order. // - inside. 'levels' is only one entry and only the level is used. All // cells inside the surface get refined up to the level. The surface // needs to be closed for this to be possible. // - outside. Same but cells outside. refinementRegions { bowrefinementBox { mode inside; levels ((4 4)); } transomrefinementBox { mode inside; levels ((4 4)); } } // Mesh selection // ~~~~~~~~~~~~~~ // After refinement patches get added for all refinementSurfaces and // all cells intersecting the surfaces get put into these patches. The // section reachable from the locationInMesh is kept. // NOTE: This point should never be on a face, always inside a cell, even // after refinement. locationInMesh (-2 -1 0); // Whether any faceZones (as specified in the refinementSurfaces) // are only on the boundary of corresponding cellZones or also allow // free-standing zone faces. Not used if there are no faceZones. allowFreeStandingZoneFaces true; } // Settings for the snapping. snapControls { //- Number of patch smoothing iterations before finding correspondence // to surface nSmoothPatch 3; //- Relative distance for points to be attracted by surface feature point // or edge. True distance is this factor times local // maximum edge length. // tolerance 4.0; tolerance 1.0; //- Number of mesh displacement relaxation iterations. nSolveIter 100; //- Maximum number of snapping relaxation iterations. Should stop // before upon reaching a correct mesh. nRelaxIter 5; nFeatureSnapIter 10; } // Settings for the layer addition. addLayersControls { // Are the thickness parameters below relative to the undistorted // size of the refined cell outside layer (true) or absolute sizes (false). relativeSizes true; // Per final patch (so not geometry!) the layer information layers { hull { nSurfaceLayers 3; } } // Expansion factor for layer mesh expansionRatio 1.5; // Wanted thickness of final added cell layer. If multiple layers // is the thickness of the layer furthest away from the wall. // Relative to undistorted size of cell outside layer. // See relativeSizes parameter. finalLayerThickness 0.7; // Minimum thickness of cell layer. If for any reason layer // cannot be above minThickness do not add layer. // See relativeSizes parameter. minThickness 0.25; // If points get not extruded do nGrow layers of connected faces that are // also not grown. This helps convergence of the layer addition process // close to features. // Note: changed(corrected) w.r.t 17x! (didn't do anything in 17x) nGrow 0; // Advanced settings // When not to extrude surface. 0 is flat surface, 90 is when two faces // are perpendicular featureAngle 60; // Maximum number of snapping relaxation iterations. Should stop // before upon reaching a correct mesh. nRelaxIter 5; // Number of smoothing iterations of surface normals nSmoothSurfaceNormals 1; // Number of smoothing iterations of interior mesh movement direction nSmoothNormals 3; // Smooth layer thickness over surface patches nSmoothThickness 10; // Stop layer growth on highly warped cells maxFaceThicknessRatio 0.5; // Reduce layer growth where ratio thickness to medial // distance is large maxThicknessToMedialRatio 0.3; // Angle used to pick up medial axis points // Note: changed(corrected) w.r.t 17x! 90 degrees corresponds to 130 in 17x. minMedianAxisAngle 90; // Create buffer region for new layer terminations nBufferCellsNoExtrude 0; // Overall max number of layer addition iterations. The mesher will exit // if it reaches this number of iterations; possibly with an illegal // mesh. nLayerIter 50; // Max number of iterations after which relaxed meshQuality controls // get used. Up to nRelaxIter it uses the settings in meshQualityControls, // after nRelaxIter it uses the values in meshQualityControls::relaxed. nRelaxedIter 20; } // Generic mesh quality settings. At any undoable phase these determine // where to undo. meshQualityControls { #include "meshQualityDict" } // Advanced // Flags for optional output // 0 : only write final meshes // 1 : write intermediate meshes // 2 : write volScalarField with cellLevel for postprocessing // 4 : write current intersections as .obj files debug 0; // Merge tolerance. Is fraction of overall bounding box of initial mesh. // Note: the write tolerance needs to be higher than this. mergeTolerance 1E-6; // ************************************************ ********************* //

November 16, 2017, 09:43		#313
Fauster Member Paul Palladium Join Date: Jan 2016 Posts: 93 Rep Power: 10	Hi everyone, I changed my BC setup, mesh and also solver setting but it's also impossible to calculate the true kelvin wave pattern. I tried to mesh the interface water/air with cell size of 5 mm but the wave pattern remains damped. I tried interFoam without LTS option without success on the kelvin wave pattern. I also tried several schemes for alpha.water : linear, vanleer or interfaceCompression but no real influence on the results. I changed the BC setup to the following (without success): inlet, side, top and bottom as inlet for U, fixedFLuxPressure for p_rgh. for outlet : fixedValue 0 for p_rgh and zeroGradient for U. In all the cases the wave pattern is strongly damped behind the hull and no waves are calculated after x = -0.5/Lpp EDIT : switch on the momentum predicator in the PISO loop improve the results. I am going to try with the last version of openFoam.com (17.06) wich provide an improved way to capture water/Air interface. Any advices ? Thanks Last edited by Fauster; November 21, 2017 at 06:46.

March 15, 2018, 10:17		#319
Fauster Member Paul Palladium Join Date: Jan 2016 Posts: 93 Rep Power: 10	Dear Foamer, For all my hull resistance simulation the pressure coefficient shows large oscillations (as I described in a previous post). This behavior really slow down the time before reaching a quasy steady state. I thought it came from the boundary condition used in the tutorials DTChull : totaPressure for atmosphere variableHeightFlowRate; for alpha @outlet outletPhaseMeanVelocity; for U @Outlet So I went back to more classical BC with fixedValue for p_rgh @outlet and zeroGradient for U and alpha (@outlet). The behavior is better and the convergence is reached quicker but I still have large pressure oscillation. Is it possible that it comes from fvsolution settings ? (I used the same as the tutorial). Has someone experienced the same thing ? Thanks Paul

April 16, 2019, 10:13	DTC Hull tutorial	#320
sita Senior Member Sita Drost Join Date: Mar 2009 Location: Arnhem, The Netherlands Posts: 227 Rep Power: 18	Hi all, I recently started using OpenFOAM (5.1-x on Scientific Linux cluster) for marine hydrodynamics applications. To start with I went through the DTC Hull tutorials that come with the standard installation, the interFoam and interDyMFoam ones. Does anyone know whether there is some more information available about these tutorials, e.g. on how and why boundary condition types, solver settings, schemes, etc. were chosen? I searched through this forum and on Google, but couldn't find much on these tutorials (most of the links posted here no longer work). I'd greatly appreciate any help! Thanks in advance, Sita

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Free-Surface Ship Flow - Boundary Conditions	James Date	CFX	1	February 19, 2013 05:42
ship free-surface analysis	Andrea Mercuri	Siemens	0	September 28, 2004 11:01
Free Surface Flow for Ship	sam	FLUENT	6	October 24, 2003 05:29
viscous free surface flow past a ship hull	lololo	Main CFD Forum	0	June 12, 2002 23:02
meshing for surface ship flow	boris	FLUENT	0	April 24, 2002 20:27

April 10, 2015, 01:57		#301
romainRH New Member romainRH Join Date: Jul 2012 Posts: 24 Rep Power: 13	Well, as far as i understand local time stepping theory/algorithm, it is not possible to use it for any unsteady simulation (for now...) Also which version of Foam are you using. Last time i checked it was not possible to run simulation with both waves and forward speed. Am i wrong ?

April 21, 2015, 08:34		#303
Sachin m Member Sachin Join Date: Aug 2014 Location: India Posts: 84 Rep Power: 11	romainRH, I am using OpenFoam 2.3.1

July 23, 2015, 15:54		#305
CFD-Palma Member carlos Join Date: Apr 2011 Posts: 37 Rep Power: 15	Hi Jojosaxo, I do not know if this will help, but when I had similar problems it was a matter of mesh. Also, the interface from coarse to fine (refined) generates waves, I suggest using multi grading to avoid this effect. Good lack, Carlos.

March 19, 2016, 21:26		#308
XinRen New Member Xin Ren Join Date: Feb 2016 Posts: 6 Rep Power: 10	Hi Juli, may i know how you get the results for your 3rd picture?

January 21, 2018, 12:18		#314
a.morang New Member Amadeo Moran Join Date: Jan 2012 Location: Madrid Posts: 10 Rep Power: 14	Fauster, can you show the wave pattern? can you show the mesh on the water plane? thanks in advance,

March 12, 2018, 09:37		#316
Fauster Member Paul Palladium Join Date: Jan 2016 Posts: 93 Rep Power: 10	Dear Foamer, I am still working on CFD for ship resistance and I would like to know your initialization strategy. For example if I want to run a transient analysis with interfoam or interdymfoam case (like DTChull tutorial) I put at t = 0 sec the hull in a non zero velocity field. By doing this you creates a large wave at the bow and depending of the mesh you can produce numerical ventilation. Moreover if you have a 2DOF you will get significant accelerations and numerical instabilities. Do you have an idea to avoid this behavior by having a smart strategy ? Thanks in advance ! F