CFD Online Discussion Forums

CFD Online Discussion Forums (
-   OpenFOAM Native Meshers: snappyHexMesh and Others (
-   -   Inside and outside mesh with snappyhexmesh (

nzy102 August 31, 2008 23:56

Inside and outside mesh with snappyhexmesh

I am practicubg a simple case using snappyhexmesh. Basically I am trying to mesh a 2D circle from both inside and outside. The outside mesh looks perfect without any problem. The inside mesh, looks pretty ugly on the boundary. It looks like that there is some problem with snapping without inside mapping. All the parameters are the same for both cases except the locationinmesh. I am just wondering if there is something different in terms of parameter setup for the inside meshing? Thank you.

mattijs September 1, 2008 04:14

There is no inherent differenc
There is no inherent difference between meshing inside and outside. Your inside mesh looks very undistorted (inside points have not moved at all). Could be that there is something special about not having a non-meshed boundary. Can you post the surface and the snappyHexMeshDict?

nzy102 September 1, 2008 13:58

================================================== ==================================================
| | |
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \ / O peration | Version: 1.0 |
| \ / A nd | Web: |
| \/ M anipulation | |

version 2.0;
format ascii;

root "/home/penfold/mattijs/foam/mattijs2.1/run/icoFoam";
case "cavity";
instance "system";
local "";

class dictionary;
object autoHexMeshDict;

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

// Which of the steps to run
castellatedMesh true;
snap true;
addLayers false; // true;

// Geometry. Definition of all surfaces. All surfaces are of class
// searchableSurface.
// Surfaces are used
// - to specify refinement for any mesh cell intersecting it
// - to specify refinement for any mesh cell inside/outside/near
// - to 'snap' the mesh boundary to the surface
type triSurfaceMesh;
name circle;

type searchableBox;
min (-2 -2 0);
max ( 2 2 0.01);

// Settings for the castellatedMesh generation.

// 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 1000000;

// 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 2000000;

// 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 0;

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

// 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 "someLine.eMesh";
// level 2;

// 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);

// Resolve sharp angles on fridges
resolveFeatureAngle 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.

// circle
// {
// mode inside;
// mode outside;
// levels ((1.0 2));
// levels ((1E15 2));
// }

mode inside;
levels ((1.0 2));


// 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 (0.5 0.6 0.004);
// locationInMesh (0 0 0.004);
// locationInMesh (-1 -1 0.005);

// Settings for the snapping.
//- Number of patch smoothing iterations before finding correspondence
// to surface
nSmoothPatch 3;

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

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

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

// Settings for the layer addition.
// Per final patch (so not geometry!) the layer information
nSurfaceLayers 1;

// Expansion factor for layer mesh
expansionRatio 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 0.3;

//- 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.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;

// Advanced settings

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

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

// Number of smoothing iterations of surface normals
nSmoothSurfaceNormals 1;

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

// Smooth layer thickness over surface patches
nSmoothThickness 10;

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

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

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

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

// Generic mesh quality settings. At any undoable phase these determine
// where to undo.
//- Maximum non-orthogonality allowed. Set to 180 to disable.
maxNonOrtho 65;

//- Max skewness allowed. Set to <0 to disable.
maxBoundarySkewness 20;
maxInternalSkewness 4;

//- Max concaveness allowed. Is angle (in degrees) below which concavity
// is allowed. 0 is straight face, <0 would be convex face.
// Set to 180 to disable.
maxConcave 80;

//- Minimum projected area v.s. actual area. Set to -1 to disable.
minFlatness 0.5;

//- Minimum pyramid volume. Is absolute volume of cell pyramid.
// Set to very negative number (e.g. -1E30) to disable.
minVol 1e-13;

//- Minimum face area. Set to <0 to disable.
minArea -1;

//- Minimum face twist. Set to <-1 to disable. dot product of face normal
//- and face centre triangles normal
minTwist 0.05;

//- minimum normalised cell determinant
//- 1 = hex, <= 0 = folded or flattened illegal cell
minDeterminant 0.001;

//- minFaceWeight (0 -> 0.5)
minFaceWeight 0.05;

//- minVolRatio (0 -> 1)
minVolRatio 0.01;

//must be >0 for Fluent compatibility
minTriangleTwist -1;

// Advanced

//- Number of error distribution iterations
nSmoothScale 4;
//- amount to scale back displacement at error points
errorReduction 0.75;

// Advanced

// Flags for optional output
// 0 : only write final meshes
// 1 : write intermediate meshes
// 2 : write volScalarField with cellLevel for postprocessing
// 4 : write current intersections as .obj files
debug 0;

// Merge tolerance. Is fraction of overall bounding box of initial mesh.
// Note: the write tolerance needs to be higher than this.
mergeTolerance 1E-6;

================================================== ========================================

Attached is snappyhexmeshdict without boundary layers. However, when I applied the BC layers, it doesn't make any difference.

mattijs September 2, 2008 03:57

Can you post the circle.stl an
Can you post the circle.stl and the blockMeshDict you used?

nzy102 September 2, 2008 12:30

Thank you for your help, J

Thank you for your help, Janssens.


nzy102 September 2, 2008 12:32

here they are.
here they are. circle.stl.tar.gz blockMeshDict

mattijs September 2, 2008 14:21

It does not like the very high
It does not like the very high aspect ratio cells in your blockMesh. I scaled the stl in z-direction

surfaceTransformPoints -scale '(1 1 100)' circle.stl circle3D.stl

and made the blockMesh generate aspect ratio 1 cells. blockMeshDict snappyHexMeshDict

nzy102 September 2, 2008 22:07

Janssens: I adjusted the as

I adjusted the aspect ratio to 1 in my blockMesh. However, I got a new problem. When I checked my mesh, I got some warnings like:

================================================== ===========================
***Number of edges not aligned with or perpendicular to non-empty directions: 7880
<<Writing 4908 points on non-aligned edges to
set nonAlignedEdges
================================================== ===========================

If you take a look at mesh from side view as shown below, the edges are not perpenticular to any direction. Here are my new stl file, my blockMeshDict, and my snappyHexMeshDict. circle1.stl.tar.gz blockMeshDict snappyHexMeshDict


mattijs September 3, 2008 03:55

Your mesh is 3D, snappyHexMesh
Your mesh is 3D, snappyHexMesh is a 3D mesher - it splits cells in all three directions. You cannot have empty patches on a 3D mesh.

nzy102 September 3, 2008 13:10

Janssens: Thank you for you

Thank you for your reply. I got rid of the empty patches and didn't get any warning after checkMesh. But still my question remains. Take a look at the second pic of my last post. Angles between top (bottom) walls and side walls are not exactly 90 degrees after mesh. How to fix this? Attached below is zoomed-in pic. Thank you.


mattijs September 4, 2008 04:31

bholbek December 11, 2008 12:22

Hi, How should i specify to

How should i specify to snappyHexMesh that i want to mesh inside the geometry and not outside?



lord_kossity December 11, 2008 12:41

Hi Bastien, in system/snapp
Hi Bastien,

in system/snappyHexMeshDict, line 148 (or close to it), you are able to specify a point that will be in the meshed region.


albcem January 12, 2009 20:36

I am still curious about the o
I am still curious about the original question:

How does one instruct snappyhexmesh to keep the 2 sides of the generated volume grid at the same time?

Essentially, I have two volumetric regions separated by an "Interface" mesh layer of arbitrary shape.

When I assign a coordinate point to "locationInMesh", snappyhexmesh automatically drops the volume on the opposite side of the Interface, which is no good. I want to keep the 2 sides and assign them to 2 separate cellzones if possible.

The dirty way around may be to be to assign to "locationInMesh" 2 different coordiantes on 2 seperate snappyhexmesh runs and then use merge/stitch mesh commands on the resulting meshes. This approach creates unnecessary overheads and would probably degrade quality.

Should I edit the snappyhexmesh code so that it accepts multiple locationInMesh arguments? This way a lot of issues with multi-phase modeling may be addressed...

Opinions/pointers are greatly appreciated.



MikeMac April 29, 2013 05:30

Hi albcem,

I just came across this thread now and I am trying to do something similar in shm. Were you ever able to figure out a way to include multiple locationInMesh lines? I'm just about to try to edit the shm code myself, but I want to avoid this if someone else has already come up with a solution.



wyldckat May 2, 2013 10:32

Greetings Mike and welcome to the forum!


Originally Posted by MikeMac (Post 423808)
I just came across this thread now and I am trying to do something similar in shm. Were you ever able to figure out a way to include multiple locationInMesh lines? I'm just about to try to edit the shm code myself, but I want to avoid this if someone else has already come up with a solution.

You can only use a single "locationInMesh". But as of OpenFOAM 2.0, you can use snappyHexMesh to generate multi-region meshes. Have a look at the tutorial "mesh/snappyHexMesh/snappyMultiRegionHeater". This way you can have a mesh for both inside, outside and inside several other geometries as well!

Best regards,

MikeMac May 8, 2013 07:26

Hi Bruno,

Thanks for the reply!

I've looked at the tutorial and I've made my case work for when I have my surfaces saved in multiple stl files. However, I would also like to be able to do the same thing when I have a single stl file with multiple regions within it. For instance, I have a simple box and sphere, and when I have them in separate stl files I can get inside and outside meshes. In this case, my refinementSurfaces look like:

level (2 2);
faceZone box;
cellZone box;
cellZoneInside inside;

level (2 2);
faceZone sphere;
cellZone sphere;
cellZoneInside outside;

But when I have them in the same "BoxAndSphere" stl file, it doesn't work with:

level (2 2);
level (2 2);
faceZone box;
cellZone box;
cellZoneInside inside;
level (2 2);
faceZone sphere;
cellZone sphere;
cellZoneInside outside;

Are you familiar with a way to fix this? I'm really new to shm, so thanks in advance for any advice you have!


wyldckat May 8, 2013 17:04

Hi Mike,

AFAIK, snappyHexMesh deals with STL files in the following way:
  • An STL "solid-endsolid" block inside any STL file is a patch or wall.
  • A single STL file is a geometry.
Therefore, if you want a closed geometry, it must all be placed inside a single STL file.

I don't think OpenFOAM 2.2 has a new way to break down a single STL file into separate blocks, using only the "snappyHexMeshDict". My best guess would be to refer to the STL file twice in the geometry section and assigning different names to each reference... but I think snappyHexMesh will complain if you do this, because the same geometry name is used twice.

Either way, I suggest that you aim to the perspective of "keeping things simple" and keeping in mind that "optimum is the enemy of good". ;)

Because the only other way that comes to mind is that you can indeed use a single STL file to create the mesh you need, but having only a single zone. Then, to create the zones you need, you'll have to rely on topoSet to use the STL file to redefine the associated zones. Problem with this scenario, topoSet will probably still complain about which "solid" to use from inside the STL...

So, in the end: it just plain better to keep one geometry per STL file. ;)

Best regards,

All times are GMT -4. The time now is 22:41.