CFD Online Discussion Forums

CFD Online Discussion Forums (
-   OpenFOAM Native Meshers: snappyHexMesh and Others (
-   -   sHM problem (

openfoam_user September 26, 2011 09:37

sHM problem
1 Attachment(s)

I have a problem using sHM.

I have a pipe with inside 3 blades. The 3 blades are identical.

Cells inside the first blade are not deleted !


Attached is a picture showing the problem.

Has someone already encountered such a problem ?



wyldckat September 26, 2011 10:47

Hi Stephane,

Probably there is a small hole in the filled blade. Google:

openfoam "admesh"
It should show you a few solutions for plugging the hole(s).

Best regards,

openfoam_user September 30, 2011 02:01

3 Attachment(s)
Hi Bruno,

Find attached 3 other pictures.

The first one is a global view of the right corners. Second and third are zoomed pictures. This time each corner has 7 blades. The blades are identical in each corner. So there is no problem (holes) with the blade geometry.

As you can see, sometimes cells are not deleted inside the blades.

Picture 2 (top right corner) : cells inside 2 blades are not deleted !

Bottom corner has no problem (picture 3).

This is very strange. I can't find any explanation. Need help ...



wyldckat October 1, 2011 12:16

Hi Stephane,

Mmm... if the surface for each of those two blades are really water tight, then it might be a numerical problem. Are you able to isolate the each one of those damaged blades into separate STL files? Then check the following two details on those two independent blades:
  1. Really confirm if they are water tight. Check with both admesh and Blender. Also check in Blender if the triangle normals all point in the same direction, inside or outside.
  2. OpenFOAM 2.0 brings a lot of new nice utilities for surface handling and verifying. Such example is:

    surfaceMeshInfo surface.stl
    This should give you some statistics about the STL geometry. If there are any veeeeery small triangles, they might not be properly seen by snappyHexMesh during mesh generation and therefore be considered to be holes.
Worst case scenario: I believe it would be the case where one or more points in those STL geometries fall directly in the same exact place of a vertex of mesh cells created during the 1st stage of castellated mesh generation and refinement in snappyHexMesh. For this, a trick would be to increase or decrease the resolution for the base mesh that is generated with blockMesh! Or even moving the corners of the base mesh, even if just a little bit.

Best regards and good luck!

openfoam_user October 3, 2011 10:33

Hi Bruno,

I think what is happening is your worst case scenario.

I have moved the domain (blockMeshDict) a little bit in the x-direction. And now cells are deleted into the blades. But the problem occurs for other blades. Till now I haven't succeed in finding the right location for the flow domain.

And my final geometry has more than 10 blades in each of the 4 corners !!!


wyldckat October 3, 2011 10:50

Hi Stephane,

I've just remembered that this problem might be overcome by adjusting the tolerances. Check the following file in OpenFOAM's folder:

There are 3 variables that might help there:
  • Near the end of the file:

    mergeTolerance 1e-6;
  • Lines 41-42:

            //tolerance  1E-5;  // optional:non-default tolerance on intersections
            //maxTreeDepth 10;    // optional:depth of octree. Decrease only in case

Along with these, it's also worth a try is the write tolerance set in "system/controlDict".

And I assume you aren't using the "Single Precision" build of OpenFOAM! If so, use the default "Double Precision"!

Good luck!

openfoam_user October 5, 2011 04:34

Hi Bruno,

Adding or changing the tolerance values has no effect for me.

Now I have 3 corners with 7 blades each that have a nice mesh. I have just add 1 cell in each direction by modifying the blockMeshDict file. But the problem remains for the 4th corner. 2 blades have cells inside !

I try to change the number of cells in direction and/or moving a little bit the location of the background mesh. I need luck. Unfortunately that's not the right solution.



wyldckat October 5, 2011 09:41

Hi Stephane,

OK, then first mesh only the castellatedMesh stage. Check which cube-like cells are the ones at fault.
The key detail is whether there are cell vertexes that fall on top of the surface being meshed.

The other possibility is to change the way the base mesh is being created. For example, divide the domain into 4 or 9 blocks, where each corner block is generated using a gradually graded mesh. This would make it harder for the cell vertexes to fall into the surfaces.
For this, you can also use refineMesh with a refineMeshDict (plus cell sets to help select the corners), for refining only in the respective corners, instead of dividing the mesh into 9 parts directly in blockMeshDict.

I've now remembered about a similar issue I found out when running snappyHexMesh in single precision, in the end of last year; check this note by Mattijs:
Hopefully those tricks he talks about will help you get a good solution!

Last but not least, I would also try meshing the domain with only the blades. This might help verify if this is a global problem or if it's only related to enclosed domains!

Good luck!

openfoam_user October 7, 2011 05:01

Hi Bruno,

I succeed in generating the grid. Only by changing the location of the background mesh. With LUCK ! Not the best way to solve the problem but for this time it is OK.



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