snappyHexMesh: Layer addition process can destroy patch shape

Summary

snappyHexMesh:

Two patches are connected at an edge. Layers are to be generated at only on patch. The other patch is wrongly stretched over the thickness of the layers of the other patch, effectively blocking the flow.

Steps to reproduce

Run an example, where two patches are connected at an edge and layers are only requested for one patch. Check the geometry of both patches at the connection line.

Example case

Check the attached file. Unzip and run snappyHexMesh.

mesh1_explicitFeatures_BAD.zip

What is the current bug behaviour?

Check the middle plot of the attached image. Layers at the green patch cause an unwanted "extending" of the adjacent red patch.

What is the expected correct behavior?

Check the right plot of the attached image. Layers end correctly at the edge, the red patch is not extended. This can be triggered by explicitly specifying zero layers for the adjacent red patch.

Relevant logs and/or images

Environment information

• OpenFOAM version : v2406|v2312|v2212

Possible fixes

Within the layer process, all patches should be initialized as if they were mentioned in the "layers" directory, but with "nSurfaceLayers 0". After that, the specific entries of the "layers" dictionary should overwrite it.

@Mattijs

added community label

• Try changing the slipFeatureAngle (see etc/caseDicts/annotated/snappyHexMeshDict). It determines whether to allow the medial-axis method to slide along the existing mesh.
• Or use a different meshShrinker (e.g. displacementMotionSolver) which does not require this setting.

I tried it with displacementMotionSolver. No difference to the prior results.

For me, the main argument is:

Generating a mesh with no layer specification for box2 results in a wrong mesh: Middle picture, the previously correctly snapped edge is shifted resulting in a distorted geometry. Generating a mesh with specification of zero layers for box2 results in a correct mesh: Right picture, correct position of the edge. This difference seems to be an unwanted behaviour.

For the first case, the problematic point is that the nodes of the edge are extended together with the layers, while they should be fixed at their snapped position at the boundary of the patch box2. See middle picture.

I tried if the manifoldness of the underlying geometry makes a difference, i.e. open shells versus closed objects: No impact.

I may ask a stupid question but what is wrong with setting nSurfaceLayers 0; on box2 to overcome the issue? Does it cause other issues?

Setting all patches to 0 layer by default would prevent to have layers extruded on inlet/outlet patches, such as this pipe mesh from Tobias: https://holzmann-cfd.com/images/OpenFOAMCases/meshingAPipe/meshingAPipe_2.png

(default 0 layer would cause the layers to collapse to preserve the inlet patch)

@Yann: Setting nSurfaceLayers 0; for box is a workaround, but not a solution. Now you know it, I know it, other users don't.

What I wanted to point out it that the current behavior on undefined patches can sometimes be desirable.

I agree it is surprising when you don't know about it. Maybe documenting it could be helpful?

If this was to be changed to fix the case you pointed out, then another way/setting should also be introduced to be able to retrieve the current behavior when wanted. (which is fine to me, as long as it's possible to do both)

Ah, I see your point. I agree on the fact that it may be helpful to have "no" layers on certain patches like i.e. the inlet of Tobi's pipe.

But I still think it is a bug: In the pipe example the "free-standing" side of the layers is incorporated into the inlet patch, which is desired, but is it correct? In my example, it is like a baffle blocking the flow, which is incorrect.

I'm not sure how to resolve this in an understandable, consistent way. Maybe the angle of the adjacent patches is the clue? For the one example the angle between the patches is concave, for the other it is convex.

I'm not sure how to resolve this in an understandable, consistent way.

I'm not sure either!

Your convex/concave distinction is also the only way I can think of. It would work for the 2 examples mentioned above, I don't know if it could fail or cause other issues on other cases.