CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Meshing & Mesh Conversion

[snappyHexMesh] Refinement region - distance not working

Register Blogs Community New Posts Updated Threads Search

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   May 3, 2019, 05:50
Default Refinement region - distance not working
  #1
Member
 
Rasmus Iwersen
Join Date: Jan 2019
Location: Denmark
Posts: 81
Rep Power: 8
Rasmusiwersen is on a distinguished road
Hi all,

I am experiencing troubles with the snappyHexMesh utility refinement regions, under the castellatedMesh subdictionary.

The problem is, when i look at my mesh in paraview, the refinement distance specified under refinement region is not the same in x- any y-directions. The y-directions seems to have lower priority compared to the x-direction.

So far I think i have narrowed it down to maxLocalCells and perhaps also maxGlobalCells. I think i have discovered that turning them both up help the problem slightly, however letting both maxLocalCells and maxGlobalCells increase to several millions, the entire domain will eventually consist of an inexpediently large number of cells.

So can anyone confirm or perhaps correct my findings?

It is worth mentioning that if the refinement level is changed from 5 to 4, a "perfect" circle is made around the two cubes that i am trying to mesh.

Please see following part of snappyHexMeshDict:

/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2.2.2 |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ 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
{
cube.stl
{
type triSurfaceMesh;
name cube;

patchInfo
{
type wall;
}
}
cube1.stl
{
type triSurfaceMesh;
name cube1;

patchInfo
{
type wall;
}
}
};


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

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

// Allow a certain level of imbalance during refining
// (since balancing is quite expensive)
// Expressed as fraction of perfect balance (= overall number of cells /
// nProcs). 0=balance always.
maxLoadUnbalance 0.10;


// Number of buffer layers between different levels.
// 1 means normal 2:1 refinement restriction, larger means slower
// refinement.
nCellsBetweenLevels 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.
features
(
{
file "cube.eMesh";
level 5;
}
{
file "cube1.eMesh";
level 5;
}
);



// 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
{
cube
{
// Surface-wise min and max refinement level
level (5 5);

// Optional specification of patch type (default is wall). No
// constraint types (cyclic, symmetry) etc. are allowed.
}
cube1
{
// Surface-wise min and max refinement level
level (5 5);

// Optional specification of patch type (default is wall). No
// constraint types (cyclic, symmetry) etc. are allowed.
}
}

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

refinementRegions
{
cube
{
mode distance;
levels ((0.125 5) (0.425 4) (1.25 1)); //(level 1) (level 2) (level 3)
}
cube1
{
mode distance;
levels ((0.125 5) (0.425 4) (1.25 1)); //(level 1) (level 2) (level 3)
}
}


// 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 (5 1 0.5);


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

[IMG]file:///C:/Users/Rasmus%20Iwersen/Desktop/good.PNG[/IMG]
Rasmusiwersen is offline   Reply With Quote

Old   May 3, 2019, 06:37
Default
  #2
Senior Member
 
Yann
Join Date: Apr 2012
Location: France
Posts: 1,074
Rep Power: 26
Yann will become famous soon enough
Hello Rasmus,

The comments in snappyHexMeshDict are pretty clear:

Code:
// 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 8000000;
Both maxLocalCells and maxGlobalCells parameters allow you to control the maximum size you allow for your mesh. You can set it according to your hardware specifications to avoid running out of RAM during meshing.
BUT, it means you accept that snappyHexMesh stops refinement process to respect these parameters.

The proper way to do it is to set high values of maxLocalCells and maxGlobalCells and to define your blockMesh cells size and refinement levels in order to reach an acceptable mesh size depending on your needs and available resources. If you want a good quality mesh, maxLocalCells and maxGlobalCells should not be the limiting parameters.

Keep in mind snappyHexMesh uses a refinement process based on the octree structure: each additional refinement level will split a cell into 8 smaller cells. Depending on the geometry, one additional level of refinement can drastically increase your mesh size.

It's up to you to define the initial cell size, and maximum refinement level you can set to avoid creating inexpedient large meshes.


Yann
Yann is offline   Reply With Quote

Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
[snappyHexMesh] No satisfying result with feature edge refinement Krapf OpenFOAM Meshing & Mesh Conversion 5 December 13, 2019 06:59
[snappyHexMesh] SHM doesn't create cellZones for one region Eko OpenFOAM Meshing & Mesh Conversion 10 January 24, 2018 02:03
conjugate heat transfer in OpenFOAM skuznet OpenFOAM Running, Solving & CFD 99 March 16, 2017 05:07
[snappyHexMesh] SnappyHexMesh not enough refinement simplefoam OpenFOAM Meshing & Mesh Conversion 2 August 30, 2013 03:37
[Commercial meshers] Using starToFoam clo OpenFOAM Meshing & Mesh Conversion 33 September 26, 2012 04:04


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