[Marpole]

Hello HPE and AtoHM


I simplified the case so I can demonstrate the problem more clearly. Attached are 3 blockMeshDict files. Baseline is that the block has a little space (baffle space) out of STL. Left blockMeshDict is the one with left block side a little inside the STL (0.5mm) and right blockMeshDict is the one with right block side a little inside the STL (0.5mm). Baseline failed to snap and the rest two snap very well. I believe there is a bug in the snappyHexMesh but would like to hear your comments on this.



Kind Regards,

[Tobi]

Dear all,


I am just writing as Charles sent me a message. A short analysis:

• Just downloaded the case
• blockMesh
• Removed featureEdges
• Added implicit feature edges
• snappying -> failed

• blockMesh
• changed the "empty" patch to wall in the background mesh (you dont't have a 2D mesh)
• snappying -> fine

Maybe I did not get the point but snappying is fine on my computer.

[Marpole]

Hi Tobi,


Thank you, I can make the mesh!


Though, I'm still puzzled that snapping works by moving blockmesh side a bit inward into the stl geometry . I checked the boundary file, they are pretty much the same. I will dig deep into it.

[Tobi]

The outcome you observe is common and known. However, even though I wanted to dig into that already 5 years ago, I never found the time to analyze the code. Furthermore, my background knowledge about meshing strategies and quality criteria calculation is almost zero. In order to provide all patches, it is common practice to make the background mesh a bit larger, otherwise the patch name of the background mesh should be added (maybe I am wrong here).


Actually my steps are always the same:

• build a well surface triangulation
• export each patch as stl
• combine the stl to form a region stl
• proof of watertightness
• create the background mesh (fits the whole stl one to one)
• scale the background mesh by a factor of e.g., 1.005
• build the snappyHexMeshDict
• run snappy
• check the mesh and improve the settings

The workflow given above is done almost automatically (I created some scripts for doing the work). So actually what I do is:

• Create the STL in Salome
• Export the STL's
• Create the background mesh in Salome
• Export the background mesh
• Execute `buildRegionSTL`
• Execute `buildSnappyHexMeshDict`
• Execute `createSnappyMesh`

Done

[Marpole]

Thanks Tobi, I took a note of your procedure!



My plan to dig deep into the code might be over ambitious. But I can write a python script to automate the process (including Salome).

[Wolfram]

Originally Posted by HPE

Have you set the refinement level correctly:

`snappy` does not pick the cells for the refinement at the very beginning:

"
Cells per refinement level:
0 98273
"

Also feature, shell refinements are not picked up. hmmm

"
Refinement phase
----------------

Found point (-0.1 0.069 -0.001) in cell 163322 on processor 0

Feature refinement iteration 0
------------------------------

Marked for refinement due to explicit features : 0 cells.
Determined cells to refine in = 3.14 s
Selected for feature refinement : 0 cells (out of 277344)
Stopping refining since too few cells selected.
"

Have you found the reason for this message? I am facing the same issue

[Marpole]

I solved the problem but cannot recall exactly now.

The error message basically says it tried to refine the mesh in the refinement region. But the refinement region is too small that it doesn't have enough initial background cells for refinement. The solution might be to redefine the refinement region to make it larger. Hope it works for you.