2 2

Next: Wheel mesh Up: Mesh Generation using snappyHexMesh Previous: Background mesh   Contents   Index

Inflow mesh

The next step of the mesh generation is similar for all three regions, only the settings will be different. After the background mesh is finished, we will need to cut it by the surface geometry. This is done by the mesher snappyHexMesh.

The settings for snappyHexMesh are in the text file system/snappyHexMeshDict and it is divided into several sections: geometry, castellatedMeshControls, snapControls, addLayersControls and meshQualityControls. The following listing presents the leading two sections that specify the boundary geometries and snap settings:

castellatedMesh true;
snap            true;
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
{
    inflow.obj
    {
        type triSurfaceMesh;
        name inflow_wall;
    }
    housing.obj
    {
        type triSurfaceMesh;
        name housing_wall;
    }
    wheel_inlet.obj
    {
        type triSurfaceMesh;
        name wheel_inlet_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 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 5000000;

    // 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 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 ( ); // 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
    {
        ".*"
        {
            level (3 3);
            patchInfo
            {
                type wall;
            }
        }
    }

    resolveFeatureAngle 10;


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

    // 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.
    // This is an outside point locationInMesh (-0.033 -0.033 0.0033);
    locationInMesh (0 0 -1.001); // Inside point

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

We are using three of the OBJ files (lines 34-48) and set the cell refinement to level 3 equally for all of them (lines 107-114; the wildcard symbol “.*” stands for arbitrary name of a patch). A point inside the mesh is given on the line 146. All other entries are standard.

It is now possible to run snappyHexMesh either in serial or parallel mode. For serial run we simply use

# snappyHexMesh
in the root directory of the case. It will create a time directory “1” with castellated mesh and a time directory “2” with the snapped mesh. The parallel run first requires decomposition of the background mesh so that the processes can work on independent sections of the mesh.

# decomposePar
# mpirun -np 2 snappyHexMesh -parallel
# reconstructParMesh -latestTime
The program decomposePar requires presence of the settings in the file system/decomposeParDict. In this case it can contain just two lines (apart from comments):

numberOfSubdomains 2;

method          scotch;

The first line specifies the number of independent sections of mesh to create. It has to be consistent with the parameter that is passed to mpirun. The final mesh will have the shape of the light brown part of figure crossref 2.