[doubledang]

Hi Guys,

I am trying to use snappyhexmesh utility to generate mesh for a CSTR.
I found a kind of annoying thing:
When I set base meshing below in the blockMeshdict, the snappyhexmesh utility
works well:

blocks
(
hex (0 1 2 3 4 5 6 7) ( 64 75 65) simpleGrading (1 1 1)
);


But when I wanted to increase the base mesh density like below, the snappy fails to remove the base mesh completely (see the pic in the attached case file).

blocks
(
hex (0 1 2 3 4 5 6 7) (84 95 88) simpleGrading (1 1 1)
);

I have uploaded the case file to the link:
https://www.dropbox.com/s/dxn5lhlug8go0mt/help.zip?dl=0

Hope you guys could take a look, and see if you have some tips!!

Many thanks!

Best regards,

[Swagga5aur]

Hello Dang,
I briefly tested your case with both blockMesh specifications and I was wondering what patch the issuing cells are stored in for for the paraview figure?

I initially assumed that they were stored in allBoundary patch, however, this patch exist for both blockMesh specifications when I run the Allrun.pre script, being inconsistent with your initial issue.

I'll look further into it in the next week as I'm quite busy the next three days.

[doubledang]

Hi Swagga5aur,

Thanks for your response.

I re-run it again, the problem could be reproduced.
You just need to run the Allrun.pre script, after it is done you will find the allBoundary
patch still exists in the final mesh. Normally the allBoundary patch should be gone after the final mesh is obtained.
Hope I have made my problem clear to you.

Best regards,

Originally Posted by Swagga5aur

Hello Dang,
I briefly tested your case with both blockMesh specifications and I was wondering what patch the issuing cells are stored in for for the paraview figure?

I initially assumed that they were stored in allBoundary patch, however, this patch exist for both blockMesh specifications when I run the Allrun.pre script, being inconsistent with your initial issue.

I'll look further into it in the next week as I'm quite busy the next three days.

[Swagga5aur]

Hello again DANG,
I just ran the two blockMeshes resulting in the following two figures with a remaining background mesh in both so I am wondering what openFOAM version you are using, I am using 4.1.

I'll try lower background mesh densities to try and pinpoint when the issue occurs.

Left figure is the blockMesh of (64 75 65) and the right is the (84 95 88).

[doubledang]

Hi Swagga5aur,

I use version 4.0, it is interesting problem, I still get no answer to this.
Let's see if you can get more information...

Best regards,

Originally Posted by Swagga5aur

Hello again DANG,
I just ran the two blockMeshes resulting in the following two figures with a remaining background mesh in both so I am wondering what openFOAM version you are using, I am using 4.1.

I'll try lower background mesh densities to try and pinpoint when the issue occurs.

Left figure is the blockMesh of (64 75 65) and the right is the (84 95 88).

[Swagga5aur]

Hello again,
I believe the issue lies in the stl files that you use as misalignment is observed of the surface triangulations as well as unenclosed surfaces. This is probably the cause to this unremoved backgroundmesh as the cells aren't part of the domain and can't be snapped to a nonexisting connecting surface.

This is shown in the below figure where a gap is noticed as well as misaligned vertices.

This has already been discussed how to solve in posts such as https://www.cfd-online.com/Forums/op...pyhexmesh.html
and https://www.cfd-online.com/Forums/op...sh-salome.html

Hope its of some help, let me know if you have any questions.

[doubledang]

Hello Swagga5aur,


After increasing the quality of the stl file, the problem is solved.

Thank you very much for your information.

Best regards,

Originally Posted by Swagga5aur

Hello again,
I believe the issue lies in the stl files that you use as misalignment is observed of the surface triangulations as well as unenclosed surfaces. This is probably the cause to this unremoved backgroundmesh as the cells aren't part of the domain and can't be snapped to a nonexisting connecting surface.

This is shown in the below figure where a gap is noticed as well as misaligned vertices.

This has already been discussed how to solve in posts such as https://www.cfd-online.com/Forums/op...pyhexmesh.html
and https://www.cfd-online.com/Forums/op...sh-salome.html

Hope its of some help, let me know if you have any questions.