CFD Online Discussion Forums - [snappyHexMesh] Adding layers distorts internal mesh

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- OpenFOAM Meshing & Mesh Conversion (https://www.cfd-online.com/Forums/openfoam-meshing/)

- - [snappyHexMesh] Adding layers distorts internal mesh (https://www.cfd-online.com/Forums/openfoam-meshing/252796-adding-layers-distorts-internal-mesh.html)

Adding layers distorts internal mesh

I am finding that if I add a thick layer on one of the domain boundaries, SHM makes a real mess of the mesh at the other surfaces, as it shrinks the internal mesh to make way for the layer. In the example below, the mesh at the top of the cube is stretched horribly. Is there any way to control this better (other than to use a thinner layer)? I couldn't see anything in the snappyHexMeshDict controls ... any suggestions would be welcomed.

Code:

/*--------------------------------*- C++ -*----------------------------------*\

  =========                 |

  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox

   \\    /   O peration     | Website:  https://openfoam.org

    \\  /    A nd           | Version:  dev

     \\/     M anipulation  |

\*---------------------------------------------------------------------------*/

FoamFile

{

    version     2.0;

    format      ascii;

    class       dictionary;

    object      snappyHexMeshDict;

}

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //



castellatedMesh true;

snap            true;

addLayers       true;



geometry { 

    domain

    {

        type triSurfaceMesh;

        file "cube.stl";

        name cubeSTL;                     // name of this surf inside SHM

        regions {

            top    { name cube_top ;}     // STL patch name and final name of the patch

            sides  { name cube_sides ;}

            bottom { name cube_bottom ;}

        }

    }

};







castellatedMeshControls  {

    maxLocalCells 1000000;            //default 100000;

    maxGlobalCells 5000000;            //default 2000000;

    minRefinementCells 10;

    maxLoadUnbalance 0.10;

    nCellsBetweenLevels 5;



    //feature edge refinement - eMesh read from constant/triSurface

    features (         

        { file "cube.eMesh"; level 1; }

    );



    //surface refinement

    refinementSurfaces {

        cubeSTL {         level (1 1);

                                        regions {

                                                top { level (1 1);  patchinfo { type wall; } }

                                                sides { level (1 1);  patchinfo { type wall; } }

                                                bottom { level (1 1);  patchinfo { type wall; } }

                                        }

                }

    }

    resolveFeatureAngle 30;



    //volume refinement

    refinementRegions { 

    }

    

    //other mesh parameters

    locationInMesh (0 0 2);

    allowFreeStandingZoneFaces true;

}





snapControls {

    nSmoothPatch 3;

    tolerance 2.0;

    nSolveIter 30;

    nRelaxIter 5;

    nFeatureSnapIter 10;

    implicitFeatureSnap false;

    explicitFeatureSnap true;

    multiRegionFeatureSnap false;

}



addLayersControls {

    relativeSizes false;

    firstLayerThickness 0.02;

    thickness 0.2;

    layers {

        Zneg {nSurfaceLayers 5;}

     }



    minThickness 0.005;

    nGrow 0;

    featureAngle 160;

    slipFeatureAngle 30;

    nRelaxIter 5;

    nSmoothSurfaceNormals 1;

    nSmoothNormals 3;

    nSmoothThickness 10;

    maxFaceThicknessRatio 0.5;

    maxThicknessToMedialRatio 0.3;

    minMedianAxisAngle 90;

    nBufferCellsNoExtrude 0;

    nLayerIter 50;

    nRelaxedIter 20;

}



meshQualityControls {   #include "meshQualityDict" }

writeFlags ( scalarLevels    layerSets     layerFields );

mergeTolerance 1e-6;

oO, it appears you are running the Foundation version, right?
I use the ESI version for meshing and cannot remember seeing it shift this way at another boundary so far away and parallel to it. Any chance you can try the same with ESI OpenFOAM? There is also an additional mesh shrinker available there, which behaves differently from the default one (that is probably used here and somewhat similar to the ESI default).
You could also provide us the stl and I can check for myself in the evening.

Great suggestion - I will try it out this afternoon and let you know how I get on. Many thanks.

I don't see why it would make a difference, but you may try to explicitly define 0 layers on your cube top surface to see if it affects the mesh.

Long time ago I had a really confusing issue on a mesh and it was related to specifying 0 layers on a surface or leaving it undefined, in a place where it wasn't supposed to make a difference. So I guess it would be worth trying, just to make sure.

Cheers Yann - I'll give that a go this afternoon as well. Stand by!

Quote:

Originally Posted by Yann (Post 859620)

Thats the super expert knowledge here :) I am curious if it helps. It if does not make a difference, you can try to prescribe 1 layer on the top with a region-specific firstLayerThickness of your "normal cell size" (you can prescribe these parameters globally like you did, or for each region separately by adding them again inside the specific region{ ... } part).

Code:

layers {



    cube_top {

        nSurfaceLayers 1;

        firstLayerThickness 0.05;  //or whatever the size is

    }

    Zneg {nSurfaceLayers 1;}



}

Wow - I tried Yann's suggestion first, since it was the easiest/quickest to try:

Code:

    layers {

        Zneg {nSurfaceLayers 5;}

        cube_top {nSurfaceLayers 0;}

     }

... and this solved it! See the pictures below, before and after layer insertion. Do you have any insight, Yann, as to what is going on here? Should I be specifying the number of layers on all of the surfaces?

I'll try the ESI version later on this afternoon, just to complete the story. But in the meantime - many thanks to you both for your suggestions.

Quote:

Originally Posted by Tobermory (Post 859644)

Do you have any insight, Yann, as to what is going on here? Should I be specifying the number of layers on all of the surfaces?

First of all this was a long shot, I'm glad it actually worked!

Now what is going on...
As I understand it : specifying 0 layers ensure the patch will not be affected by the layer addition. It's a way to freeze the patch. Not specifying anything means the patch might be affected by the layer addition, even if there is no layer to be inserted on this patch.

The best example for that would be the side walls of your cube. You didn't specify anything for those patches in the layers section, but they are affected by the layer addition on Zneg (see screenshot)
If you specify 0 layers on those walls, it will be frozen and the layers will get killed close to the wall.

Now concerning your cube top face it is pretty hard to now why you get this result. I can only guess it might be a side effect of the mesh morphing on the side walls and surrounding mesh.

So whether your should define a number of layers or not depends on what behavior to want on the patch.

That's brilliant. I tested it with another case, for a cylinder on a surface ("ground"):
- if I do not specify anything for the sides and top of the cylinder, the mesh shrinkage really mangles the interior mesh, corrupting the snapping to the cylinder (see pics 1 & 2);
- if I explicitly specify 0 layers on the sides and top of the cylinder I get some degenerate cells at the bottom of the cylinder, at the point where the cylinder meets the ground (see pic 3)
- and if I explicitly specify 0 layers on the top alone I get a perfect mesh (see pic 4)

Just a quick update on this one - I tried snappyHexMesh under v2112, and got exactly the same behaviour with the same setup ... there are clearly more options in the v2112, but I stuck with the default shrinkage model and just read the notes in the annotated SHM dictionary, and this prompted me to try adding the following to the addLayersControls section:

Code:

nMedialAxisIter 10;

and magically this once again fixed the shrinkage distortion issue without having to tell SHM to put zero layers on the cube/cyl top ... ie had the same effect.

Interesting. I never touched this and wouldn't have either in this situation. Also I am finding the doc weird one this, its a num of iteration kind of parameter but seems to spatially limit the zone of influence of the distortion. How do I know the extent of this region by the number of iterations? Ominous!

Thanks for your feedback Tobermory, I would not have thought to use this parameter for this specific issue.
Now I wonder what kind of influence it can have on other cases.