[ziad]

Hi all,

I wonder if anybody can comment on the RAM consumption of snappyHexMesh. I managed to create a starting mesh of about 620,000 cells and 905,000 points. Obviously a very moderate mesh size, but is taking over 7GB of RAM!!!!! Based on my experience with other meshers such as GridGen, Pointwise and ICEM-CFD this is very large.

Any idea how one can reduce snappy's appetite?

Ziad

[bastil]

Originally Posted by ziad

I managed to create a starting mesh of about 620,000 cells and 905,000 points. Obviously a very moderate mesh size, but is taking over 7GB of RAM!!!!! Based on my experience with other meshers such as GridGen, Pointwise and ICEM-CFD this is very large. Ziad

Ziad,

as you mentioned this is a starting mesh size. Mesh can become much larger.... You can limit both the maximum of total cells created and the maximum cells per core in snappyHexMeshDict. You can also run it in parallel. What version of sHM are you using? Which step is the problem? Castellating snapping or layer addition?
Tetra-Meshers use a different principal so this is hard to compare. From my experience sHM comsumes about 1.5GB/1Mio but it is dependent mainly on layer generation.

Regards Bastian

[ziad]

Originally Posted by bastil

Ziad,

as you mentioned this is a starting mesh size. Mesh can become much larger.... You can limit both the maximum of total cells created and the maximum cells per core in snappyHexMeshDict. You can also run it in parallel. What version of sHM are you using? Which step is the problem? Castellating snapping or layer addition?
Tetra-Meshers use a different principal so this is hard to compare. From my experience sHM comsumes about 1.5GB/1Mio but it is dependent mainly on layer generation.

Regards Bastian

Hi Bastian,

Thanks for your reply.

Running OpenFOAM 1.7.0 in parallel on 4 cores of a PhenomII machine. Total RAM available is 7.8GB, hence the memory concern.

The mesh is computed without any problem that I can see, but then I am fairly new to snappy so maybe a more experienced eye can notice something I missed. The output log and snappyHexMeshDict are both provided.

Increasing the minDeterminant from 0.2 (previous post) to 0.35 improved the memory consumption and reduced the mesh size to 548,511 cells and 833,114 points. Consumption is now just about 6GB, but still high.

The CAD has features that cover 3 orders of magnitude in detail (25m to 0.1m). Layer specs are not aggressive and so far I am sticking to 1 surface layer everywhere.

Ziad

[ziad]

problem solved by separating the small surfaces from the larger ones. The mesh size was reduced by 3 and the memory consumption is now about 2GB-2.5GB. still pricy but at least it's manageable.

[Greg Givogue]

Thanks Ziad,

I've been having a similar problem. Can you post the decomposeParDict file?

Greg

[ziad]

sure thing. I am using the simple decomposition. nothing fancy there.

FoamFile
{
version 2.0;
format ascii;

root "";
case "";
instance "";
local "";

class dictionary;
object decomposeParDict;
}

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

numberOfSubdomains 4;

method simple;
//method metis;
//method parMetis;

simpleCoeffs
{
n (2 2 1);
delta 0.001;
}

hierarchicalCoeffs
{
n (3 2 1);
delta 0.001;
order xyz;
}

manualCoeffs
{
dataFile "cellDecomposition";
}

metisCoeffs
{
//n (5 1 1);
//cellWeightsFile "constant/cellWeightsFile";
}

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

[Greg Givogue]

Thanks. Are you using a specific tutorial for the basis of your case?

I've been using the motorBike tutorial as a basis for my analysis. Whenever I refine the mesh in my case or in the motorBike tutorial in snappy I get either a segmentation fault or printstack error. I thought initially it was a ram issue (as discussed above) in my virtual machine so I increased it from 3.5 GB to 11 GB but that did not get rid of these errors.

In the snappyHexMeshDict file of the motorBike tutorial if you change the refinementsurfaces level (5 6) (line 115) to level (7 8) and run it - that's when I get the error. Can someone explain this? I have spent a lot of time playing with the snappyHexMeshDict file from the motorBike tutorial and adapting it to my geometry but I can't seem to get a finer mesh.

I've read that it might have something to do with the fvsolutions and fvschemes files of the motorBike tutorial but I'm not really sure. I don't really understand what either has to do with snappy.

I'd really appreciate any suggestions you may have. I'm really stuck here.

Thanks again!

I'm running OF 1.7.0 in Virtualbox with 11 GB ram on a quad core iMac (2.66 GHz).

[ziad]

I actually put together my own case. Ran the motorbike tutorial the first time successfully but ended doing my own thing. In my case every single surface is defined in its own stl file and every intersection is defined by an explicit feature edge with its own refinement level. I found that it makes things easier. Still not perfect though since my geometry has nothing but perpendicular surfaces and straight edges, a very Cartesian building. Pythagoras would be proud

What you could do to reduce mesh size if to reduce the overall domain size to slightly larger than the refinement box and then merge it back with the other upstream and downstream chunks with mergeMeshes and stitchMesh. It worked for me.

As for platform I am running OpenSuSe 11.2 and OF1.7.0 on a PhenomII X4, without any virtual machines. Sorry but I am not familiar with OSX. However, 11GB of virtual RAM seems a bit exaggerated. How much physical RAM do you have? I would guess that if your virtual memory exceeds your physical memory by some amount then one should expect stack errors. Keep in mind OSX requires a minimum memory to run as well. Can you switch to a Linux box?

What kind of geometry do you need to mesh?

[Greg Givogue]

Thanks for response and the suggestions. I am running Virtualbox on my mac and the virtual OS is Ubuntu 10.04 in which OF resides. Virtual ram is 11 GB and the physical ram is 12 GB. I was just about to try sectioning the body into separate stl files. Right now it's one stl with regions defined within. I think that this is suppose to behave the same as separate stls but I don't think it is. I'll give that a shot and report back.

The geometry is similar to the centre line fuel tank on a fighter jet. It's cigar shape (streamlined) with a mounting frame on one side. I used the motorBike tutorial because it seemed to best fit my problem. I will post an image shortly.

[Greg Givogue]

Here's the geometry.

[ziad]

It's probably the thin plates in the attachment frame. Is that the reason why you need to go with (7 8) refinement levels?

I would do this:
* Try to separate each plate in as many separate faces as possible.
* Separate as well the thin edges and use equal min-max levels on each face. All faces do not need to have the same min-max combo so you can adjust to the local dimensions.
* Use straight lines on the edge intersections with higher level to resolve the intersection regions (example: (5 5) for the face and 7 for the edge).
* Use nCellsBetweenLevels 1

Here's an example of my setup:

geometry
{
BigCondenser.stl
{
type triSurfaceMesh;
name BigCondenser;
regions
{
BIGCONDENSER // this is the name you just type in the stl file after keywords solid and endsolid
{
name BIGCONDENSER;
}
}
}
.
.
.
// Big Condenser lines
{
file "H0H1.eMesh";
level 6;
}
.
.
.
refinementSurfaces
{
BigCondenser
{
level (4 4);
}
.
.
.
addLayersControls
{
relativeSizes true;

// Per final patch (so not geometry!) the layer information
layers
{
BIGCONDENSER // this is the patch name
{
nSurfaceLayers 1; // you can add more with refineMesh later
}

going to bed now. let me know how it works.

[Greg Givogue]

Exactly, the support frame is where I get poor meshing results. I played around with surface/region refinements and surface layers. I have set up my stl files and snappyHexMeshDict file as recommended.

I like your suggestion of using the 'features' refinement and focusing on the edges and faces. I had read that it effectively doesn't work but I will give it a shot. I'm a little confused about the file type it requires to describe an edge, .eMesh? edgeMesh? Do you have an example?

I'd be happy to provide you with my stl files if you'd like to take a look at them - just send me your email address. Thanks again for all your help.

Here's my snappyHexMeshDict;


// List steps to run
castellatedMesh true;
snap true;
addLayers 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
geometry
{
pod.stl //stl file located in constant/trisurface
{
type triSurfaceMesh;
name pod;
regions
{
POD
{
name POD;
}
}
}

bracket1.stl
{
type triSurfaceMesh;
name bracket1;
regions
{
BRACKET1
{
name BRACKET1;
}
}
}
bracket2.stl
{
type triSurfaceMesh;
name bracket2;
regions
{
BRACKET2
{
name BRACKET2;
}
}
}
bracket3.stl
{
type triSurfaceMesh;
name bracket3;
regions
{
BRACKET3
{
name BRACKET3;
}
}
}

bracket4.stl
{
type triSurfaceMesh;
name bracket4;
regions
{
BRACKET4
{
name BRACKET4;
}
}
}

frame.stl
{
type triSurfaceMesh;
name frame;
regions
{
FRAME
{
name FRAME;
}
}
}

// refinementBox// geometry is bound by this region in environment
//{
// type searchableBox;
//min (-0.5 -0.475 0.0);
//max ( 8.0 0.925 2.0);
//}
};



// 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 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 10; //changed from 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 of cells between different levels of refinement.
// 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 "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.

refinementSurfaces
{
pod
{
level (2 3);
}

bracket1
{
level (2 3);
}

bracket2
{
level (2 3);
}

bracket3
{
level (2 3);
}

bracket4
{
level (2 3);
}

frame
{
level (2 3);
}
}

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

refinementRegions
{
//refinementBox
//{
//mode inside;
// levels ((1E15 5)); // distance is ignored (1E15) but must be listed
// }
//pod
//{
// mode distance;
//levels ((0.01 6)); // refined mesh near surface (1 cm) at refinement level
//}
}


// 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 (3 3 0.43);
}



// Settings for the snapping.
snapControls
{
//- Number of patch smoothing iterations before finding correspondence
// to surface
nSmoothPatch 10; //was 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 1; // was 4

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

//- Maximum number of snapping relaxation iterations. Should stop
// before upon reaching a correct mesh.
nRelaxIter 5; //was 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
{
POD
{
nSurfaceLayers 1;
}
BRACKET1
{
nSurfaceLayers 1;
}
BRACKET2
{
nSurfaceLayers 1;
}
BRACKET3
{
nSurfaceLayers 1;
}
BRACKET4
{
nSurfaceLayers 1;
}
FRAME
{
nSurfaceLayers 1;
}
}

// Expansion factor for layer mesh
expansionRatio 1.5; //was 1.0

//- Wanted thickness of final added cell layer. If multiple layers
// is the thickness of the layer furthest away from the wall.
// See relativeSizes parameter.
finalLayerThickness 0.8; //was 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.001;//was 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; //was 1


// Advanced settings

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

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

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

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

// Smooth layer thickness over surface patches
nSmoothThickness 10;

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

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

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

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

// Overall max number of layer addition iterations
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 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 a sensible fraction of the smallest cell volume expected.
// 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.02;

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

[ziad]

Looks good but you still need to separate the brackets in individual faces. I use salome and this is best done with the explode function under the new entity menu. I don't think it makes a difference whether you pick shell or face as the sub-entity type.

Another trick to reduce the number of cells is to jack up the minDeterminant parameter. The higher it is the more hexahedra you have and hexahedral meshes have a number of cells roughly equal to the number of points. For my case the optimum range was 0.1 < minDeterminant < 0.3.

You should use *.eMesh files in the triSurface folder. See example attached. You can email me at ziad dot boutanios at gmail dot com.

[Greg Givogue]

Thanks again. I'll give those a shot and report back. I'm trying to get snapEdge to work as well for my case - I'm getting moderate results so far. I'll send you an email later tonight with my case. I really appreciate the help - otherwise I'd be really stuck and losing my mind!

I'm not sure if increasing the minDeterminant is the best idea for my case because of the contours along the pod surface.

[ziad]

Don't worry about it. We all learn from each other on the forums.

I tried snapEdge before and did not really like the result since my geometry has nothing but perpendicular edges. A really extreme case. The mesh did not pass the checkMesh after snapEdge and I found that it was better to minimize the problem with the eMesh edges. It might work better for you though. Looking forward to see the result.

Why should the contours suffer from increasing minDeterminant?

BTW how big is your mesh so far?

[Greg Givogue]

The last attempt I made produced about 200k cells. I had originally dabbled with Salome but I found it couldn't produce stl files with a high enough degree of tessellation. This is important in my case for contoured shapes to be reasonably smooth. It would probably be sufficient for the brackets and frame of my problem if/when I go down the face/edge path. I found that SolidWorks can produce high quality stl files. Anyway, I will email you my latest attempt shortly.
Thanks again!

[ziad]

here is my snappyHexMeshDict for reference if it can help.

[Greg Givogue]

thanks - just for everyone else - Ziad ran my case with no errors. We both think that it has something to do with my Virtualbox 3.2.6 or Ubuntu 10.04 ....

[ziad]

why use a virtual machine when you can run native...

http://www.cfd-online.com/Forums/ope...?highlight=osx

[Greg Givogue]

I downloaded VMWare Fusion 3 and it seems to be working really well with Ubuntu 10.04 as the guest.