Proposal: add boundary layer meshing option to gmshing.

[linuxguy123]

I'm finding cfmesh and snappyhexmesh to be inadequate for my CFD needs.

People doing CFD work on parts with fine edges need a very fine mesh around these surfaces in order to get accurate results. While mesh refinement areas for cfmesh and SnappyHexMesh are great in certain use cases, it is very difficult to build a mesh from the outside in with sufficient fineness at the areas of concern on some models to get good results.

An example of this issue is the trailing edge of aircraft wings. While cfmesh can generate a somewhat fine grid on these areas, it does this at the expense of a huge number of mesh cells, very long meshing time and still a rather poor mesh outcome. SnappyHexMesh has the same issue.

Another hard to mesh item is heat exchanger fins.

This is about the best mesh I've been able to accomplish with cfmesh.

By contrast, this is what a really good aircraft trailing edge mesh looks like:

Gmsh is capable of generating boundary meshes of this quality and even better.

The surface cell width in this example was limited by the data points used to generate the profile. Had the user used a spline instead of discrete points, the cell width could have been finer. Gmsh allows one to specify the starting size of the cells used on the boundary, the number of layers and the size progression of the layers.

The FEM workbench uses gmsh as their primary meshing tool and already supports boundary layer meshing. I think that CfdOF should also support boundary layer meshing via gmsh.

I am thinking of adding gmsh boundary layer meshing to CfdOF.

Right now the CfdOF Mesh Object holds generic meshing parameters used by all the meshers.

By contrast, these are the mesh parameters for gmsh used in FEM.

I don't think we want to just add all the gmsh parameters to the existing mesh object parameter list. But I may be wrong. On the other hand, I don't want to tear apart a bunch of existing code and reinvent the wheel.

Thoughts, advice, ideas ?

Necessity is the mother of invention (development). I need to generate meshes for a bunch of CFD work, ASAP. I'm torn between implementing gmsh boundary layer meshing in CfdOF and trying to make the FEM mesher work with my CfdOF projects.

I look forward to your input.

[linuxguy123]

Should we have a different mesher object for each meshing tool ? One for each of gmsh, cfmesh and snappyhexmesh ?

I say this because the parameter list for each one is very different if we start enabling different options. As are sub mesh objects like refinement volumes, surface meshes, etc.

A generic mesher object has worked until now but use cases like enabling surface meshing for gmsh are going to break that compatibility. SnappyHexMesh has a lot of options too. Currently only a few are displayed for the user to use.

I could leave the existing CfdOF meshing code base alone and add a dedicated gmsher object as a trial. I should be able to borrow a lot of the code from the FEM workbench. If my trial works out, we can migrate the other meshers to their own mesh object later.

The other advantage to this approach is that the user could set up 2 different meshers for a project without losing the settings when changing back and forth between them. The user could select which mesh to use by changing the mesh object in the solver.

The other thing about changing to dedicated mesher objects is that in the future we could implement a dynamic mesher object, that generates dynamic meshes.

Thoughts ?

[linuxguy123]

If we create separate mesher objects for each mesh engine, why wouldn't I essentially copy the code for the gmsh engine from the FEM project ?

If I did that, how would I link their code (using git) so that their future changes happen in our code (automatically) ? Or would we manually copy the changes they make to their code into ours ?

I could fork the FEM project and rename it CfdOF-gmsh, for example. Then delete the unnecessary files from the project and pull the updates for the files we do use and never push back to their repo ? Does that sound like it would work ?

[linuxguy123]

The other mesher object we could add would be "Import" wherein the user could import an external mesh to use for analysis. For my present use case this would allow me to generate a mesh with the FEM mesher and then import it the CfdOF Analysis object to use with the solver.

The FEM project also has a Netgen mesher object. If we used their code base and used separate mesher objects for each mesh engine we would gain use of teh Netgen mesher.

[linuxguy123]

The other part of this equation is that the FEM workbench doesn't have access to cfmesh and snappyhexmesh yet. If we kept the mesher object the same such that it was back compatible with the existing FEM mesher objects and we converted the CfdOF cfmesh and snappyhexmesh meshers to the FEM mesher object type, they would gain cfmesh and snappyhexmesh.

Both the FEM and CfdOF workbenches have the same sort of meshing requirements. It is silly that each workbench is independently developing their own mesher object. The two workbenches should be working together to develop a single meshing code base that works with both applications.

Furthermore, there are many people who need to mesh objects that don't need CfdOF or FEM. Eventually a stand alone meshing workbench could be developed for these users. The output of that workbench, ie a mesh, could be used with the FEM and CfdOF solvers.

[linuxguy123]

The easiest thing for me to do right now is to write a CfdSolver_MeshImport and import a FEMMeshGmsh object.

In the future I think that the mesh tools between these two workbenches should be merged.

[linuxguy123]

[linuxguy123]

The FEM Gmsh mesher does 2 things that could work in this situation.

1) It creates a gmsh .geo file which we could theoretically run with the CfdOF gmesher. This geo file has the boundary mesh commands in it. 2) It creates a .unv mesh with the filename Part name + "__Mesh.unv"

OpenFoam is capable of converting .unv mesh files to foam format.

$ ideasUnvToFoam
Using: OpenFOAM-2206 (2206) - visit www.openfoam.com
Build: _8993af73-20221106 (patch=221104)

Expected 1 arguments but found 0

See 'ideasUnvToFoam -help' for usage

[me@workstation1 ~]$ ideasUnvToFoam -help

Usage: ideasUnvToFoam [OPTIONS] <.unv file>
Options:
  -case <dir>       Specify case directory to use (instead of cwd)
  -dump             Dump boundary faces as boundaryFaces.obj (for debugging)
  -doc              Display documentation in browser
  -help             Display short help and exit
  -help-full        Display full help and exit

Convert I-Deas unv format to OpenFOAM

Using: OpenFOAM-2206 (2206) - visit www.openfoam.com
Build: _8993af73-20221106 (patch=221104)
Arch:  LSB;label=32;scalar=64

My proposed solution to import a FEM mesh file is 1) locate the .unv mesh file that the FEM mesher created. I can do this by looking at the FEM workbench settings. 2) copy the .unv file to the local CfdOF working directory 3) convert the .unv file to the Foam format with $ideasUnvToFoam 4) put it in the meshCase directory, just like if was meshed by any other CfdOF mesher.

Does this sound reasonable ?

The only drawback is that the user has to run the FEM mesher first and then import the result with the CfdOF mesher. It would be nice to be able to call the FEM mesher from the CfdOF mesher, but I do not see a way to do that easily. Maybe if I dug deeper into the FEM code. Could probably do it with a macro call, but for now I'll make the user run the FEM mesher to generate the mesh and then the CfdOF mesher to import the mesh.

Thoughts ?

The other way to add boundary meshing with gmsh in CfdOF would be to add boundaries to the existing CfdOF gmsh mesher. The issue with this is that we are adding refinement layers for cfmesh and now boundaries for gmsh. And as far as I can tell neither cfmesh and snappyHM can do boundary meshing and gmsh can't do refinement zones.

Truthfully, it would probably be nice to have both... the ability to import a unv file as well as the ability to add faces for boundary meshes right in CfdOF.

Thoughts ?

[oliveroxtoby]

Do you know whether Gmsh can do boundary layers in 3D? Looking at the documentation https://gmsh.info/doc/texinfo/gmsh.html and going to the 'BoundaryLayers' keyword, it appears to be 2D only.

If that's the case I'm not inclined to put effort into adding it as a feature (although you are welcome to if you want to). Import of FEM mesh might be the way to go, but I think there is going to be some complexity in associating CFD boundary conditions with the existing imported mesh. The OpenFOAM utility surfaceToPatch might be helpful for that.

[linuxguy123]

Do you know whether Gmsh can do boundary layers in 3D? Looking at the documentation https://gmsh.info/doc/texinfo/gmsh.html and going to the 'BoundaryLayers' keyword, it appears to be 2D only.

I'm pretty sure it works for 3D as well. But even 2D would help with airfoils.

Turns out I'm not the first one to want this. https://forum.freecad.org/viewtopic.php?t=22968

Import of FEM mesh might be the way to go, but I think there is going to be some complexity in associating CFD boundary conditions with the existing imported mesh. The OpenFOAM utility surfaceToPatch might be helpful for that.

You are correct that one would have to align the surfaces to patches after importing the FEM mesh. That alone might make it easier to just add boundary layer meshing to gmsh in CfdOF.

I found a couple useful examples to help me. It doesn't look too bad - just a few additions to the .geo file.

https://www.iesensor.com/blog/2017/06/16/boundarylayer-setup-for-gmsh-3d-meshing/

https://www.cfd-online.com/Forums/openfoam-meshing/126563-boundary-layer-mesh-gmsh.html

It doesn't look too bad - just a few additions to the .geo file. I'll have to add a new refinement object for boundary layers, capture the parameters for the boundary, allow the user to select the edges or surfaces and add it to refinement list.

Importing a mesh in CfdOF has been mentioned before. The importing part is straight forward. Matching the FreeCAD surfaces to patches is less straight forward and a bit of a pain if the mesh didn't come from CfdOF.

[linuxguy123]

I am graphically challenged. Would someone care to make a workbench icon for the boundary layer mesh refinement ?

[linuxguy123]

Do you know whether Gmsh can do boundary layers in 3D? Looking at the documentation https://gmsh.info/doc/texinfo/gmsh.html and going to the 'BoundaryLayers' keyword, it appears to be 2D only.

You might be right about this. I am taking a closer look at it.

CfMesh will do boundary layer generation. http://www.wolfdynamics.com/training/CFMESH/cfmesh2017.pdf

Is it possible to specify this in the current version of CfdOF ?

I got this with surface refinement in CfMesh. It improved my results by a lot. I think it can be improved more.

[oliveroxtoby]

CfMesh will do boundary layer generation. http://www.wolfdynamics.com/training/CFMESH/cfmesh2017.pdf

Is it possible to specify this in the current version of CfdOF ?

Yes, both it and snappy can, through the mesh refinement object. There are examples in the 'examples' directory.

[oliveroxtoby]

Closing as this doesn't appear to be supported in 3D by gmsh.