Skip to content

SnappyHexMesh returns different results when setting functions to true 1-by-1 or running with all set to true!

Summary

When exploring snappyHexMesh as beginners me and my group at Aalborg University noticed a strange behavior: When running snappyHexMesh with all functions (castellated, snap and addLayers) set to true, it returns a poor mesh with illegal faces (both when '-overwrite' is included and when it is not!). However, when running the exact same case with each function set to true 1-by-1 (the others false) it returns a much better mesh (especially the layers) without any illegal faces or errors! I have attached a minimum reproducible case as a .zip file. My group and I verified this behavior on the university cluster, so this should not be machine specific!

Steps to reproduce

Download the attached folder 'baseCase.zip' and unzip it. Place it in your run-folder. Navigate inside the folder 'baseCase' in the terminal. Verify that the file 'runBaseCase.sh' does not include any unwanted commands. NOTE: You may have to adjust the 'decomposeParDict' to specify the number of processors in your system (not sure if 'runParallel'-command takes care of this). Then run the bash script by typing './runBaseCase.sh' inside the folder 'baseCase'.

Example case

baseCase.zip. When viewing the mesh in ParaView remember to turn off 'decompose polyhedra' and also turn off 'triangulate slice' (make a slice in the z-direction to reproduce screenshots below).

What is the current bug behaviour?

snappyHexMesh creates poor meshes for all functions set to 'true' (castellated, snap and addLayers), both with and without '-overwrite'! However, when setting the functions to true 1-by-1 it produces a much higher quality mesh (as inspected in ParaView) without any errors!

What is the expected correct behavior?

Expected behavior is that snappyHexMesh should act the same, independent of the order of the 'true/false'.

Relevant logs and/or images

The relevant logs will be generated for each case when running the case as described above.

I attach some screenshots here, this is the output from the .sh script: bashOutput

First the case with all snappyHexMesh functions set to true and -overwrite included in the same run: Case1

Next, the case with all snappyHexMesh functions set to true one by one and -overwrite included (clearly this mesh is better!): Case2

Lastly the cases with all snappyHexMesh functions set to true and -overwrite not included: Case3_castellated Case3_snap Case3_addLayers

Environment information

  • OpenFOAM version : v2106
  • Operating system : ubuntu WSL2 18.04 (local PC) and ubuntu 18.04 (university cluster)
  • Hardware info : Lenovo Legion 5 Pro (32 GB RAM) AMD Ryzen 7 5800H 8 core (local PC)
  • Compiler : not used

Possible fixes

Sorry I am not a programmer, but the problem seems to be with the addLayers functions, as can be seen from the third case (all functions set to true and no -overwrite). I have an idea for why the boundary layers fail: If addLayers reads from disk it works well, but if it reads from memory it works poorly. This could explain all of this behavior, given that the addLayers step of the last case still reads from memory, even though it has written the 'snap'-mesh to disk. However, this deduction is not based on any code, so I might be wrong. A current workaround is creating a .sh run file like the one above. Hope you can fix this!

Edited by Nikolaj Bielefeld