[arashghgood]

Dear Pablo
First of all, thank you for your help. the mesh problem accomplished and the case works.
I am interested in measuring the wave amplitude in different locations. assume a tank of 10 m in length for example. a solitary wave starts at t=0. I want to measure its amplitude in x=2, x=6, x=9 for example. then plot these points. (2,a1), (6,a2), and (9,a3)
I used sampling and prob in OpenFoam. but the came back a function of time.
I need just the amplitude when the wave paths the locations
How can I do?

[Michael@UW]

Originally Posted by Phicau

Dear all,

olaFlow is now compatible with the newest releases of OpenFOAM (v1906 and v7).

You can get the latest version in https://github.com/phicau/olaFlow

Best,

Pablo

Hi Pablo,
Can you help me with the following compiling errors with OpenFOAMv1906?
Thank you!
Michael

....
OlaFlow project wave absorption boundary conditions compiled successfully for OpenFOAM v1906



wmake overOlaDyMFlow
make[1]: Entering directory `/pfs/tsfs1/project/multicfd/olaFlow/solvers/olaFlowOFv19xx/overOlaDyMFlow'
Making dependency list for source file overOlaDyMFlow.C
make[1]: Leaving directory `/pfs/tsfs1/project/multicfd/olaFlow/solvers/olaFlowOFv19xx/overOlaDyMFlow'
make[1]: Entering directory `/pfs/tsfs1/project/multicfd/olaFlow/solvers/olaFlowOFv19xx/overOlaDyMFlow'
g++ -std=c++11 -m64 -DOPENFOAM=1906 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -Wno-unknown-pragmas -O3 -DNoRepository -ftemplate-depth-100 -I. -I.. -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/finiteVolume/lnInclude -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/meshTools/lnInclude -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/sampling/lnInclude -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/transportModels/twoPhaseMixture/lnInclude -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/transportModels -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/transportModels/incompressible/lnInclude -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/transportModels/interfaceProperties/lnInclude -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/TurbulenceModels/turbulenceModels/lnInclude -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/TurbulenceModels/incompressible/lnInclude -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/transportModels/immiscibleIncompressibleTwoPhaseMixture/lnInclude -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/dynamicMesh/lnInclude -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/dynamicFvMesh/lnInclude -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/applications/solvers/incompressible/pimpleFoam/overPimpleDyMFoam -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/overset/lnInclude -IlnInclude -I. -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/OpenFOAM/lnInclude -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/OSspecific/POSIX/lnInclude -fPIC -c overOlaDyMFlow.C -o Make/linux64GccDPInt32Opt/overOlaDyMFlow.o
g++ -std=c++11 -m64 -DOPENFOAM=1906 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -Wno-unknown-pragmas -O3 -DNoRepository -ftemplate-depth-100 -I. -I.. -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/finiteVolume/lnInclude -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/meshTools/lnInclude -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/sampling/lnInclude -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/transportModels/twoPhaseMixture/lnInclude -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/transportModels -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/transportModels/incompressible/lnInclude -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/transportModels/interfaceProperties/lnInclude -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/TurbulenceModels/turbulenceModels/lnInclude -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/TurbulenceModels/incompressible/lnInclude -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/transportModels/immiscibleIncompressibleTwoPhaseMixture/lnInclude -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/dynamicMesh/lnInclude -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/dynamicFvMesh/lnInclude -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/applications/solvers/incompressible/pimpleFoam/overPimpleDyMFoam -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/overset/lnInclude -IlnInclude -I. -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/OpenFOAM/lnInclude -I/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/src/OSspecific/POSIX/lnInclude -fPIC -Xlinker --add-needed -Xlinker --no-as-needed Make/linux64GccDPInt32Opt/overOlaDyMFlow.o -L/project/multicfd/OpenFOAMv1906/OpenFOAM/OpenFOAM-v1906/platforms/linux64GccDPInt32Opt/lib \
-lfiniteVolume -lfvOptions -lsampling -lincompressibleTransportModels -linterfaceProperties -limmiscibleIncompressibleTwoPhaseMixture -lturbulenceModels -lincompressibleTurbulenceModels -ldynamicMesh -ldynamicFvMesh -ltopoChangerFvMesh -loverset -L/home/lli16/OpenFOAM/lli16-v1906/platforms/linux64GccDPInt32Opt/lib -lwaveGeneration -lwaveAbsorption -lOpenFOAM -ldl \
-lm -o /home/lli16/OpenFOAM/lli16-v1906/platforms/linux64GccDPInt32Opt/bin/overOlaDyMFlow
Make/linux64GccDPInt32Opt/overOlaDyMFlow.o: In function `Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::storeOldTimes() const':
overOlaDyMFlow.C.text._ZNK4Foam14GeometricFieldI dNS_12fvPatchFieldENS_7volMeshEE13storeOldTimesEv[_ZNK4Foam14GeometricFieldIdNS_12fvPatchFieldENS_7v olMeshEE13storeOldTimesEv]+0x5e): undefined reference to `Foam::string::endsWith(std::__cxx11::basic_string <char, std::char_traits<char>, std::allocator<char> > const&) const'
Make/linux64GccDPInt32Opt/overOlaDyMFlow.o: In function `Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh>::storeOldTimes() const':
overOlaDyMFlow.C.text._ZNK4Foam14GeometricFieldI dNS_13fvsPatchFieldENS_11surfaceMeshEE13storeOldTi mesEv[_ZNK4Foam14GeometricFieldIdNS_13fvsPatchFieldENS_1 1surfaceMeshEE13storeOldTimesEv]+0x5e): undefined reference to `Foam::string::endsWith(std::__cxx11::basic_string <char, std::char_traits<char>, std::allocator<char> > const&) const'
Make/linux64GccDPInt32Opt/overOlaDyMFlow.o: In function `Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::storeOldTimes() const':
overOlaDyMFlow.C.text._ZNK4Foam14GeometricFieldI NS_6VectorIdEENS_12fvPatchFieldENS_7volMeshEE13sto reOldTimesEv[_ZNK4Foam14GeometricFieldINS_6VectorIdEENS_12fvPat chFieldENS_7volMeshEE13storeOldTimesEv]+0x5e): undefined reference to `Foam::string::endsWith(std::__cxx11::basic_string <char, std::char_traits<char>, std::allocator<char> > const&) const'
Make/linux64GccDPInt32Opt/overOlaDyMFlow.o: In function `Foam::GeometricField<Foam::Vector<double>, Foam::fvsPatchField, Foam::surfaceMesh>::storeOldTimes() const':
overOlaDyMFlow.C.text._ZNK4Foam14GeometricFieldI NS_6VectorIdEENS_13fvsPatchFieldENS_11surfaceMeshE E13storeOldTimesEv[_ZNK4Foam14GeometricFieldINS_6VectorIdEENS_13fvsPa tchFieldENS_11surfaceMeshEE13storeOldTimesEv]+0x5e): undefined reference to `Foam::string::endsWith(std::__cxx11::basic_string <char, std::char_traits<char>, std::allocator<char> > const&) const'
Make/linux64GccDPInt32Opt/overOlaDyMFlow.o: In function `Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh>::storeOldTimes() const':
overOlaDyMFlow.C.text._ZNK4Foam14GeometricFieldI NS_6TensorIdEENS_12fvPatchFieldENS_7volMeshEE13sto reOldTimesEv[_ZNK4Foam14GeometricFieldINS_6TensorIdEENS_12fvPat chFieldENS_7volMeshEE13storeOldTimesEv]+0x5e): undefined reference to `Foam::string::endsWith(std::__cxx11::basic_string <char, std::char_traits<char>, std::allocator<char> > const&) const'
Make/linux64GccDPInt32Opt/overOlaDyMFlow.overOlaDyMFlow.C.text._ZNK4Foam 14GeometricFieldINS_10SymmTensorIdEENS_12fvPatchFi eldENS_7volMeshEE13storeOldTimesEv[_ZNK4Foam14GeometricFieldINS_10SymmTensorIdEENS_12 fvPatchFieldENS_7volMeshEE13storeOldTimesEv]+0x5e): more undefined references to `Foam::string::endsWith(std::__cxx11::basic_string <char, std::char_traits<char>, std::allocator<char> > const&) const' follow
Make/linux64GccDPInt32Opt/overOlaDyMFlow.o.data.rel.ro._ZTVN4Foam8OPstream E[_ZTVN4Foam8OPstreamE]+0x80): undefined reference to `Foam::UOPstream::writeQuoted(std::__cxx11::basic_ string<char, std::char_traits<char>, std::allocator<char> > const&, bool)'
/home/lli16/OpenFOAM/lli16-v1906/platforms/linux64GccDPInt32Opt/lib/libwaveAbsorption.so: undefined reference to `Foam:perator<<(Foam::Ostream&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
collect2: error: ld returned 1 exit status
make[1]: *** [/home/lli16/OpenFOAM/lli16-v1906/platforms/linux64GccDPInt32Opt/bin/overOlaDyMFlow] Error 1
make[1]: Leaving directory `/pfs/tsfs1/project/multicfd/olaFlow/solvers/olaFlowOFv19xx/overOlaDyMFlow'
make: *** [overOlaDyMFlow] Error 2
olaFlow solvers compilation failed

[Phicau]

Hi Arash,


yes, sampling produces a time series of free surface elevation. Obviously, if you want the solitary wave height you need to postprocess such time series, getting the maximum value and subtracting the still water level (first value).


Hi Michael,


I have just rechecked and everything compiles well in my computer. I would suggest you to recompile (or reinstall) OpenFOAM in your machine. If it still does not work, please report back with additional details on your system, installation type...
Chances are that if you installed a pre-compiled version, there might be something weird or wrong with it, so in the end you may need to file a bug report with the releasers directly.


Best,


Pablo

[Michael@UW]

Hi Phicau,
Thank you for your rechecking. I'll try to reinstall my OFv1916 on HPC later. I'll let you know if it works when I get it done.

Best,
Michael

[M.W.G.]

Hi Pablo,

I have installed OpenFOAM5 on my laptop and it seems to be working fine, tested using the elbow tutorial. However, I was trying to install olaFlow using the instructions provided here (as usual), and unfortunately it fails:

$ ./allMake 
wmake libso genAbs/waveGeneration
/opt/openfoam5/wmake/wmake: line 409: make: command not found
/opt/openfoam5/wmake/wmake: line 412: make: command not found
wmake error: file 'Make/linux64GccDPInt32Opt/sourceFiles' could not be created in /home/mwg/olaFlow/genAbs/waveGeneration
\n\nOlaFlow project wave generation boundary conditions compilation failed

I have also tried installing olaFlow on OpenFOAM6 and it also fails:

$ ./allMake 
wmake libso genAbs/waveGeneration
/opt/openfoam6/wmake/wmake: line 410: make: command not found
/opt/openfoam6/wmake/wmake: line 413: make: command not found
wmake error: file 'Make/linux64GccDPInt32Opt/sourceFiles' could not be created in /home/mwg/olaFlow/genAbs/waveGeneration
\n\nOlaFlow project wave generation boundary conditions compilation failed

So, do you have a clue on what am I missing here?

[M.W.G.]

Hi Pablo,

I was trying to compile OlaFlow on both OpenFOAM5 and 6 on my laptop with no luck so far. I am following (as usual) the steps provided at this link. this is what i get once I run ./allMake:

OpenFOAM5:

wmake libso genAbs/waveGeneration
/opt/openfoam5/wmake/wmake: line 409: make: command not found
/opt/openfoam5/wmake/wmake: line 412: make: command not found
wmake error: file 'Make/linux64GccDPInt32Opt/sourceFiles' could not be created in /home/mwg/olaFlow/genAbs/waveGeneration
\n\nOlaFlow project wave generation boundary conditions compilation failed

OpenFOAM6:

wmake libso genAbs/waveGeneration
/opt/openfoam6/wmake/wmake: line 410: make: command not found
/opt/openfoam6/wmake/wmake: line 413: make: command not found
wmake error: file 'Make/linux64GccDPInt32Opt/sourceFiles' could not be created in /home/mwg/olaFlow/genAbs/waveGeneration
\n\nOlaFlow project wave generation boundary conditions compilation failed

You may kindly notice that the openFOAM installations seem to be working fine, I have tested them using the elbow tutorial and they were fine.

So, what am I missing here?

looking forward to hearing from you.

P.S.

After further investigation I suspected that this may be related to "make" binaries. Simply, removing and reinstalling "make" solved the problem.

I will be just leave these comments here for future references.


Mwg.

[renos]

Dear Pablo,

I am trying to simulate wave breaking in a monopile using OlaFlow. I am using the library libforces.so provided by OpenFoam but a have a lot of difference in the magnitude of Force. All the other things (mesh / boundary conditions is the same ). Below is the function that I am using in the controlDict file. Also the diameter of the monopile is D=0.7 m / H=1.3 / T = 4.0s / d=3.8 m. What is going wrong ?

forceCylinder
{
type forces ;
libs ("libforces.so");
enabled true;
patches ("cylinder");
pName p;
UName U;
rho rhoInf;
rhoInf 1;
CofR (0 0 0);
log true;
writeControl timeStep;
writeInterval 1;
}

Thanks you very much for your time,

Kind regards

Renos

[aow]

Hi Renos,

Without some details concerning more specifically what is wrong with the force/moment results you're getting as well as simulation setup (i.e. domain geometry, mesh setup, solution setup, etc...) it's a bit hard to take a stab in the dark to guess what's going wrong for you.

Concerning your setup of the force recording function object, it looks correct to me. Just make sure that your "CofR" (i.e. center of rotation) is where you want it (i.e. at the bottom center of your pile) to get the moment values you're expecting since the moment arm for calculating these results is taken to be the distance between the CofR and the center of pressure through which a resultant force acts. The forces will not change regardless of what CofR you specify as one should expect.

My gut instinct for a problem like you're doing is that the mesh probably has some poor quality cells somewhere that are messing up your solution. In particular, I would be curious to know how you meshed around the cylindrical pile. If you're relying on snappyHexMesh to perfectly fit the cylinder into a mesh created by blockMesh, you'll probably get some bad quality cells, especially near regions where your pile intersects a boundary. To avoid such issues, take an approach like the one shown in this video using only blockMesh to get vastly improved results and also a meshing setup that is scalable should you want to perform a refinement study to see if your forces converge.

[renos]

Dear Aow,

Thanks you for your quick reply, I will give you some extra details about my case. The case that I want to simulate is like the picture in the link with the STL files / system folder and constant folder.

https://drive.google.com/open?id=1w3...PqTfL9uSi28N8F

The checkMesh results are below.

CheckMesh
Mesh stats
points: 1909871
faces: 5593569
internal faces: 5458041
cells: 1842154
faces per cell: 5.99929
boundary patches: 7
point zones: 0
face zones: 0
cell zones: 0

Overall number of cells of each type:
hexahedra: 1840840
prisms: 1306
wedges: 0
pyramids: 0
tet wedges: 0
tetrahedra: 0
polyhedra: 8
Breakdown of polyhedra by number of faces:
faces number of cells
5 8

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
inlet 4000 4131 ok (non-closed singly connected)
outlet 2850 2958 ok (non-closed singly connected)
ground 7500 7701 ok (non-closed singly connected)
top 27000 27591 ok (non-closed singly connected)
sides 73750 74946 ok (non-closed singly connected)
slope 19462 19915 ok (non-closed singly connected)
cylinder 966 984 ok (non-closed singly connected)

Checking faceZone topology for multiply connected surfaces...
No faceZones found.

Checking basic cellZone addressing...
No cellZones found.

Checking geometry...
Overall domain bounding box (0 0 0) (54 5 8)
Mesh has 3 geometric (non-empty/wedge) directions (1 1 1)
Mesh has 3 solution (non-empty) directions (1 1 1)
Boundary openness (4.03454e-16 -3.30061e-14 -1.83681e-14) OK.
Max cell openness = 2.82278e-16 OK.
Max aspect ratio = 3.30557 OK.
Minimum face area = 0.00414729. Maximum face area = 0.0173887. Face area magnitudes OK.
Min volume = 0.000417483. Max volume = 0.00138071. Total volume = 1842.17. Cell volumes OK.
Mesh non-orthogonality Max: 28.3981 average: 0.595392
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 0.817106 OK.
Coupled point location match (average 0) OK.

Mesh OK.

End



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

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

geometry
{
slope.stl
{
name slope;
type triSurfaceMesh;
}
cylinder.stl
{
name cylinder;
type triSurfaceMesh;
}


}
// Settings for the castellatedMesh generation.
castellatedMeshControls
{


maxLocalCells 800000;


maxGlobalCells 1000000;


minRefinementCells 10;


maxLoadUnbalance 0.10;


nCellsBetweenLevels 3;




features
(
);


refinementSurfaces
{
slope
{
level (1 3);
}
cylinder
{
level (1 3);
}
}

resolveFeatureAngle 30;



refinementRegions
{

}


locationInMesh (5.01 0.005 1.74);


allowFreeStandingZoneFaces true;
}

// Settings for the snapping.
snapControls
{

nSmoothPatch 3;


tolerance 3.0;


nSolveIter 30;

nRelaxIter 5;


nFeatureSnapIter 15;


implicitFeatureSnap false;


explicitFeatureSnap true;


multiRegionFeatureSnap false;
}

// Settings for the layer addition.
addLayersControls
{

relativeSizes true;

// Expansion factor for layer mesh
expansionRatio 1.0;


finalLayerThickness 0.3;

minThickness 0.25;

layers
{
}

nGrow 0;

featureAngle 60;

slipFeatureAngle 30;

nRelaxIter 10;

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 1.7.x! 90 degrees corresponds to 130
// in 1.7.x.
minMedialAxisAngle 90;

// Create buffer region for new layer terminations
nBufferCellsNoExtrude 0;
nLayerIter 50;
nRelaxedIter 20;

meshQualityControls
{
// Maximum non-orthogonality allowed. Set to 180 to disable.
maxNonOrtho 65;

// Max skewness allowed. Set to <0 to disable.
maxBoundarySkewness 20;
maxInternalSkewness 4;

// Max concaveness allowed. Is angle (in degrees) below which concavity
// is allowed. 0 is straight face, <0 would be convex face.
// Set to 180 to disable.
maxConcave 80;

// Minimum pyramid volume. Is absolute volume of cell pyramid.
// Set to a sensible fraction of the smallest cell volume expected.
// Set to very negative number (e.g. -1E30) to disable.
minVol 1e-13;

// Minimum quality of the tet formed by the face-centre
// and variable base point minimum decomposition triangles and
// the cell centre. This has to be a positive number for tracking
// to work. Set to very negative number (e.g. -1E30) to
// disable.
// <0 = inside out tet,
// 0 = flat tet
// 1 = regular tet
minTetQuality 1e-9;

// Minimum face area. Set to <0 to disable.
minArea -1;

// Minimum face twist. Set to <-1 to disable. dot product of face normal
// and face centre triangles normal
minTwist 0.05;

// minimum normalised cell determinant
// 1 = hex, <= 0 = folded or flattened illegal cell
minDeterminant 0.001;

// minFaceWeight (0 -> 0.5)
minFaceWeight 0.05;

// minVolRatio (0 -> 1)
minVolRatio 0.01;

// must be >0 for Fluent compatibility
minTriangleTwist -1;

//- If >0 : preserve single cells with all points on the surface if the
// resulting volume after snapping (by approximation) is larger than
// minVolCollapseRatio times old volume (i.e. not collapsed to flat cell).
// If <0 : delete always.
//minVolCollapseRatio 0.5;

// Advanced

// Number of error distribution iterations
nSmoothScale 4;
// amount to scale back displacement at error points
errorReduction 0.75;

// Optional : some meshing phases allow usage of relaxed rules.
// See e.g. addLayersControls::nRelaxedIter.
relaxed
{
//- Maximum non-orthogonality allowed. Set to 180 to disable.
maxNonOrtho 75;
}
}

// Advanced

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

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

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

scale 1;

vertices
(
( 0.0 0.0 0.0)
( 54.0 0.0 0.0)
( 54.0 5.0 0.0)
( 0.0 5.0 0.0)
( 0.0 0.0 8.0)
( 54.0 0.0 8.0)
( 54.0 5.0 8.0)
( 0.0 5.0 8.0)
);

blocks
(
hex (0 1 2 3 4 5 6 7) (540 50 80) simpleGrading (1 1 1)
);

edges
(
);

boundary
(
inlet
{
type patch;
faces
(
(0 4 7 3)
);
}
outlet
{
type patch;
faces
(
(1 5 6 2)
);
}
ground
{
type wall;
faces
(
(0 1 2 3)
);
}
top
{
type patch;
faces
(
(4 5 6 7)
);
}
sides
{
type patch;
faces
(
(0 1 5 4)
(3 2 6 7)
);
}
);

mergePatchPairs
(
);

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

[aow]

At a glance, your setup looks okay and the mesh quality metrics don't look bad either (both max skew and max non-orthogonality are reasonably low), but maybe you could execute "checkMesh -allGeometry -allTopology" instead of just "checkMesh", which gives additional info and could reveal other problems with your mesh.

Also, I have actually simulated a very similar problem to the one you're working on and found that even though checkMesh looked okay, the cylinder-bottom boundary interface looked really ugly (i.e. not at all a smooth intersection of the two objects). I would take a look at this region of your mesh using ParaView to see if this is the case as well as all around the pile to make sure there isn't anything weird going on.

If the pile-bottom boundary intersection is an issue, one thing you can do to try and get around this is to use the surfaceFeatureExtract utility on your .stl files and then use the features option for refinement in snappyHexMesh. I noticed you don't have this in your snappyHexMeshDict so you could try it to see if it reproduces the pile and bottom boundary surfaces more accurately than without it enabled, which would lead to better force results.

Perhaps you have not refined enough to match the pile surface accurately? I noticed your initial cell size from blockMeshDict is 0.1 m, whereas the diameter of the pile is 0.7 m. Even though you're allowing up to 3 levels of refinement from level 0, the surface you end up with may still not be as close to being circular as it ought to be. Also, if you don't provide enough refinement levels when using snappyHexMesh, you can run into situations where even though you get a qualitatively exact surface in your mesh compared to the .stl file you end up with incorrect dimensions (i.e. too large or small of a diameter in your case) since the cells cannot be split enough to reach the location of your .stl surface so snappyHexMesh does the best it can and leaves you with a surface that looks correct, but is incorrectly sized (this eluded me for several months during my PhD work and addressing this issue was one of the keys to getting accurate forces compared to experiments).

Finally, you still have not explained at all what was strange about the forces/moments you were getting... knowing what's wrong would probably help reveal the problem

[renos]

Dear Aow,

Thank you for your replay. The reason that in the blockMeshDict cells are 0.1m, is that I am trying to verify from an article with the same conditions some results like surface elevation/velocity and forces. Surface elevation from my simulation is very close to the article but forces are about 50 % of that in the article but they have the same shape. I don't know, what else to do in order to have the correct results.

Kind regards,

Renos

[aow]

Hey Renos,

That's strange you're so far off, especially if you're attempting to replicate someone else's modeling results. To which journal article are you referring? I am curious to look at it and see what their approach was for modeling this problem.

Andrew

[Phicau]

Originally Posted by aow

Hi Renos,

Without some details concerning more specifically what is wrong with the force/moment results you're getting as well as simulation setup (i.e. domain geometry, mesh setup, solution setup, etc...) it's a bit hard to take a stab in the dark to guess what's going wrong for you.

Concerning your setup of the force recording function object, it looks correct to me. Just make sure that your "CofR" (i.e. center of rotation) is where you want it (i.e. at the bottom center of your pile) to get the moment values you're expecting since the moment arm for calculating these results is taken to be the distance between the CofR and the center of pressure through which a resultant force acts. The forces will not change regardless of what CofR you specify as one should expect.

My gut instinct for a problem like you're doing is that the mesh probably has some poor quality cells somewhere that are messing up your solution. In particular, I would be curious to know how you meshed around the cylindrical pile. If you're relying on snappyHexMesh to perfectly fit the cylinder into a mesh created by blockMesh, you'll probably get some bad quality cells, especially near regions where your pile intersects a boundary. To avoid such issues, take an approach like the one shown in this video using only blockMesh to get vastly improved results and also a meshing setup that is scalable should you want to perform a refinement study to see if your forces converge.

Hi Renos,


this excellent answer by Andrew (thanks!) and his follow-ups condense most of the things that you need to be aware of and can go wrong when performing this sort of simulations.


Having said that, I don't see any obvious mistakes here except for one in snappyHexMesh. If you read the log carefully you will see the error: "No cells marked for refinement since reached limit 1000000."


Now, this is difficult to catch, but if you check your mesh after being created, which you must, you will miss the additional refinement that you were asking for. The solution is simple, make the values for maxLocalCells and maxGlobalCells much larger in snappyHexMeshDict.


I would like to stress that you should also run a mesh convergence test on your case.


Best,


Pablo

[aow]

Good catch Pablo! I used to do this a lot when I was starting out and have forgotten about it being a common problem.

Renos,

I just wanted to stress that using roughly 2,000,000 global cells (your blockMeshDict gives 2,160,000) is a bit small of an amount, especially for a 38 m long, 5 m wide, 8 m tall domain; your mesh resolution might be poor and you may not be able to represent waves well depending on their amplitude let alone wave impact phenomena at the pile.

When simulating a similar scale problem, I was setting the "maxLocalCells" (i.e. the per processor amount) to 1,000,000 and "maxGlobalCells" 20,000,000 in my snappyHexMeshDict, which were overkill since my resulting number of cells was in the range 5,000,000 to 10,000,000. I used uniform mesh grading (see the user guide sections "5.3.1.3 The blocks" and "5.3.1.4 Multi-grading of a block") to reduce the cell size gradually in the x direction near my test structure and then increase the cell size again beyond the structure. You can do the same thing in the vertical direction centered about the region where you expect waves to pass through (i.e. from wave troughs to peaks). However, I would advise against doing this in the y direction since it can result in locally non-physical wave heights and velocities if the cell size changes too much.

[renos]

Thank you very much both Pablo and Andrew for your useful advice. I will try to simulate breaking waves with better discretization!

Kind regards,

Renos

[philiplu]

hello, Phicau,

a simple question:

generally a turbulence model shall be 3D, but specific in an incident wave normal to shore, it's 2D issue.

so if/how possible in ola:
to define e.g. the "front", "back" as "empty" in a turbulence wave model?,
i.e. spare simu in y-dirction (thus reduce the related simu-overhead as can be done in laminar simu)?


thank u in advance

[renos]

Dear Andrew and Pablo,

Hope, that you have a great weekend,

First of all thank you for your useful advice.

Although, I had refined the mesh with a lot of cells, I have the same problem in the force estimation. Maybe is something else in the FvSchemes and FvSolutions files?

I used the K-omega SST model for the wave breaking interactions with a monopile.Here are the files that I had used.


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

ddtSchemes
{
default Euler;
}

gradSchemes
{
default Gauss linear;
}

divSchemes
{
div(rhoPhi,U) Gauss linearUpwind grad(U);
div(phi,alpha) Gauss vanLeer;
div(phirb,alpha) Gauss linear;
div(((rho*nuEff)*dev2(T(grad(U))))) Gauss linear;
div(phi,k) Gauss upwind;
div(phi,epsilon) Gauss upwind;
div(phi,omega) Gauss upwind;
}
laplacianSchemes
{
default Gauss linear limited 0.5;
}

interpolationSchemes
{
default linear;
}

snGradSchemes
{
default limited 0.5;
}

wallDist
{
method meshWave;
}
// ************************************************** *********************** //

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

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

pcorr
{
solver PCG;
preconditioner DIC;
tolerance 1e-6;
relTol 0.1;
}
pcorrFinal
{
solver PCG;
preconditioner DIC;
tolerance 1e-7;
relTol 0;
}


p_rgh
{
solver PCG;
preconditioner DIC;
tolerance 1e-6;
relTol 0.1;
}

p_rghFinal
{
solver PCG;
preconditioner DIC;
tolerance 1e-7;
relTol 0;
}

"(U|k|omega)"
{
solver PBiCG;
preconditioner DILU;
tolerance 1e-6;
relTol 0.1;
}

"(UFinal|kFinal|omegaFinal)"
{
solver PBiCG;
preconditioner DILU;
tolerance 1e-7;
relTol 0;
}
}

PIMPLE
{
momentumPredictor no;
nOuterCorrectors 1;
nCorrectors 3;
nNonOrthogonalCorrectors 0;
}

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


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

[arashghgood]

Dear Pablo
first of all, thanks for helping me. based on your suggestion my problem solved by correct meshes.
I have more questions.

How can study my olaFlow case, in the moving reference frame in OpenFoam?
my case is a wave travels through the tank as you may remember it.

how can I groovyBC? I mean that in your tutorials the boundary's type are set. if I change them to groovyBC, it seems that olaFlow does not work.

[Phicau]

Hi Philip,


yes, it is possible to run RANS turbulence modelling in 2D. Check out the breakwater tutorial to see how it is set up.


Hi Renos,


that is strange, I have just finished a similar project and wave-induced pressures at a cylinder are spot on for me, so I would expect that forces need to be too. Maybe a stupid question, but worth checking: have you measured the incident wave conditions to ensure that you are getting the wave height that you expect?


Hi Arash,


I am not aware of any implementation to simulate waves in moving reference frames in OpenFOAM.
To use groovyBC, or any other external libraries, you need to include then dynamically in controlDict, in a similar way as shown here: https://openfoamwiki.net/index.php/C...ary_Conditions


Best,


Pablo

[philiplu]

Hello, Phicau,
many thanx.

so u mean, handling 2D-RANS Simu, Ola is same as that in OF, i.e. default or explicit define a "D" as empty.

but is possible to get LES run in 2D-wise?
since specifically for waves normal to shore, including a "D" parallel to shore puts partial computer resources to aspect less important


thank u and in advance, u a nice weekend