CFD Online Discussion Forums

CFD Online Discussion Forums (
-   OpenFOAM Native Meshers: snappyHexMesh and Others (
-   -   Snap Precision to a STL Surface (

malaboss April 18, 2013 06:15

Snap Precision to a STL Surface
2 Attachment(s)
Hi FOAMers !
I am now studying an airfoil and I would like to create the mesh around it with snappyHexMesh. When I ran some simulations, it gave me a high drag.
Looking at the profile more precisely I saw that the stream line left the profile quite early (at least earlier than they should, which could be the cause of this higher drag. Looking more precisely, I saw that the profile did not respect well the NACA geometry which is normal as snappyHexMesh does not generate curves cells.

I spent several hours looking for the parameters I should change to improve the precision of the snap to the surface and I could not find the solution.

Do you know how can I improve the snapping ?

You can find attached the bad surface I get and my snappyHexMeshDict File.


        allowFreeStandingZoneFaces true;
    // Refinement parameters
    // ~~~~~~~~~~~~~~~~~~~~~

    // While refining maximum number of cells per processor. This is basically
    // the number of cells that fit on a processor. If you choose this too small
    // it will do just more refinement iterations to obtain a similar mesh.
    maxLocalCells 100000000;

    // Overall cell limit (approximately). Refinement will stop immediately
    // upon reaching this number so a refinement level might not complete.
    // Note that this is the number of cells before removing the part which
    // is not 'visible' from the keepPoint. The final number of cells might
    // actually be a lot less.
    maxGlobalCells 200000000;

    // The surface refinement loop might spend lots of iterations refining just a
    // few cells. This setting will cause refinement to stop if <= minimumRefine
    // are selected for refinement. Note: it will at least do one iteration
    // (unless the number of cells to refine is 0)
    minRefinementCells 20; //10

    // Number of buffer layers between different levels.
    // 1 means normal 2:1 refinement restriction, larger means slower
    // refinement.
    nCellsBetweenLevels 20;  // 2;

    // Explicit feature edge refinement
    // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    // Specifies a level for any cell intersected by its edges.
    // This is a featureEdgeMesh, read from constant/triSurface for now.
            file "surfacemesh.eMesh";
            level 8;

    // Surface based refinement
    // ~~~~~~~~~~~~~~~~~~~~~~~~

    // Specifies two levels for every surface. The first is the minimum level,
    // every cell intersecting a surface gets refined up to the minimum level.
    // The second level is the maximum level. Cells that 'see' multiple
    // intersections where the intersections make an
    // angle > resolveFeatureAngle get refined up to the maximum level.

            // Surface-wise min and max refinement level
            level (3 3);  // 5 6

    // Resolve sharp angles
    resolveFeatureAngle 30;  // 30;

    // Region-wise refinement
    // ~~~~~~~~~~~~~~~~~~~~~~

    // Specifies refinement level for cells in relation to a surface. One of
    // three modes
    // - distance. 'levels' specifies per distance to the surface the
    //  wanted refinement level. The distances need to be specified in
    //  descending order.
    // - inside. 'levels' is only one entry and only the level is used. All
    //  cells inside the surface get refined up to the level. The surface
    //  needs to be closed for this to be possible.
    // - outside. Same but cells outside.

            mode inside;  // inside;
            levels ((1.0e+15 0));  //1E15 4

    // Mesh selection
    // ~~~~~~~~~~~~~~

    // After refinement patches get added for all refinementSurfaces and
    // all cells intersecting the surfaces get put into these patches. The
    // section reachable from the locationInMesh is kept.
    // NOTE: This point should never be on a face, always inside a cell, even
    // after refinement.
        //locationInMesh (-1.39263 1.8424 0.0477);
    //locationInMesh (-3023.55 4000 -103.606);
        locationInMesh (-3 11 0);



    //- Number of patch smoothing iterations before finding correspondence
    //  to surface
    nSmoothPatch 10;

    //- Relative distance for points to be attracted by surface feature point
    //  or edge. True distance is this factor times local
    //  maximum edge length.
    tolerance 5;

    //- Number of mesh displacement relaxation iterations.
    nSolveIter 30;

    //- Maximum number of snapping relaxation iterations. Should stop
    //  before upon reaching a correct mesh.
    nRelaxIter 10;


    relativeSizes true;  //true;  // v 1.6
    // Per final patch (so not geometry!) the layer information
        //    nSurfaceLayers 3;
        stlSurface_patch0  // a_surface_name
            nSurfaceLayers 15;//2;

    // Expansion factor for layer mesh
    expansionRatio 1.03;  // 1.0;

    //- Wanted thickness of final added cell layer. If multiple layers
    //  is the
    //  thickness of the layer furthest away from the wall.
    //  Relative to undistorted size of cell outside layer.
    //finalLayerRatio FINALLAYERRATIO;  // 0.3;
    finalLayerThickness 0.8;  // 0.3;    // v 1.6

    //- Minimum thickness of cell layer. If for any reason layer
    //  cannot be above minThickness do not add layer.
    //  Relative to undistorted size of cell outside layer.
    minThickness 0.001;  // 0.1;

    //- If points get not extruded do nGrow layers of connected faces that are
    //  also not grown. This helps convergence of the layer addition process
    //  close to features.
    nGrow 1;  // 1;

    // Advanced settings

    //- When not to extrude surface. 0 is flat surface, 90 is when two faces
    //  make straight angle.
    featureAngle 180;  // 30;

    //- Maximum number of snapping relaxation iterations. Should stop
    //  before upon reaching a correct mesh.
    nRelaxIter 3;

    // Number of smoothing iterations of surface normals
    nSmoothSurfaceNormals 500;//5

    // Number of smoothing iterations of interior mesh movement direction 
    nSmoothNormals 50;//3

    // Smooth layer thickness over surface patches
    nSmoothThickness 100;//10;

    // Stop layer growth on highly warped cells
    maxFaceThicknessRatio 0.8;//0.5;

    // Reduce layer growth where ratio thickness to medial
    // distance is large
    maxThicknessToMedialRatio 0.5;//0.3;

    // Angle used to pick up medial axis points
    minMedianAxisAngle 180;//130;

    // Create buffer region for new layer terminations
    nBufferCellsNoExtrude 0;

    // Overall max number of layer addition iterations  // v 1.6
    nLayerIter 10;//50;  // v 1.6

Every help is welcome !
Thanks in advance !

Haces April 18, 2013 17:15

Hi malaboss,

Try to install OF 2.2. Go to the new releases of OF 2.2 in the official web page and you will see that there are more parameters in the snapping part. The explicit utility works quite well.
You can also try to increase the nSolveIter in the snap part.

Hope this helps,

malaboss April 19, 2013 06:06

1 Attachment(s)
Hi David,
Thanks for the advices it helped me a lot.
Increasing the solve iter from 30 to 1000 did not change anything first, I still had this "smooth castellated" mesh.

Then, I upgraded my openFOAM to 2.2.x and used the featureHandlingEdge (actually I wasn't sure it was necessary to upgrade my openFoam for this, but there are many other improvment).

I saw a lot of improvment as my surface respects now the STL File.
I think the surface could me improved again is I increased the level in the castellated part.
(I did this with level 4)

Thank you !

malaboss April 19, 2013 08:26

2 Attachment(s)
I just tried a new simulation with the new geometry and you can find enclosed what I see for the pressure field.

The quality of the snapping seems to be very important, for the fields near the wall.
I am using Spalart allmaras for Re = 1000 000

Changing the castellatedMesh level from 4 to 6 (which increases a lot the amount of cells !) does not really change the problem.

I enclosed also the new snappyHexMeshDict file I use.

JR22 April 19, 2013 17:54

In addLayersControls try:


        relativeSizes true;
        expansionRatio 1.0;
        finalLayerThickness 0.5;
        minThickness 0.25;
        nGrow 1;

malaboss April 20, 2013 03:10

Thanks for the answer.
Actually I tried to change the layer mesh in many ways but it did not have any effect on the problem I showed above. I think the fact that my surface snapping is not entirely made of curves is the problem. As you can see, the low zones of pressure are located on the "angles" of my surface.

Then, I think the problem is due to my snapping rather than my layer mesh

I will give a try monday with your post and tell you about it.

malaboss April 22, 2013 11:47

2 Attachment(s)
Hi FOAMers,

as I promised, I tested the new set of parameters proposed by JR22 for the layer.
It did not really change the problem as I still see some jump of pressure of the angle parts of the surface.
Moreover, it seems to create some weird pressure field.

What I don't understand it that I could not see it when I applied the same parameters to a cylinder. I could get some correct result. But now with an airfoil, it became hard having a pressure field coherent with expectations.

Again, if anyone has an idea, I would be delighted to hear it.

Haces April 22, 2013 13:06

Can you upload the final mesh?

malaboss April 23, 2013 03:38

3 Attachment(s)

sure you can see the mesh !

I realized last night that I did not recheck my Yplus when I changed the layer controls. I replaced the

finalLayerThickness 0.5;

finalLayerThickness 1;
so that I have Yplus between 20 and 100 approximately.
However, the situation is quite the same...

Here are three point of view :
-One zoomed out with pressure represented : you can see the big jump of pressure on the left.
-Two zoomed in screenshots representing only the mesh near the airfoil. On the trailing edge, there is some high non orthogonality. Elsewhere, the mesh is uniform but I see some high stretching from time to time.

Check Mesh complains about 1 non orthogonality (it seems to be because of the trailing edge, so I don't think it is the problem here)

What do you think about it ?

Haces April 23, 2013 06:29

If you are running a highRe simulation I think that the yplus should be bigger than 30. If you want to control the real size of the layers you can select relativesizes: false.
Have you checked if the geometry is smooth enough?

malaboss April 23, 2013 12:45

1 Attachment(s)
Thanks to your answer I saw that a problem comes from the STL surface itself.
I generated a surface with splines and then extruded it with salome Meca.
At this moment, Salome changed the accuracy of the geometry, and created the extrusion with triangle faces.
You can find enclosed the stl surface viewed with discretizer set up.

I posted a question on a salome forum and will tell you about it.

About the weird pressure field, do you think it was due to this surface or something else ?

Thank you again.

Haces April 23, 2013 13:29

I know that with solidEdge you can select the accuracy of the geometry but I have no clue about salome. For sure there are open topics about the accuracy of the surface.
To check the quality of the surface you can also run surfaceCheck

malaboss April 29, 2013 08:47

Hi !
I looked for a solution with salome Meca and many people say it is impossible to change the precision of the Stl file generation in Salome.
I use instead AutoCAD in which it is easy to control the number of facets of my STL file. In my version, I just have to use the function FACETRES

This problem solved, I exported my file as a STL and used again snappyHexMesh. And I still had these jumps of pressure over my surface. I tried then to change many parameters, and I finally noticed that when I used the interpolation linear instead of upwind (in system/fvSchemes) everything suddenly went right !

I really do not understand why upwind generated such problem with the flow. I thought it could make the convergence easier, and modeled better the flows dominated by convection.

Correct me if I am wrong but basically upwind is approximating the flow on a the frontier between 2 cells by the flow at the upstream cell. Linear is rather considering that the flow at the frontier of two cells is influenced by the upstream and the downstream equally.

Upwind seemed to be a good deal to me, even if it is only first order accurate.

vasava May 2, 2013 05:23

Sometimes choosing inappropriate angle value with surfaceFeatureExtract command will result in to unresolved edges of the STL file. In other words not all the features of the STL surface are identified if you choose an inappropriate angle. Here is what I do:

Step-1: Use surfaceFeatureExtract with some angle to extract feature
Step-2: Use surfaceFeatureConvert to convert the identified feature (you will only see edges) to an .obj file.
E.g. surfaceFeatureConvert constant/triSurface/example.eMesh exmple_test.obj
Step-3: Read .obj file with paraview and make sure that all the edges as they appear in the original STL surface are identified.
Step-4: If you are happy you can proceed to snappyHexMesh operations else go to step-1 and continue with some other angle.

Try and lets see if it works for others as well.

Sliwa July 10, 2013 07:50


Originally Posted by vasava (Post 424592)
Step-1: Use surfaceFeatureExtract with some angle to extract feature
Step-2: Use surfaceFeatureConvert to convert the identified feature (you will only see edges) to an .obj file.
E.g. surfaceFeatureConvert constant/triSurface/example.eMesh exmple_test.obj
Step-3: Read .obj file with paraview and make sure that all the edges as they appear in the original STL surface are identified.

I followed these steps and all the edges I want are identified. But for some reason, the snapping fails: my mesh edges are wavy!
I tried to play around with pretty much all the snappyHexMeshDict parameters according to what I read on the forum, but nothing helps.
In fact, I noticed that even when turning off the explicit utility, I still get the same rough edges... It looks like snappy doesn't use the features extracted at all.
Any ideas about where this might come from?

malaboss July 25, 2013 08:11

Have you checked if your stl file was precise enough ?
As I said on my previous message, my stl file was already extremly wavy.

vasava July 26, 2013 01:44

Yes I agree with malaboss. I think the .obj files give much better output than .stl.

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