BUG: renumberMesh after snappyHexMesh modify behavior of DynamicRefinement
Summary
renumberMesh does not update properly cellLevel
, Level0Edge
and pointLevel
files created by snappyHexMesh
but instead delete them.
It will later cause some cells to be protected and not refined, negating the interest of the dynamic refinement.
Steps to reproduce
To reproduce, one can call renumberMesh
in a case with snappyHexMes
and dynamicFvMesh
after snappyHexMesh
has been called.
Example case
I first encountered this bug on a personnal case, but I was able to reproduce it with a tutorial.
cp -r $FOAM_TUTORIAL/tutorials/multiphase/interFoam/RAS/motorbike
- Then add a renumberMesh after snappyHexMesh in Allrun.pre or replace with Allrun.pre and execute Allrun
What is the current bug behaviour?
Actually, at the launch of the solver, some cells are protected from refinement, and therefore will not be refined by dynamic refinement even if respect the criteria for the refinement.
What is the expected correct behavior?
No cells should be proctected. So the could be refined if necessary.
Relevant logs and/or images
from log.interFoam :
Selecting dynamicFvMesh dynamicRefineFvMesh
Detected 3055 cells that are protected from refinement. Writing these to cellSet protectedCells.
here is two pictures showing the expectation and the reality on a case with a cube, since the case with the motorbike diverges and
fails. The first gif was obtained using topoMesh
but I got same results with snappyHexMesh
without renumberMesh
.
mesh evolution with renumberMesh
:
Environment information
OpenFOAM version : v1806 and v18012 Operating system : debian/buster and Ubuntu bash on Windows Compiler :
Possible fixes
I have determined that this behavior is caused by the deletion of the
processor*/constant/polyMesh/{cellLevel,level0Edge,pointLevel}
files
or the incorrect (I deleted them manually without executing renumberMesh
or created them manually filling them with 0)
Thus, the file responsible is located at $WM_PROJECT_DIR/applications/utilities/mesh/manipulation/renumberMesh/renumberMesh.C:1327
// Remove refinement data
hexRef8::removeFiles(mesh);
and it should be replaced with function that update the cellLevel, level0Edge and pointLevel files according to the renumbering.
After some tests, I concluded that rotateMesh
and transformPoints
are not affected.
The use of
reconstructParMesh -constant -mergeTol 1e-6
deconstructPar -force
also results in protectedCells.
Others mesh manipulations utilities may also lead to this behavior.
Thanks a lot, feel free to ask if you need any details.