[deji]

Hello Foamers. I am having some trouble with snappyHexMesh. After generating a mesh with blockMesh, I utilize snappyHexMesh to refine the grid in two regions, one region comprises the turbulent boundary layer, and the other is next to the first region. However, when I run the simulation and get my results, they are totally screwed up. It seems snappyHexMesh is doing something funny to the grid. I must say though, the initial mesh does not have an aspect ratio even close to 1. I am using LES turbulent boundary layer grid criteria (wall units).

So is snappyHexMesh only good for aspect ratios close to 1?



Deji

[deji]

/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 1.7.1 |
| \\ / A nd | Web: www.OpenFOAM.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object snappyHexMeshDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
// Which of the steps to run
castellatedMesh true;
snap false;
addLayers false;

// 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
geometry
{

Box1
{
type searchableBox;
min (0 0 0.00);
max (1.00 1.00 4.20);
}
/* Box2
{
type searchableBox;
min (0.40 0 0.00);
max (0.50 1.00 4.20);
}*/
/*
fridgeFreezer
{
type searchableSurfaceCollection;
mergeSubRegions true;
freezer
{
surface box1;
scale (1 1 1);
transform
{
type cartesian;
origin (0 0 0);
e1 (1 0 0);
e3 (0 0 1);
}
}
fridge
{
surface box1;
scale (1 1 1.1);
transform
{
type cartesian;
origin (0 0 1);
e1 (1 0 0);
e3 (0 0 1);
}
}
}
twoFridgeFreezers
{
type searchableSurfaceCollection;
mergeSubRegions true;
seal
{
surface box1;
scale (1.0 1.0 2.1);
transform
{
type cartesian;
origin (2 2 0);
e1 (1 0 0);
e3 (0 0 1);
}
}
herring
{
surface box1;
scale (1.0 1.0 2.1);
transform
{
type cartesian;
origin (3.5 3 0);
e1 (1 0 0);
e3 (0 0 1);
}
}
}
*/
};

// Settings for the castellatedMesh generation.
castellatedMeshControls
{
// Refinement parameters
// ~~~~~~~~~~~~~~~~~~~~~
// If local number of cells is >= maxLocalCells on any processor
// switches from from refinement followed by balancing
// (current method) to (weighted) balancing before refinement.
maxLocalCells 3000000;
// 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 4000000;
// 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 100;
// 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.
features
(
{
file "fridgeA.eMesh";
level 3;
}
);

// 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.
refinementSurfaces
{
twoFridgeFreezers
{
// Surface-wise min and max refinement level
level (2 2);
regions
{
// Region-wise override
"cook.*"
{
level (3 3);
}
}
}
"iglo.*"
{
// Surface-wise min and max refinement level
level (1 1);
}
}
// Resolve sharp angles on fridges
resolveFeatureAngle 60;

// 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.
*/
features
(
{
file "A.eMesh";
level 1;
}
);
resolveFeatureAngle 30;
refinementSurfaces
{
}
refinementRegions
{
Box1 //near wall region
{
mode inside;
levels ((1.00 1)); //disregards the 1.00 entry,for distance!!!
}
/* Box2
{
mode inside;
levels ((1.00 1));//disregards the 1.00 entry,for distance!!!
}*/
}

// 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.01 0.003 0.09);

// Whether any faceZones (as specified in the refinementSurfaces)
// are only on the boundary of corresponding cellZones or also allow
// free-standing zone faces. Not used if there are no faceZones.
allowFreeStandingZoneFaces true;
}

// Settings for the snapping.
snapControls
{
//- 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.
addLayersControls
{
/*
// Are the thickness parameters below relative to the undistorted
// size of the refined cell outside layer (true) or absolute sizes (false).
relativeSizes true;
// Per final patch (so not geometry!) the layer information
layers
{
"two.*"
{
nSurfaceLayers 3;
}
"igloo_.*"
{
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.
// is the thickness of the layer furthest away from the wall.
// See relativeSizes parameter.
finalLayerThickness 0.5;
//- 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.
// See relativeSizes parameter.
minThickness 0.25;
//- 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 0;

// 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
// Note: changed(corrected) w.r.t 16x! 90 degrees corresponds to 130 in 16x.
minMedianAxisAngle 90;
// Create buffer region for new layer terminations
nBufferCellsNoExtrude 0;

// Overall max number of layer addition iterations. The mesher will exit
// if it reaches this number of iterations; possibly with an illegal
// mesh.
nLayerIter 50;
*/
}

// Generic mesh quality settings. At any undoable phase these determine
// where to undo.
meshQualityControls
{
//- 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 pyramid volume. Is absolute volume of cell pyramid.
// Set to a sensible fraction of the smallest cell volume expected.
// Set to very negative number (e.g. -1E30) to disable.
minVol 1e-13;
//- Minimum tet volume. Is absolute volume of the tet formed by the
// face-centre decomposition triangle and the cell centre.
// Set to a sensible fraction of the smallest cell volume expected.
// Set to very negative number (e.g. -1E30) to disable.
minTetVol 1e-20;
//- 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;

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

[val46]

What do you mean by screwed up?
Is the solution converged?
What does checkMesh say?

[deji]

Thanks !!!! Well the solution is not right, when I compute for example the heat transfer scaling (LES of Wall Bounded Turbulent Natural Convection Flow), it is completely wrong. My simulations were fine until I began to use snappyHexMesh hoping to save on computational cost.

I am solving for a flow that transitions from laminar to turbulent over a heated vertical plate, so I would think OpenFOAM should be able to handle this, although the mesh does not have aspect ratio close to 1 at all. Would the aspect ratio matter if I am only refining the turbulent boundary layer region?

I have not used the checkMesh utility, I will try that today. So if checkMesh is okay, what does that mean?

Best regards,
Deji

[grjmell]

We've found that snappyHex is quite sensitive to aspect ratio and that it is best to keep the initial aspect ratio below 2:1. checkmesh tells you whehter or not your mesh passes the quality criteria which is helpful. it will not tell you whether you'll get a sensible solution however...

[deji]

Hello Foamers. I am even more confused now. I made a new mesh with blockMesh and made sure the aspect ratios were 1:1. Used checkMesh, and all was well, however, when I ran my case again, the solution was not right. But, when I ran the case without using snappyHexmesh, the solution behaved as I expected. So, this tells me that perhaps my snappyHexmesh file is not correct. Can anyone help......

[deji]

Hello everyone. I hope someone can give me some possible feedbacks as to what might be causing my CFD calculation to become inaccurate after refining the mesh with snappyhexmesh. Can anyone think of why this might be happening?

Being able to utilize the snappyhexmesh tool would greatly reduce my computational cost and time...

[deji]

I am just confused as to why my solution would change after using snappyHexmesh and that should never happen...

[longamon]

hey, I'm also interested in using the snappyhexmesh, have been looking into it.
Are you using non-orthogonal correctors?

[deji]

I am not sure if I have come across that while using snappyHexmesh. I am basically meshing the flow over a flat plate, so it is a fairly simple geometry. Is non-orthogonal correctors in the snappyHexmeshdict?

[longamon]

since snappyhexmesh usually builds non-orthogonal meshes you should account for this. The option for this is in the fvSolution file.
You can additionally modify in the fvSchemes file the discretization schemes to account for non-orthogonality using corrected or limited schemes.

[deji]

Maybe that is the problem. I just looked into the surface normal gradient schemes in OpenFOAM, and the coefficient psi should be 1 for corrected. I will look more into this and see if it changes my solution. I think this might be the problem.

So, snappyHexmesh refines the mesh based on non-orthogonality? It is definitely a powerful tool that greatly reduces computational cost especially for wall bounded high Reynolds number turbulent boundary layer flows.

Best regards,
Deji

[longamon]

The power of snappy hex mesh is the posibility of concentrating the computer resources where you need. The transition between the refined cells and the ones that are not is done using piramidal (as the are shown on paraview) cells. Also, inside snappyhexmeshdict (meshQualityControls) theres a part to help limit non-orthogonality, skewness and other geometric factors.

[deji]

Thank you David. I just started looking into snappyHexmesh 2 days ago, and it can be very powerful. I will look into all those things to accout for non-orthogonality and limiting it. Thanks.

Best regards,
Deji

[deji]

Hello Foamers. So, I have discovered what the problem is with my solution. I wrote a post-processor to compute the wall normal temperature gradient in order to compute the heat transfer scaling. The post-processor also averages in the spanwise direction (homogeneous axis), however using snappyHexmesh, it seems that the numbering of my domain has somewhat changed. Hence, when I spatially average, it seems it cannot be done the previous way it was done when snappyHexmesh was not utilized. So, I have to figure this new one out. Thanks.

Deji

[LeeRuns]

The best approach here is to ensure that the mesh has a low number of "Highly Non-Orthogonal Faces". This should be done during the meshing phase (snappyhexmesh). The non-orthogonal correctors can lead a "hyper-convergent algorithm (ie simpleFoam will converge on the wrong answer). I know that the developers of ofoam are careful with deciding things like the checkMesh.


To put it simply, i find openfoam to be a nightmare when i have a mesh that doesn't pass checkMesh, but when I do have a mesh that passes "i be like"->

[B_R_Khan]

Hi!

I am having the same problem as yours; My snappyHexMesh has max non orthogonality of 64, aspect ratio 15, has some concave cells as well. The mesh looks visibly fine but I have tried using pimpleFoam and SimpleFoam on it with various boundary conditons and all of the simulations failed to produce required results or failed to converge.

Do you know how were you able to resolve your issues?
Do concave cells cause any problem?