CFD Online Discussion Forums

CFD Online Discussion Forums (
-   OpenFOAM Meshing & Mesh Conversion (
-   -   [snappyHexMesh] snappyHexMesh <-> dynamicMeshDict problem with protected cells (

Billy_16 March 30, 2016 09:51

snappyHexMesh <-> dynamicMeshDict problem with protected cells
1 Attachment(s)
since this is my first post, please be patient if my question is already answered in another thread.

My Test-case:
1. blockMesh simple cubic domain
2. snappyHexMesh a stl geometry (circle) and substract it from mesh
3. run the flow with dynamicMeshDict for adaptive refinement, based on vorticity.

This works as expected with one problem:

dynamicMeshDict reports:


Detected 172 cells that are protected from refinement. Writing these to cellSet protectedCells.
These cells are 2 to 4 cells away from the solid. So refinement of the solid with snappyHexMesh is working

checkMesh (before running the solver) reports:


Time = 0

Mesh stats
points: 2020
faces: 3828
internal faces: 1940
cells: 948
faces per cell: 6.08439
boundary patches: 6
point zones: 0
face zones: 0
cell zones: 0

Overall number of cells of each type:
hexahedra: 896
prisms: 16
wedges: 0
pyramids: 0
tet wedges: 0
tetrahedra: 0
polyhedra: 36
Breakdown of polyhedra by number of faces:
faces number of cells
6 12
9 16
12 8

Checking topology...
Boundary definition OK.
***Total number of faces on empty patches is not divisible by the number of cells in the mesh. Hence this mesh is not 1D or 2D.
Cell to face addressing OK.
Point usage OK.
Upper triangular ordering OK.
Face vertices OK.
Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces...
Patch Faces Points Surface topology
frontWall 40 82 ok (non-closed singly connected)
backWall 40 82 ok (non-closed singly connected)
inlet 20 42 ok (non-closed singly connected)
outlet 20 42 ok (non-closed singly connected)
topAndBottom 1704 1880 ok (non-closed singly connected)
cylinder 64 96 ok (non-closed singly connected)

Maybe there is some setting in SnappyhexMesh, to generate only hexahedrons.
As the sum of (front+back+inlet+outlet) + non-hexahedra = 120 + 52 = 172
It seems to me that the problem are the non-hexahedra cells.

In the attached file, red cells are refined, blue not.
Yellow cells should be refined, but are protected.

Thanks for a hint, where the problem is. ( except in front of the monitor )


potentialFoam November 21, 2016 10:33

Dear William,

did you find a solution for the problem that Adaptive Mesh Refinement is not working for non-pure-hex cells?

I also faced this problem here
But I didn't find a solution until now... Although is should work, see e.g. what T. Holzmann achieved:


mAlletto November 21, 2020 04:34

I just tested to use AMR on a flow around a sphere where the mesh is generated by snappyhexMesh and it worked. I used OF2006. In this version (maybe also earlier) cells which cannot be refined are shielded in the beginning of the simulation. The only drawback is that one cannot use wall layers. A mesh generated with snappyhexMesh with wall layers produces the following error:


cell 29599 of level 5 uses more than 8 points of equal or lower level
Points so far:8(14554 25760 25761 28967 35727 35732 35737 35742)

All times are GMT -4. The time now is 14:03.