General workflow to create a flawless mesh in cfMesh
 

Hi there foamers,

I want to know in general, how should we deal with errors or warnings when cfMesh notifies us (during meshing process) or when you use checkMesh syntax of openFOAM. My geometry is a little bit complex and contains several .stl files and I have used special settings for some parts to make refinements within my meshDict. When I run cfMesh, it automatically generates a folder called "sets" (attached as sets.zip) in my "$caseFile/constant/polymesh" folder which contains "badCells,
badFaces, invalidBoundaryLayerCells, invertedBoundaryPoints, nonAlignedEdges, nonOrthoFaces, skewFaces, upperTriangularFace, wrongOrientedFaces and zeroVolumeCells" files. And of course within each, you may find the exact address of the cells which are problematic and you may track them also with paraview to see which parts are problematic for cfMesh. But how can I remedy them based on the notifications of either cfMesh or checkMesh, is the question. I have generated two log files as outputs of cfMesh and checkMesh so that you can have a feeling of what I'm saying (they are attached in log.zip).

I also have asked another question which was NOT answered so I might ask it in this post again :). cfMesh gives us different results each time you run it ! I noticed this in particular when I generated mesh and checked the number of badCells then I deleted polymesh folder and re-run it again and this time I got different number of badCells! this happens for the same version of openFOAM and even if you use another version of openFOAM you will have different results for the same case (in my case I used OF5.0 and OF1712).

I am using OF1712 and the latest version of cfMesh.

Thanks for your precious help :)

Hi,

I also noticed that cfMesh gives different results when ran several times. There are random functions in the source code that you can find with grep... I agree it is a bit scary but results are quite consistent, most of the time a bad mesh will remain a bad mesh, and a good mesh will remain a good mesh.

Regarding the workflow, here's what's working for me.

- Generate a detailed enough stl from salome/freecad etc... The default export settings from CAD softwares are NOT good enough, and sometimes you have to mesh the surface and export it. Several 100 of Mo is not uncommon as an input stl.

- Split your input surface in a single stl where you want cfmesh to catch a feature accurately : trailing edges etc... Then you can join them with renameBoundary by using a wildcard.

- A constant refinement is always better, but can be undoable in some geometries.

- Use additionalRefinementLevels rather than boundaryCellSize and minCellSize.

- Use optimize option in boundary layer

- De-feature or increase refinement level where cfmesh gives bad quality cells

- Eventually if all else fails, you can extract the surface from a bad quality volume mesh generated by cfmesh, and use that surface as input to a new cfmesh generation. The surface mesh might be better and more waterproof than the previous one. This trick has worked quite well on really complex geometries for me in the past.

Good luck !

Hi there Benn

* First and foremost thanks for your detailed answer. But still your suggestions give rise to newer questions in my mind :D.

* here by saying "mesh the surface and export it" you mean the triangulated surface mesh of the .stl file ?


* here by saying "constant refinement" you mean a consistent refinement strategy ? cause we have two approaches for refinements in cfMesh 1. cellSize 2. combination of additionalRefinementLevels & refinementThickness

* and here for this last trick, you mean taking out the surface out of the generated volume mesh with foamToSurface/surfaceMeshTriangulate capability of Foam?

Hi Benoit,


I am getting an overall really good mesh. Thanks to your advice.

I am still getting nonOrthogonal faces at some parts where surfaces are deformed to preserve features. How can I de-feature those edges. I am using fms format as the input.



Thank you

Sorry guys for the late reply, I didn't see your messages.



No, I mean use your CAD software to mesh your object, and then export the surface mesh to stl




I mean having a single value for additionalRefinementLevels



Exactly

Very often octree meshers will make a better mesh when they do not have to follow edges precisely - even though that is not always true. Typically trailing edges are easier to mesh when you let it be a little jaggy... But at the cost of geometric accuracy.


If you want cfmesh to not folow these edges, you need to generate the fms as a single surface, or remove the feature edges. This is strongly dependent on your workflow. If you convert it from a stl you just to need to merge all parts in the stl file, and not run surfaceFeatureEdges. If you just want some of the edges you can use the options from surfaceFeatureEdges, like -angle.

Thank you for your interest on the issue,



I am simulating the flow inside the vehicle cabin, hence the geomtery is complex. The workflow I am following is, I merge all the stl file and run surfaceFeatureEdges to get the fms file. Hence it is difficult for me to delete feature edges.



I dont think reducing the angle helps. Have you tried providing multiple input surface files for the cfMesh?


Is there any possibility to reduce nonOrhofaces using improveMeshQuality tool?

Try increasing the angle. Maybe 179 wil be ok. That way you'll take less edges into account. Ultimately you can try NOT running surfaceFeatureEdges.

Thank you Benoit, I will try that.

Can we use edge refinements in these regions? Or even surface refinements as mentioned in few of the previous threads also in the user manual.

Hi Metikurke,
In my experience, bad cells occurs while retaining the features because there are not enough cells to capture the feature. As you stated, You can use edge refinements. Even better, extract surface from input surface using paraview where cells are insufficient and give surface refinements.


For some of the patches, enabling 'keepCellsIntersectingPatches' reduced the number of bad cells for my case. I think it works similar to increasing tolerance in snapping stage of snappyHexMesh.

True, as the geometric detail increases the number of bad cells increases. I will try 'keepCellsIntersectingPatches' once again. In my previous meshing keepCellsIntersectingPatches took too much time than usual for mesh generation.

This is a little bit of a late reply, but haven't been on the forum in a while. Sorry!

I have used cfMesh for quite a long time with lots of success. In terms of my meshing workflow it looks like this:

1. Generate a STEP, or BREP of the fluid domain. This usually entails a boolean subtraction in whatever CAD software I am using and then exporting.
2. Load the STEP into SALOME. In the geometry module use: New Entity -> Group -> Create Group . With this you can select and name all of your surface boundaries. Additionally you can name surface boundaries for refinement.
3. Run the "extractFeatureEdges.py" salome script provided with cfMesh. (select your geometry, press ctrl-t, and select the script).
4. Go to the mesh module. Here, simply create a surface mesh of the domain. I either use Mefisto for the 2D and wire discretization with adaptive spacing, or you can use Netgen 1D-2D with default settings. It depends on your geometry how good the result will be.
5. Load your boundaries from the geometry module into the mesh module (Mesh -> Create Groups From Geometry). Then select the boundaries you created in the geometry module. Make sure you include the edges. cfMesh needs these.
6. Finally, export your surface mesh, boundary information, and edges into an FMS file using the python script "salomeTriSurf.py". Again this is provided with cfMesh. First load the script (ctrl-t, select the script). Then in the python shell, type: triSurf().writeFms('FluidDomain.fms'). This will be output in your Salome folder.
7. Copy the FluidDomain.fms to your case file and refer to it in your meshdict.

The fms file contains all of your boundary information, the edges, and the geometry info. This also lets you use the Salome GUI to select groups of faces for boundaries. This is super helpful if you have a large number of faces. You can leave the faces you created for refinement specifications as separate patches, or you can rename them in using the meshDict.

Hopefully one of you finds this useful!

Thanks for your very useful and well explained process.

Are you able to provide a bit more information regarding:
- The version of Salome you are using, and
- the OS/distro you are using?

I ask as I have tried to follow these steps using Ubuntu 18.04 and Salome 9.2.0 but am greeted with errors when running the .py scripts. They seem to be trivial syntax errors.
From an initial interrogation the scripts were produced for a much older version of Salome and Python, but have not been updated.
How do you get around this?

Thanks,
Tom

P.s. I don't suppose you have any involvement with this (rather useful) website? The process is near identical. https://curiosityfluids.com/2019/02/...-your-meshing/

Currently, I use Ubuntu 16.04 and I just looked and my installed version of Salome is 8.5 . I will try to update my version of Salome and see if I can get the process to work.

And yes! That's my website. I have recently added it to my signature.

Yes. It looks like Salome has migrated from python 2 to python 3. This is why there are syntax errors. There are a couple options: use Salome 8.5 , or you can use the python 2to3 command to change the script version compatibility (i haven't tried this yet, but probably will). I'll post here if I have any issues.

Hi Schuyler,

Many thanks for that information. Was good to know I only had to revert back one version of Salome to find Python 2 support. I did try python2to3 but in the end it was easier to install the additional dependencies for Salome 8.5 into Ubuntu 18.04.

Pleased to say my test model worked very well indeed! Appreciate your help.
Tom

I'll upload 9.2 compatible version of the script in a bit. It should run on both windows and Linux, but test it out as I'm not a Windows fan, especially python-wise..

I attached two Salome 9.2 compatible scripts.

The first one is just a conversion with same features. Tested on linux but using newline statement it should be fine on windows too. Try it out.

Keep in mind that windows' created fms are still linux-only compatible because of "\n" newline sequence.

If you need to run cfMesh under windows, just substitute all:
with
This was made because "wb" won't work under python 3.

The "v2" script has a very small feature. It checks if face group's name starts with "W_" for walls and "P_" for patches and changes boundary types accordingly, trimming the first two string chars.

You name your groups something like:
W_wall, W_shell, P_inlet, P_outlet
and you get:
wall (as wall), shell (as wall), inlet (as patch), outlet (as patch)

If you don't use this convention, the scripts works normally (all groups are type wall)

Obviously this can be done with meshDict, but I'm lazy.

I would make some small improvement if there is anything usefull you would like (like calling regex "control code" as method's arguments or auto-sense os type)

I'm not a developer so I don't care much about style or efficiency.
bye

EDIT: Fixed v2 script[indentation missed]

I forgot to mention featureEdges. I don't know if it was already clear but you can call triSurf with a specific, sometimes useful argument: allEdges.
If you have geometries like the one I usually work on (let's say cylinder with surface holes) you want to treat almost all edges as features.

will do the trick.

Just for reference.