[Marpole]

I have a strange problem. I used snappyHexMesh to generate mesh. It failed to snap. When I reduce a block size in blockMesh by 2mm, it snaps well. (see attached plot). When it failed, I have not found any error message. I attached code here as well (two blockMeshDict are a.blockMeshDict and b.blockMeshDict. you need to copy it to blockMeshDict in order to run). Any help is appreciated.


Regards,

[AtoHM]

Seen this a view times and - as you mentioned - I determined it can originate from a "bad" block mesh. How do you set that up?
Get the max bounding box of the STL file and add just a bit of material in each direction, so the block mesh covers a bit more space than the geometry.



Also, make sure your "point inside" is correctly located inside domain AND does not coincide with a face or node (use coordinate values like 0.0124 instead of 0).

[Marpole]

Thanks AtoHM for your comments.



I checked and am sure that the seed point is inside: locationInMesh (-0.100 0.069 -0.001);


Bound of STL is an interesting question.



STL x bound is from -0.114 to 0.114. If I used -0.116 or -0.120 as the block left, to have a bit more space, it wouldn't snap. But if I used -0.114 or -0.110, it snaps well for the rest surface. Of course, it wouldn't see the left surface. This is where I get confused.



BR

[AtoHM]

When you have a background mesh of 2mm and try -0.016, the first cell covers exactly the space up to -0.014, which might cause this. Try -0.015 to 0.015 for the background mesh and see what happens.

[Marpole]

Thanks again.



I tried with -0.115. It failed to snap. I was surprised that there is no error message on snapping failure.

[AtoHM]

Hm, then it must be something else. Can you share your sHM dict?

[Marpole]

The model was attached in my first post ( modelV2e.zip), where blockMeshDict is included. There are two blockMeshDict files: a.blockMeshDict and b.blockMeshDict. The run time is about 2-3 minutes. You can copy to blockMeshDict so to reproduce the snapping failure or the snapping working. Appreciate!

[HPE]

`snappyHexMesh` guarantees the generated mesh obeys the given `mesh quality metrics`. In light of this constraint, if the `mesh quality` metrics are not attained at the end of `snap` phase, the entire mesh is reverted back to the `castellatedMesh` result. I think your `not-snapped` mesh corresponds to just blocks of cells, which indicates `castellatedMesh`.

Try to relax the mesh metrics if you want to keep the `blockMeshDict` the same.

In addition, `snappyHexMesh` may need finer `blockMesh` to achieve the input refinement levels for your geometry. To my experience, fine background `blockMesh` helps.

[Marpole]

Thanks Herpes.



I have already tried finer background. Maybe, I need to make it further.



Your suggestion on "reverting back" is very helpful. It explained why there is no error message. I will try to relax mesh quality metrics and see what I get. Can I get info, from snappyHexMesh log file, on what metric should I relax?

[HPE]

Yes, log file contains all the related info, even tells you that it reverts the mesh back.

But there are lots of messages inside a typical log file. That's why you might have missed it if it is there.

Hope you solve your problem.

[Marpole]

It is strange, I cannot find keyword "revert" or "Revert" in log file

[HPE]

No no, revert is my verb. If you attach the log file here, we can try to find it in our spare time.

[Marpole]

Hi HPE,


Attached is the log.snappyHexMesh. The system doesn't allow me to upload log.snappyHexMesh. I have to compress it to zip file. Thanks.

[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.
"

[Marpole]

Good findings. I will review them in more detail. Thanks very much!

[Marpole]

Originally Posted by AtoHM

Hm, then it must be something else. Can you share your sHM dict?

Hello AtoHM,



Have you tried to open up the model zip file and review the blockMeshDict? I would like to hear your insight comments. Thanks.

[Marpole]

Hi HPE,


I got chance to review the log file this morning. I found that I got similar messages when I reduced the block size and made a good (snapping) mesh. So I'm not sure if I will take these as root cause of snapping failure. Any more insights on the log file?


If you want, the blockMeshDict and snappyHexMeshDict are in the attachment of my initial post.



Kind Regards,

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.
"

[HPE]

Let me look at it properly then when I have a chunk of free time, which is rare to find these days.

Hope you find your answer before then.

[Marpole]

Thanks very much.



I noticed a difference, between "working" log and "failed" log, that the failed log has "Correcting 2-D mesh motion ...done" but working long doesn't have this. I don't know if this is helpful for diagnosis.

[AtoHM]

HPE's findings sounded promising and I thought blockMesh was ok then, but I had the same message "2-d mesh motion" last week. Reason was, I increased the model dimensions in y but forgot to adjust the block mesh. I might have time to look into your files in the evening today.