generate terrain mesh with many components
 

Hello all,

I am wondering if there is a way to generate a terrain mesh that has a terrain stl as the bottom of the bounding box (the bottom follows the terrain contour).

Also the stl geometry to be subtracted has many components because different cell size will be applied to each component. Is there a way to write it into the meshDict?

JT

Hey,
for sure you can do with snappy, so, in this case maybe snappy is better.


Otherwise, you have to create your solid domain in some CAD software and then use in CfMesh the solid domain as stl.


Another workaround is an original mesh with snappy, then use foamToSurface to create a stl file and then use CfMesh.


This should works

Thanks Carlo, I have solved this issue. In face, cfMesh can handle terrain stl, although I don't know how it work since I didn't define a point in mesh as in snappy. There was a leak on my stl terrain which caused the issue.

I have few more issues I hope you can help me.

I am generating mesh for pretty complex geometry. The output message reports a lot of warnings regarding non-ortho, high skewness and zero volume cells. They do in the end impact the CFD simulation, RANS or LES. Non-ortho and high skewness are in the range of 300-2000, and zero volume cells are around 50 - 100 in the end. How do you deal with those?

Another question is how to you capture the feature edges around the body? Lots of straight faces have edges like zigzag lines. I used surfaceFeatureEdges <in> <out> angle 20 to get a output vtk featureEdges. It seems not good enough.

Thanks a lot!

JT

Hi Junting Chen, It is always difficult to capture the exact geometry during meshing, when your object is so complex and has a lot off sharp edges. Although you can preserve every edge and patch using Salome or any other tool, at the end you need to create very small cells in those regions, which sometimes result in bad cells. Please think of simplifying your model as far as possible, de-featuring your model will dramatically increase the mesh quality. You can refer this link if you want to know more about capturing features using Salome https://curiosityfluids.com/2019/02/...-your-meshing/

Krao

Hey chen112p , the skweness would affect a lot your results, non-ortho a little less. You can use non ortho correctos in the fvSolution.


In the end, it is not the best.


Zero volume is quite always related to shitty stl file.
In which cad are you deisgning?
It would be better to import maybe in salome of freecad and then reexport.


During the mesh with cfMesh don't look to much at the warning.

Consider only the erro in checkMesh.

All stls were created in Rhino. I figured most of the bad cells were created when boundary layers colliding at corners. So i took the advice from Kmeti's link, commented boundaryLayers section in the system/meshDict first and run cartesianMesh; then create boundary layers with generateBoundaryLayers command.
I tried it and did receive much less bad cell (almost nothing in fact!), but I am not sure how to use generateBoundaryLayers command. Seems like it reads in the meshDict again because there is a something going on when I uncomment the boundary layer section. But the mesh generated still has no boundary layer as I checked from paraview. I haven't looked into the source code yet, thats probly what I am going to do. Can you drop me some hints on running generateBoundaryLayers?

Also it seems improveMeshQuality can help, but I haven't tested it. My geometries are indeed quite complex.. such as thin shell, concave corners...

Thanks for the help!

Thanks Kmeti, that's a very helpful link. I did see it before but not carefully. I found that tip where not creating boundary layer at first but run generateBoundaryLayer command after a mesh is created is quite interesting. Once I commented out the boundaryLayers section from the meshDict, bad cells did reduce to almost nothing. But can you give me some hint on running generateBoundaryLayers command? -help didn't really give me much information. Does it go into the meshDict again and look for boundaryLayers section? and how do you tell cfmesh at which boundary to create how many layers of boundary layer?

Thanks a lot!

JT

Hi Junting,

Good to hear that you made some progress, as you have mentioned you should comment out the boundary layer section part of the mesh dict and run cfMesh. After generating the mesh, you shoud go to the mesh dict and comment out the boundaryLayers section and then in terminal you should just type 'generateBoundaryLayers'. The mesh will read only that part and add layers into your mesh.

Maybe you have changed the name of the patches during the generation of mesh or you have wrongly defined the patch names. At the end of this post you can find a sample boundary layer definition.

Just be careful while using 'improveMeshQuality' after using it, checkMesh will give a warning that the upper triangles are not in order, you can overcome this by running 'renumberMesh'

May be if you de-feature your sharp edges they will vanish, because in reality these sharp edges are quite hard to produce also.

Go through the following example and you will clearly understand!

Please add reputation points if you have solved your problem, I will be thankful!

K. Rao

I didn't understand if you are using CfMesh or Snappy.
Sorry.
With Snappy, the best is to run buonadarylayer with 1 nofLayer and use refineWallLayer in order to increase the number of layers.


http://openfoamwiki.net/index.php/RefineWallLayer


with snappy, you can also use this tool: https://cfdfeaservice.it/index.php/2...snappyhexmesh/


but, I repeat, the best is to work with snappy, without boundary layer, use foamToSurface and then use cfMesh.


If you can provide a picture a the geoemtry can be better.


Thanks!

Thanks Kmeti and Carlo, these are helpful information.

Carlo: I have solved the terrain problem. Now the issue is the building geometries on the terrain. In fact, i noticed that buildings are the issue so I am using flat base. I have tried what you said: use blockMesh -> snappy -> cartesianMesh (no boundary layer). Up to this point, i agree the mesh is visually better than straight up doing cartesianMesh. Once I call generateBoundaryLayer function, the sharp edges at corners will be somehow chamfered. Also, I noticed that edges which are not aligned with xyz coordinates become messed up (zig-zaged), perhapes due to the boundary layer generation? Is that something you see? A bit of chamfer I guess is fine, but sharp edges are somewhat a key feature I am trying to maintain...

However, with all methods I have tried (some cases sharp edges are maintained, some got chamfered, with boundary layer mesh or without), pimpleFoam always break / diverge. With the same setup, snappyHexMesh converges pretty easily.

One thing I might did wrong. In the section of renameBoundary section in meshDict, although newType patch was given to inlet / outlet, they are always set as defaultType (wall), which will be reflected in constant/polyMesh/boundary after the mesh generation. So I have to manually change the boundary condition of inlet and outlet to patch in constant/polyMesh/boundary. Is something I should do?

Thanks again, Kmeti and Carlo!

Hi,

You can use renaming as mentioned below, instead of newType use type.

If you have given the patch name wrong or you want to change the type to AMI or cyclic, define those changes using 'createPatchDict' instead of doing it manually

Hey Chen, this is an example of changeDict:
/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 6 |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ M anipulation | |
|*---------------------------------------------------------------------------*|
| File created by Carlo Pasquinucci for Tecnohit S.r.l |
| www.tecnohit.it info@tecnohit.it |
\*---------------------------------------------------------------------------*/



FoamFile
{
version 2.0;
format ascii;
class dictionary;
object changeDictionaryDict;
}

//dictionaryReplacement
//{
boundary
{
"In.*"
{
type patch;
// inGroups 2 (inlet);
}
"Out.*"
{
type patch;
// inGroups 3 (outlet);
}
"Symm.*"
{
type symmetry;
// inGroups 4 (symmetry);
}
}

you can find the file here : https://github.com/Carlopasquinucci/ShareOpenFOAMFile




Second, with cartesianMesh you can create a very nice boundayLayer. You don't need to use generateBoundaryLayer function.


If you want, can you share the geoemtry (stl) file? If it not to heavy (1 milion - 10 milion of cells), I would like to mesh it.

Thanks Kmeti, that works now! but still simulation is difficult to converge (easily diverged).

My meshDict for flow past a single rectangular box looks like this:


/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | cfMesh: A library for mesh generation |
| \\ / O peration | |
| \\ / A nd | Author: Franjo Juretic |
| \\/ M anipulation | E-mail: franjo.juretic@c-fields.com |
\*---------------------------------------------------------------------------*/

FoamFile
{
version 2.0;
format ascii;
class dictionary;
location "system";
object meshDict;
}

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

surfaceFile "/constant/triSurface/singleBlockBox_fe.stl";

maxCellSize 8.0;

//boundaryCellSize 3.0;
minCellSize 0.2;

surfaceMeshRefinement
{
singleBlock.stl
{
additionalRefinementLevels 3;
surfaceFile "constant/triSurface/singleBlock.stl";
refinementThickness 1;
}
}

edgeMeshRefinement
{
singleBoxEdges
{
edgeFile "constant/triSurface/singleBlock_featureEdges.vtk";
additionalRefinementLevels 4;
refinementThickness 0.1;
}
}

objectRefinements
{
//outer box
refineOuter
{
type box;
centre (0 0 20);
lengthX 100;
lengthY 60;
lengthZ 40;
additionalRefinementLevels 2;
}

}


boundaryLayers
{
optimiseLayer 1;

// Untangling of boundary layers
// Works on negative volume cells created
// during layer addition
// Activate 1 or deactivate 0
// Default value is 1
untangleLayers 1;

// No idea what this does, but it's a thing
symmetryPlaneLayerTopology 1;

patchBoundaryLayers
{
singleBlock
{

nLayers 3;

thicknessRatio 1.5;

maxFirstLayerThickness 0.3;
}
bottom
{
nLayers 3;

thicknessRatio 1.5;

maxFirstLayerThickness 0.3;
}

}
}
optimisationParameters
{
// number of iterations in the procedure for
// redciting normal vectors
// in the boundary layer (optional)
// Default value is 5
nSmoothNormals 5;


// number of iterations of the smoothing procedure
// optional
// Default value is 5
maxNumIterations 20;

// Ratio between the maximum allowed layer thickness
// and the estimated feature size
// Used to limit layer thickness in regions
// dominated by curvature (optional)
// Value ranges between 0 and 1
// Default value is 0.3
featureSizeFactor 0.3;

// activate 1 or deactivate 0 calculation of normals
// (optional)
reCalculateNormals 1;

// Controls the maximum difference of the
// layer thickness between two neighbouring points
// divided by the distance of the points
// lower values enforce uniform thickness distribution
relThicknessTol 0.1;

// active 1 or inactive 0
// No idea why you would ever set this to 1
allowDiscontinuity 0;
}


renameBoundary
{
defaultName fixedWalls;
defaultType wall;

newPatchNames
{
xMin.*
{
newName inlet;
type patch;
}

xMax.*
{
newName outlet;
type patch;
}
yMin.*
{
newName south;
type wall;
}
yMax.*
{
newName north;
type wall;
}
zMin.*
{
newName bottom;
type wall;
}
zMax.*
{
newName top;
type wall;
}
OBJECT.*
{
newName singleBlock;
type wall;
}
}
}


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

The geometry is extremely simple.. but still, pimpleFoam breaks all the time. Only once it didn't, but takes a long time to converge. Do you see anything fishy in the setup? With this meshDict, I ran generateBoundaryLayers after cartesianMesh. I tried both methods: generateBoundaryLayers separately or generate boundary boundary layer during cartesianMesh. Simulation still breaks very easily.

Thanks Carlo, please find the stl files in the attachment.

I am basically testing the performance of cfMesh, so currently I am only running relatively simple geometries. One is the most basic geometry which is a single rectangular block (singleBlock.stl) in the fluid domain. The other one has few ramps, edges unaligned with x/y/z coordinate, concave corner joining 3 patches. Although the mesh files I created looks very neat and checkMesh doesn't complain, pimpleFoam never found a easy converge (mostly diverge) for some reasons.

In the STLs.zip, files with file names end with *Box_fe.stl were created by:

surfaceGenerateBoundingBox xyz.stl xyzBox.stl xMin xMax yMin yMax 0 zMax
surfaceFeatureEdges xyzBox.stl xyzBox_fe.stl -angle 30

This is what I usually do to capture the feature edges along with the surface patches in one STL. xyzBox_fe.stl is used in meshDict as my surfaceFile.

Also, I would call:

surfaceFeatureEdges xyz.stl xyz_fe.fms -angle
FMSToSurface xyz_fe.fms xyz.vtu -exportFeatureEdges

to generate a file xyz_featureEdges.vtu which contains only feature edges and used in meshDict to refine those feature edges (edgeMeshRefineMent). This seems to be the best way to deal with feature edges I found so far.

Also, I attached a zip file called completeSettings4Pimple which contains all the Foam folders for my pimple run, just in case you want to do a quick pimple run.

Thanks a lot for your help!

Junting Chen

I checked the geometry and I have only three tricks to suggest you.

1) convert your stl in fms. I think that the command is surfaceToFMS . CfMesh works better with FMS.

2) I saw that the box is exactly with the same dimension of the internal geoemtry.
The main problem is that you have some part of the zMin in common with the zMin surface of the block.
I attach two images..you shold have the second one triangolation.

3) It would be better to have a more dense triangolation, also if the surface are flat. Maybe you can use surfaceRefineRedGreen, but I'm not an expert of this command.

Did you run checkSurface and checkMesh?
The quality is good?

Cheers.
I will try to run tomorrow or on the weekend

Thanks Carlo. I have made some progress on this single block geometry by restricting cell size on the boundary.

The bigger problem is the other geometry where it contains concave corner, surface unaligned with cartesian coordinates, and ramps (challenging feature edges). I have successfully run 1st order LES on it but 2nd order diverged very quickly. Seems bad cells are near the ramps.

Response to your suggestions:
(1) Sure, probably there is some improvement? I have tried ftr and fms. I can't really tell.
(2) The outer box was created by surfaceGenerateBoundingBox. The target geometry has to sit on the ground.. So you are suggesting me to subtract the geometry from the box first?
(3) I haven't tried that yet. Most error I have seen occurs at edges and corners. I can try it later..

Thanks again Carlo!

Junting