[nzy102]

Hey:

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]

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]

================================================== ==================================================
/*---------------------------------------------------------------------------*\
| | |
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \ / O peration | Version: 1.0 |
| \ / A nd | Web: http://www.openfoam.org |
| \/ M anipulation | |
\*---------------------------------------------------------------------------*/

FoamFile
{
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
geometry
{
circle.stl
{
type triSurfaceMesh;
name circle;
}

box
{
type searchableBox;
min (-2 -2 0);
max ( 2 2 0.01);
}
};



// Settings for the castellatedMesh generation.
castellatedMeshControls
{

// 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.
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
{
circle
{
// 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.

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

box
{
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.
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
{
// Per final patch (so not geometry!) the layer information
layers
{
circle_circle
{
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.
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 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]

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

[nzy102]

Thank you for your help, Janssens.

Ning

[nzy102]

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

[mattijs]

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]

Janssens:

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

Ning

[mattijs]

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]

Janssens:

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.



Ning

[mattijs]

http://www.cfd-online.com/cgi-bin/Op...4667#POST24667

[bholbek]

Hi,

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

Thanks

Bastien

[lord_kossity]

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.

Regards,
Andreas

[albcem]

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.

Thanks.

Albcem

[MikeMac]

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.

Thanks!

Mike

[wyldckat]

Greetings Mike and welcome to the forum!

Originally Posted by MikeMac

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,
Bruno

[MikeMac]

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:

refinementSurfaces
{
box
{
level (2 2);
faceZone box;
cellZone box;
cellZoneInside inside;
regions
{
}
}

sphere
{
level (2 2);
faceZone sphere;
cellZone sphere;
cellZoneInside outside;
regions
{
}
}
}

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

refinementSurfaces
{
BoxAndSphere
{
level (2 2);
regions
{
".*box.*"
{
level (2 2);
faceZone box;
cellZone box;
cellZoneInside inside;
}
".*sphere.*"
{
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!

Mike

[wyldckat]

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,
Bruno

[zannatul]

Originally Posted by wyldckat

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,
Bruno

Hi Bruno
I am using snappy to run an axisymmetric case. I am having a few problems.
1. I have used 7 separate stl files in snappy but when they are joined, they give closed surface. So I selected location in mesh to be inside (for internal flow) and ran snappy. But after running snappy my background mesh is not deleted though I have deleted them in the boundary file and changed the patch number accordingly. What might be the reason for it? I do not know the exact way of choosing the location in mesh. So I chose a point from one of my .emesh file as I know this point is inside the stl file. Is this the wrong way of choosing location in mesh and is this the reason of not deleting background mesh?
2. Another problem is that as I have axisymmetric case. When I draw my geometry in solidworks and selected the faces to export as stl files for using boundary patches, I have selected my two wedge faces along with other faces and exported them. But after I ran snappy those wedge faces has become type wall in my boundary file under polymesh folder. But in my 0 folder where I give boundary conditions, my wedge faces are of type wedge. So there is conflict between wedge and wall type. So I could not run simpleFoam solver. What is actually the right way for it?

Please help me.

[Tobi]

Originally Posted by zannatul

Hi Bruno
I am using snappy to run an axisymmetric case. I am having a few problems.
1. I have used 7 separate stl files in snappy but when they are joined, they give closed surface. So I selected location in mesh to be inside (for internal flow) and ran snappy. But after running snappy my background mesh is not deleted though I have deleted them in the boundary file and changed the patch number accordingly. What might be the reason for it? I do not know the exact way of choosing the location in mesh. So I chose a point from one of my .emesh file as I know this point is inside the stl file. Is this the wrong way of choosing location in mesh and is this the reason of not deleting background mesh?
2. Another problem is that as I have axisymmetric case. When I draw my geometry in solidworks and selected the faces to export as stl files for using boundary patches, I have selected my two wedge faces along with other faces and exported them. But after I ran snappy those wedge faces has become type wall in my boundary file under polymesh folder. But in my 0 folder where I give boundary conditions, my wedge faces are of type wedge. So there is conflict between wedge and wall type. So I could not run simpleFoam solver. What is actually the right way for it?

Please help me.

Point 1. 7 STL's that have internal faces if you join them? If yes its clear why you only get a peace of the fluid domain. If you get the whole background mesh but with boundaries your STL is not waterproof and snappy find the holes in between (I swear that is your problem). The point inside the mesh have to be inside the mesh, not on a corner, a edge or sth else. Like the name tells you "inside the mesh".

Point 2. The conflict is, that snappyHexMesh does not change anything in your boundaries (0 folder). SnappyHexMesh will always create wall patches otherwise you have to tell snappy which boundary you want to apply. But you always can change the type wall to type wedge. Again I swear that you will not be able to get a 2d-axissymmetric mesh because the angle between wedge1 and wedge2 should be 5° and plane. After snapping you will never get a plane boundary. Therefore you have to do it in other ways that I will not discuss here (because it is not the question and does not belong to that problem here).

If you want to do sth. like that, check out my homepage and the axis-rotational-symmetric mesh case.