View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001376||OpenFOAM||[All Projects] Bug||public||2014-08-19 05:34||2016-02-02 18:28|
|Platform||Unix||OS||Other||OS Version||(please specify)|
|Fixed in Version|
|Summary||0001376: Abysmal performance of snappyHexMesh is #1 obstacle to any serious CFD work with OpenFOAM today!!|
|Description||SHM layers algorithm is useless in virtually all real-world viscous flow cases. The abysmal performance of SHM in general is the key reason why OpenFOAM cannot be used for any serious CFD work, research or commercial today. Sorry. The solvers are excellent, but the meshes need to be created elsewhere within a commercial package.|
Parties offering CFD services based on OpenFOAM have developed unreleased meshers they license out at high cost, i.e. engys and their working version of snappyHexMesh aka helix-Mesh.
|Steps To Reproduce||Replace ship geometry in openfoam230/tutorials/multiphase/interDyMFoam/ras/DTCHull with yacht hull supplied here, increase viscous layers to 10 and try meshing - or any variant based on this.|
I literally spent weeks trying to create a workflow that would mesh this simple geometry properly with 10 quality viscous layers within 30mm from the body, and failed.
It is possible to get reasonable snapping, but layers collapse and regrow along the symmetry plane, or disappear completely, it is totally unreliable, there are way too many obscure parameters (nGrow!=0 for example only ever destroyed all my layers) and no usable mesh can be produced.
|Additional Information||I eventually implemented a workaround by growing one single layer of cells, feature refinement disabled to obtain a consistent thickness (viscous layers should not thin down and increase again following the surrounding mesh size, and NO, absolute layer thickness is NOT reliable) and then repeatedly called refineWallLayer to subdivide this layer. Problem is that the first layer from SHM is not great and then refineWallLayer doesn't care about cell quality.|
The solution was attractive, but SHM was still not robust enough and the whole setup collapsed as soon as I altered the background mesh or geometry.
Trying to grow consecutive layers in SHM is hopeless. Defects and problems compound rapidly and the process fails miserably. I suggest redesigning it as follow:
1/ offset the surface by the thickness of all layers
2/ snap to this surface
3/ extrude the surface mesh through to the geometry patch
4/ refine the cells in layers
This is how some of the best and most successful automatic meshers on the market operate and they produce perfectly even and consistent boundary layers.
We have had discussions about this with more context on:
SHIP.stl (1,856,307 bytes)
layers.png (20,887 bytes)
layers.png (20,887 bytes)
Thanks for the feedback. The shrinking procedure can have problems with large layer thickness v.s. cell size but the big advantage is that it is fully undoable so will likely produce something that obeys the mesh quality constraints.
What is your snappyHexMesh setup and blockMesh? I just did a quick snappyHexMesh run with a coarse mesh and get 10 layers (but no features) and pretty complete coverage (99.6%). (see layers around trailing edge in pic)
SHM-Hull.tar.gz (230,921 bytes)
DTC-Mesh-10-layers.png (188,826 bytes)
DTC-Mesh-10-layers.png (188,826 bytes)
Ok, I have attached the setup with the scripts building the mesh. I ended up taking as much of the processing away from SHM because it was so misbehaved. I build and refine the blockMesh, select cells sets and perform isotropic refinement around the geometry, extract features and snap with one call to SHM, then call SHM again to produce one layer. The only reason for the two SHM dictionaries was to allow me to get the snapping and features right and inspect this before going further.
Put the proximity refinement back into SHM, combine the snapping and layers dictionaries and grow 10 layers from there, removing the use of refineWallLayer etc.
Growing 10 layers around a damaged geometry in a uniform coarse mesh is not a real world case, it is play-meshing. No one is going to care whether it works or not. I took the DTC tutorial case again, increased the number of layers to 10, changed nothing else and meshed. A snapshot of the result is attached. It is a useless mess.
No matter what the process used to generate them is, viscous layers must have an even thickness, they must be continuous and they need to be reliable. This is not less important than mesh quality constraints, because running the solver is not the end game. The end game is good simulation results with good resolution of the boundary layers, good numerical results and no artifacts. It takes a clean, smooth and tidy mesh to do this and OpenFOAM is unable to produce one at present.
Meshers that successfully create such meshes don't grow consecutive layers from the surface as far as I have been able to see. I tried reversing the process using the scripts attached and it was a lot more successful, but still way too unreliable because of SHM.
I understand your frustration, particularly your comment "Parties offering CFD services based on OpenFOAM have developed unreleased meshers they license out at high cost, i.e. engys and their working version of snappyHexMesh aka helix-Mesh."
This is a good example why we started the campaign to see modified versions of OpenFOAM made publicly available:
Anyone who has modified code is entitled to release it publicly under the GPL. Anyone is free to campaign on the public's behalf.
OpenFOAM Foundation and CFD Direct
I tried to use SHM in an industrial environment with mixed success. There is, however, one thing I noticed; thin layer addition is mostly affected by those cells where the wall faces are warped. One can force creation of layers by disabling most quality checks during that phase and indeed get complete coverage, but then the solver will crash.
My hypothesis is that, once you have significant face twist on a wall, if you then extrude a very thin layer cell, all sorts of problems can occur with that cell, such as the cell center possibly being outside the cell volume itself. Cell quality will therefore suffer significantly, and it destroys either the mesh quality test or the solver later on if quality is ignored.
Would the following strategy perhaps solve anything: after the snapping phase, any patch faces that require layer growth get triangulated or split into less twisted faces if their twist is larger than a specified value (as a triangle has a twist of 0).
Also, looking at other code such as StarCCM+, I can see that the patch faces tend to get subdivided when twist is significant. Unfortunately I do not understand the code well enough to be able to contribute directly, but I would be willing to test any improvements.
This is a very interesting observation. My input geometries were typically STL data, so triangulated by definition. Twisted faces would be produced by the intersection of this triangulated geometry and the hexahedral core mesh and subsequent processing/simplification of the wall mesh.
StarCCM+ begins by offsetting the wall surface once, by the thickness of all the layers. The wall surface can be first remeshed to improve its properties and this does indeed appear to address face twist.
Offsetting a non-concave surface is trivial, but not so otherwise as some vertices may need to be shifted or collapsed in places. SHM seemed to be able to achieve this quite well however in my "single extruded layer approach".
I believe a lot of the building blocks needed to reverse the meshing sequence and layer generation process as I was describing earlier are there.
I also wish I had more familiarity with the internal code structure in order to be able to undertake such changes.
In the meanwhile, cfMesh is an alternative open-source OF mesher that has been making very promising progress. The stumbling block for me so far has been with anisotropic refinement. cfMesh produces much better layers and runs much faster than SHM, but SHM has better anisotropic refinement capability as long as inflation layers are not required. This means I can't make use of either code at the moment.
Thank you for your comment and strongly supporting the public release of confidential commercial developments. After a most entertaining conversation I had with a representative of engys (helixMesh, derived from SHM) some 18 months ago, I really would like to see this code finally coming out.
To this effect, I want to quote here below some of the text found at the link you provided above:
"Publishing the Source Code
If you have the source code of a privately distributed, modified version of OpenFOAM, please distribute it to the public. If you need assistance with that, or would prefer to distribute it through the OpenFOAM Foundation, please contact the OpenFOAM Foundation."
If you happen to have access to a mature native OpenFOAM mesher, please send the source code to the OpenFOAM Foundation.
||Rewriting snappyHexMesh will require significant funding.|
|2014-08-19 05:34||seaspray||New Issue|
|2014-08-19 05:35||seaspray||File Added: SHIP.stl|
|2014-08-19 05:36||seaspray||Tag Attached: Mesh|
|2014-08-19 05:36||seaspray||Tag Attached: snappyHexMesh|
||File Added: layers.png|
||Note Added: 0003212|
|2014-08-20 21:41||seaspray||File Added: SHM-Hull.tar.gz|
|2014-08-20 22:20||seaspray||File Added: DTC-Mesh-10-layers.png|
|2014-08-20 22:33||seaspray||Note Added: 0003213|
|2015-12-15 11:51||chris||Note Added: 0005763|
|2016-01-04 11:36||GeckoVM||Note Added: 0005798|
|2016-01-06 22:09||seaspray||Note Added: 0005804|
|2016-02-02 18:28||henry||Note Added: 0005876|
|2016-02-02 18:28||henry||Status||new => closed|
|2016-02-02 18:28||henry||Assigned To||=> henry|
|2016-02-02 18:28||henry||Resolution||open => suspended|