GitLab

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.