[seaspray]

Originally Posted by vonboett

dear all,

I had good experience with the refineWallLayerSmart utility, that just refines based upon the wanted y+ value.

It is an interesting concept and I have done quite a lot of incremental wall layer refinement myself as discussed earlier in this thread, for other reasons. I did generate y+ fields sometimes, but they weren't very well behaved around corners in the geometry.

As a result, I never tried to use y+ for wall layer refinement. I can easily imagine applications where it should work very well. One issue with refineWallLayer and its derivatives is the lack of assurance when it comes to cell quality. Sometimes it resulted in meshes that weren't usable for solving.

[bennn]

Originally Posted by pbachant

Right now the trailing edge is rounded off. Would you recommend making it flat, so there's a defined edge between it and the remaining foil surfaces?

On a side note, what CAD software do you use that allows defining separate solids? I am using SolidWorks, and it seems I can only create a single body.

The angle between the suction/pressure side and the TE is not relevant there, they just have to be defined as separate solids in the CAD file. rounded might actually be better, but I usually do flat TE.

I use Salome for my CAD, export each part as stl, sed the files in order to add the solid name, and cat them afterward.

[bennn]

Originally Posted by franjo_j

Hi everyone,

I am the author of cfMesh, and I want to thank you for trying the tool.
From my experience, boundary layer meshing is quite difficult, and it depends a lot on the quality of the input geometry. The problem get worse as the first layer get thinner. In cfMesh, there exists a possibility to specify an upper bound on the thickness of the first boundary layer. If you want to get Y++ value below a given threshold it is possible to calculate the first layer thickness as y = (Y+ * kinematicViscosity) / sqrt(shearSress). The rule of the thumb, the total thickness of the boundary layer is approximately equal to the cell size at the boundary.
cfMesh is agressive in getting rid of inverted face normals, high non-orthogonality and skewness, and it sometimes moves vertices inside the boundary layer to get rid of inverted faces. I would be grateful if you could provide me some cases and help to improve the layers further.
Regarding the anisotropic refinement, there are various possibilities to implement that feature. What is the preferred way of setting up an anisotropic interface? Primitive shapes (planee, box, etc)? Surface meshes?

Kind Regards,

Franjo

Dear Franjo, thank you again for the great tool, and for making it opensource.

I've never developped a mesher myself, but I always thought it was kinda backward to make the background mesh, and then try to add the BL.

Wouldn't it be possible to add the BL first by offseting the surface, and then grow a mesh around that ? Thanks for your input, and sorry if it is a silly question.

[seaspray]

Originally Posted by pbachant

On a side note, what CAD software do you use that allows defining separate solids? I am using SolidWorks, and it seems I can only create a single body.

I created my boundary meshes in Rhino3D, meshing each patch individually and exporting to a STL file. Then same as Benoit explained, rename the objects to reflect the patch names and append all the files together.
The drawback is that vertices along edges don't coincide. Using Salome as Benoit suggests sounds like a better pathway as meshing of the edges can be managed.

Otherwise, I found that the FFW/CAESES modeler is able to directly produce a correct STL output with patches for OpenFOAM by mapping geometry colours to STL solids. It is quite an amazing piece of software.

[franjo_j]

Hello Benoit,

Originally Posted by bennn

Dear Franjo, thank you again for the great tool, and for making it opensource.

I've never developped a mesher myself, but I always thought it was kinda backward to make the background mesh, and then try to add the BL.

Wouldn't it be possible to add the BL first by offseting the surface, and then grow a mesh around that ? Thanks for your input, and sorry if it is a silly question.

I agree, there are many possible ways of generating BLs, and all of them have their pros and cons. When offsetting the surface, you have to take care of the feature size at every location, and make sure that the surface does not get tangled anywhere. I am scared of meshing a void because it requires a lot of checking to be robust and stable. The approach in cfMesh takes the feature size into account implicitly, and it tries to generate the BL with the total thickness equal to the neighbouring cell size. The approach can be further improved and I plan to enhance it when I find the time.

Kind Regards,

Franjo

[bennn]

Originally Posted by franjo_j

Hello Benoit,

I agree, there are many possible ways of generating BLs, and all of them have their pros and cons. When offsetting the surface, you have to take care of the feature size at every location, and make sure that the surface does not get tangled anywhere. I am scared of meshing a void because it requires a lot of checking to be robust and stable. The approach in cfMesh takes the feature size into account implicitly, and it tries to generate the BL with the total thickness equal to the neighbouring cell size. The approach can be further improved and I plan to enhance it when I find the time.

Kind Regards,

Franjo

Thanks a lot for the input Franjo. I did understand from using it that the total thickness was somewhere close to the neighboring cell size, which is simplistic but if robust, very fine by me.

One of the main modification I'd do right now would be to have a bit more control on the background mesh, and especially start with an anisotropic blocking, that is refined isotropically. basically have initial cells that are not cubes. I'll try doing it myself when I have time, but I've not even looked at the code, so no idea how tough that would be.

[seaspray]

Originally Posted by franjo_j

Hello Benoit,

I agree, there are many possible ways of generating BLs, and all of them have their pros and cons. When offsetting the surface, you have to take care of the feature size at every location, and make sure that the surface does not get tangled anywhere. I am scared of meshing a void because it requires a lot of checking to be robust and stable. The approach in cfMesh takes the feature size into account implicitly, and it tries to generate the BL with the total thickness equal to the neighbouring cell size. The approach can be further improved and I plan to enhance it when I find the time.

Kind Regards,

Franjo

Dear Franjo,

I understand the temptation of tying the layers thickness to the local cell size, but this makes it dependent on local mesh refinement. In the case of feature-based refinement, it means that the mere proximity of a geometric feature causes the layers the shrink down in thickness.
Unfortunately, this behaviour is extremely unphysical because the boundary layer does not thin down at all in these regions. In fact, the presence of a feature would rather cause the opposite behaviour, an increase in BL thickness. This had led me to discarding entirely feature-based refinement in the sample case I had uploaded earlier, for the simple reason that good quality layers could not be obtained with it.

From a CFD point of view, the user must be able to generate either uniform layers around the geometry, or layers of a thickness that is based on some geometric function or previous physical calculation (i.e. some information about the local y+ value). The latter approach is fraught with risks and issues, but the first one is essential.

For this reason, I tend to support Benoit's earlier comment about layer generation and surface offsetting, because it would lead towards producing uniform layers. Some commercial codes clearly project a surface mesh through the layers space and then refine those cells in a direction normal to the surface. The BL is then made of stacked, identically shaped cells. Creases and ridges in the surface remain more problematic areas, but this is always the case. At least, in this instance the problem needs to be dealt with once when offsetting the surface and projecting the surface mesh, rather than each time a layer is added.

Viscous layers are only useful if they are of good quality, this is the main pitfall of SHM. As the physical boundary layer thickness only increases with distance along the flow lines in most applications, viscous layers must either remain constant in thickness or follow the physics. For these reasons, I am tempted to say that they must not be tied at all to refinement or feature sizes, but purely determined by an absolute distance from the surface or possibly some user-defined geometric function providing this distance.

Eric

[bennn]

Hi Eric,

Originally Posted by seaspray

I understand the temptation of tying the layers thickness to the local cell size, but this makes it dependent on local mesh refinement. In the case of feature-based refinement, it means that the mere proximity of a geometric feature causes the layers the shrink down in thickness.
Unfortunately, this behaviour is extremely unphysical because the boundary layer does not thin down at all in these regions. In fact, the presence of a feature would rather cause the opposite behaviour, an increase in BL thickness. This had led me to discarding entirely feature-based refinement in the sample case I had uploaded earlier, for the simple reason that good quality layers could not be obtained with it.

I definitely agree with you, however you can't be too demanding for automatic tool. And Hexpress, a widely used octree mesher, does exactly the same. I end up refining homogeneously where flow is critical.

[seaspray]

Originally Posted by bennn

Hi Eric,

I definitely agree with you, however you can't be too demanding for automatic tool. And Hexpress, a widely used octree mesher, does exactly the same. I end up refining homogeneously where flow is critical.

Benoit,

Very fair comment, but then let's view the matter from the other angle: as generating cell size related viscous layers in a mesh zone with variable refinement doesn't produce a useful result, then I would exclude this scenario and simplify the problem altogether: while the BL mesh thickness is still cell size related, it is constant size - no on-going sampling and thickness determination.

If viscous layers are specified, then uniform refinement is applied to the mesh surrounding the patch out to a distance of, say, 2 cells (I have used 3 to be safer while fighting with SHM earlier) and then the set of cells nearest to the surface is converted into the BL mesh as per current procedure and refined in a direction normal to the surface.

Several of the meshers I tested against my geometry were impressive and never produced wavy, collapsing viscous layers no matter what the input and meshing configuration was. What made them unsuitable was an inability to produce an anisotropic topology where needed as well. There are surprisingly few codes able to handle this combination of requirements.

Eric


PS: I have attached a screenshot of a converted Star-CCM+ cut cell mesh with 10 viscous layers and anisotropic refinement. Star-CCM+ starts with a base size specification and applies boundary and volumetric refinement/coarsening specifications to it. I can't say too much more, it is very early days. It is the best mesher I have tried by a very, very long way on this case.

The documentation mentions: "Before the core volume mesh is created, a subsurface is generated at the specified prism layer thickness values, in effect “shrinking” (for internal flows) or “expanding” (for external flows) the starting surface. The core mesh is built using this subsurface. The prism layer mesh is then generated by extruding the cell faces from the core mesh back to the original starting surface."

In other words, it does everything opposite to SHM and the layers originate from a refinement process. The thickness of the layers can be related to the base size specification or given as an absolute value.

[rgpeters]

Originally Posted by seaspray

I have uploaded here a stripped down test case showing how far I have got experimenting with cfMesh using the type of geometries I need to mesh.
Note the damaged hull boundary surface and uneven viscous layers. A smaller number of layers can prevent damage to the input geometry, but this would not be satisfactory for solving.

Controlling layers thickness seems to become more problematic if the cell size around the geometry changes; here I disabled automatic refinement near features and uniformly refined near the HULL patch to alleviate such issues.

Vertical refinement of the free-surface region is the other obstacle at present for pursuing. I have been considering schemes merging a cfMesh mesh around the hull with a blockMesh mesh with a refined free-surface for the rest of the domain, but I haven't progressed down this pathway and it would only be a workaround.

Still - it is not that far off the mark, cfMesh is only in its initial release state and only took two minutes to build the mesh!

Eric

I was bale to obtain very smooth boundary layers by making a few tweeks to cartesianMeshGenerator.C and recompiling. I basically made it so cfMEsh will create two 'initial' boundary layers. The second inital boundary layers comes out much smoother. To do so, find the generateMesh() function and find optimiseFinalMesh(). After there add an additional generateBoundaryLayers(); and optimiseFinalMesh();. In the optimiseFinalMesh() function, you must comment out "deleteDrivenData(octreePtr_);" or the second optimiseMesh will fail. You can then refine that second 'initial' boundary layer with the settings in meshDict.

From what I can gather looking at some the code:
generateBoundaryLayers(); creates a layer of cells halfway extruded to the nearest vertex.
optimiseMesh(); fixes issues in the mesh and make all the boundary cells around the same size as the surrounding mesh.

Franjo- Great work on cfMesh! Some suggestions- perhaps it might be worth adding something to meshDict to determine how many iterations of boundary layer treatment each patch will recieve? I can imagine some algorithm to vary boundary layer thicknesses on patches by doing different intervals and iterations of these functions with perhaps a way to control the .5 cell initial height in generateBoundaryLayers. For example- generateBoundaryLayers()
optimiseMesh();
generateBoundaryLayers()
refineBoundaryLayers()
generateBoundaryLayers.8initalheight()
refineBoundaryLayers2().

Just a thought.

Robert

[n719z]

Dear Franjo,

After fighting with snappy for weeks, yesterday I first tried your cfMesh and within
a few dozen tries was able to get beautiful looking meshes with neat boundary layers.
Kudos for a fantastic tool!

My problem now is that the solver settings that used to work without fail on snappy
meshes blow up all the time on cfMeshes, even trivially simple ones. I'm trying to do
external aerodynamics of small airplanes with simpleFoam, started from the notorious
motorBike tutorial for solver setup. I was wondering if you had any insight into why
this happens, and how I might try changing the meshing and/or solver parameters to
make solving more stable?

Thanks,
Diego

[franjo_j]

Hello Diego,

My experiences show that OpenFOAM does not like transition of cell sizes in regions of high gradient variation. cfMesh is designed to produce highly localised refinement zones, by default, so you may have coarse mesh in the regions of important gradients. What happens if you try to use refinementThickness option, to spread the refinement further into the mesh? This option is available in the 1.0.1 version released yesterday.

Regards,

Franjo

[n719z]

Originally Posted by franjo_j

My experiences show that OpenFOAM does not like transition of cell sizes in regions of high gradient variation. cfMesh is designed to produce highly localised refinement zones, by default, so you may have coarse mesh in the regions of important gradients. What happens if you try to use refinementThickness option, to spread the refinement further into the mesh? This option is available in the 1.0.1 version released yesterday.

Yea my gut feeling went in that direction too, I do typicaly use 4-5
nCellsBetweenLayers in snappy, that's the most striking visual
difference between the meshes. I did try out refinement surfaces
in 1.0.1 briefly, but my impatient conclusion was that the mesher just
gets stuck indefinitely (as in, 15 minutes ). I will take another more
patient shot at it tonight and report my findings.

Best,
Diego

[n719z]

I spent another evening trying to get to the bottom of this, and am none the wiser.

I don't think the p-solver divergence has to do with cfMesh mesh coarseness.
I tried meshing the entire volume with very fine uniform size cells and still get
the blowup with cfMesh.

The problem is quite odd. simpleFoam blows up only with the cfMesh, only if the
angle of attack is zero, and only if I run potentialFoam first.

I'm attaching two examples in case one of you wizards wants to tackle this one.
The "015.zip" is the problematic cfMesh case. Run "mesh" first, then run e.g.
./wind 80 0
in the "outputs/run-*/reproduce/" directory. This should result in a simpleFoam crash.

Any non-zero angle of attack, e.g. "./wind 80 0.001" results in convergence.

The "stl.zip" contains the minimal geometry I've been feeding it, a little tilted box.
The result is similar with a realistic wing geometry.

The "017.zip" is a similar snappy mesh that I never saw diverge.

In case that makes a difference, I'm on ubuntu 14.04, running 2.3.x cloned on
Dec 3rd and cfMesh 1.0.1.

Cheers,
Diego

[franjo_j]

Hello Diego,

My impression is that there is something wrong with the script. I could generate meshes by running ./mesh in both 015 and 017 cases. The mesh in 015 is Ok, according to checkMesh:

Checking geometry...
Overall domain bounding box (-0.729686 -1.32 -1.42818) (1.94293 1.32 1.24443)
Mesh (non-empty, non-wedge) directions (1 1 1)
Mesh (non-empty) directions (1 1 1)
Boundary openness (2.38299e-16 -1.27714e-16 6.2086e-17) OK.
Max cell openness = 3.25499e-16 OK.
Max aspect ratio = 2.7632 OK.
Minimum face area = 0.00479851. Maximum face area = 0.0126942. Face area magnitudes OK.
Min volume = 0.000389756. Max volume = 0.00123663. Total volume = 18.595. Cell volumes OK.
Mesh non-orthogonality Max: 27.6095 average: 1.76661
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 0.818953 OK.
Coupled point location match (average 0) OK.

Mesh OK.

Though, I am having problems starting the solver. Whenever I do ./wind 80 0 it generates a new case in the outputs directory, and it does not copy the mesh there. potentialFoam than fails with a message:

--> FOAM FATAL ERROR:
Cannot find file "points" in directory "polyMesh" in times 0 down to constant

From function Time::findInstance(const fileName&, const word&, const IOobject::readOption, const word&)
in file db/Time/findInstance.C at line 203.

We have went of the topic here. Please open another thread or feel free to send me a private message to resolve this issue.

Regards,

Franjo

[n719z]

Originally Posted by franjo_j

Though, I am having problems starting the solver. Whenever I do ./wind 80 0 it generates a new case in the outputs directory, and it does not copy the mesh there.

Ah sorry my writing was clear as mud.
Before running the "wind" script first change into the output directory
resulting from the "mesh" script, e.g. "cd outputs/run-*/reproduce/",
then the mesh ought to get copied yet another time into yet another
"outputs" subdirectory of that directory.

The reason I departed from the common "Allrun" scheme is I'm
running many meshings and solvers in parallel while attempting to
debug things, this way I can keep track of what ran on what mesh
with what actual inputs.

[student666]

Hi Franjo,

thanks for your meshing tool; I started using it today and actually I'm getting better results with it than with SHM.

Anyway, if you're going to upgrade it, can you please add following features?

1- possibility to set first layer height (absolute) as mandatory on BL creation
2- possibility to define a sort of volume of influence for small gaps

Request 2 is when you have to add layers in small gaps, sometimes it happens that cells are merged, so by defining a volume of influence ( sphere, torus, ecc..) layers have to squash instead of collapsing one into another.

One last question is:

How can you disable layer addiction on particular patches?

thanks a lot.

Best regards

[ssss]

Student666 you can use custom boundary layer parameters forma each patch using the boundary dictionary inside meshDict. Ser the documentatio about it in the cfMesh webpage. There is also a variable named keepIntersectedCells that may help your second feature.

Cfmesh would be one of the best automatic mesher if it could add more options to the boundarySize and lastCellThickness. It would also be better if it the boundary layer wouldnt be so jaggy. Because of this I use snappyHexMesh, but I really love the simplicity of cfMesh

[jdchakes]

Hey Eric

Very interesting thread!
I am also working in the marine industry in Auckland trying to push openFoam in my office, more commercial vessels rather than yachts.

Have you made any progress with this?
Using your method I still have trouble getting that first layer to reliably extrude. Have not tried this CFMesh yet.

Similarly related, I cannot get the openFoam utility yPlusRAS to work? From what I can tell it does not work on multiphase simulations, has anyone got this to work for ship hull analyses??

[seaspray]

Hello James,

In short, SHM is quite atrocious when it comes to generating multiple layers, but producing one is normally feasible as long as the surrounding mesh is uniform regular hex, so you need to devise a mesh refinement strategy that delivers this for a start.
Next issue is that refining that layer doesn't automatically preserve mesh quality, so it can be hit-and-miss. It is possible to set up the odd simulation, but I found the whole meshing problem unworkable overall in standard OpenFOAM.
Since cfMesh cannot perform anisotropic refinement at present (I assume it is still the case in v1.01 after reading the release notes, but I haven't actually tried again), it is not really usable for marine surface hydrodynamics.

The Salome meshers are very unreliable and simply can't produce this type of mesh anyway. Many commercial meshers I tried can't either, or will only do it through a rather time-consuming manual/visual process.
People working with marine hydrodynamics and OpenFOAM typically get their meshes somewhere else - for good reasons! Somewhere else includes some of the closed-source, licensable OpenFOAM meshers, like helixMesh owned by engys, who hired the original developer of SHM to finish the job properly.

I see cfMesh as the single most essential OF-related development taking place because a decent mesher is the missing piece for using OF in all applications where boundary layers are important, so I really hope Franjo keeps it open-source. I think that with a little more functionality, his code would directly compete with the best commercial automatic meshers available.

I generated y+ fields with OpenFOAM for multiphase flows, I just had to hack the case files as it complained about something missing for the second phase from memory. It was just a matter of adding what it was looking for.

I have moved my simulations to a different environment for now in order to get some work done and yes, I am usually also more interested in commercial vessels. I am interested in closed-loop design optimisation.