[jiaodanuma]

Dear openfoamers:

I'm trying to use snappyhexmesh in openfoam to mesh fluid around a cube, However, I can't control the boundary layers around the cube as I designed. To make sure y+ around the cube is about 1, the thickness of the first layer need to be 1.573E-5 m, and I want to add 55 layers with growth ration 1.1 as defined in snappyHexMeshDict. Unfortunately, the generated mesh around the cube is very different from what is expected as shown in attached pictures. I've read several threads about this problem but can't fix it yet. Can anyone give me some advice about this? I've uploaded related files through attachment. Thank you very much. BTW, can anyone explain the weird lines labelled by the red lines in the picture? Many many thanks!

Best regards
Yanan

[jiaodanuma]

snappyHexMeshDict:

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

    refinementBox1
    {
        type searchableBox;
        min (-0.05 -0.05 -0.05);
        max ( 0.35 0.2 0.2);
    }
    refinementBox2
    {
        type searchableBox;
        min (-0.2 -0.2 -0.2);
        max ( 0.95 0.35 0.35);
    }

    refinementBox3
    {
        type searchableBox;
        min (-0.5 -0.5 -0.5);
        max ( 2.15 0.65 0.65);
    }
    refinementBox4
    {
        type searchableBox;
        min (-0.8 -0.8 -0.8);
        max ( 3 0.95 0.95);
    }
};



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

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

    // 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 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 "cube.eMesh";
            level 1;
        }
    );



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

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

    // Resolve sharp angles
    resolveFeatureAngle 80;


    // 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.0006 6));
        }
        refinementBox1
        {
            mode inside;
            levels ((1E15 5));
        }
        refinementBox2
        {
            mode inside;
            levels ((1E15 4));
        }
        refinementBox3
        {
            mode inside;
            levels ((1E15 3));
        }
        refinementBox4
        {
            mode inside;
            levels ((1E15 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 0 1);


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

    //- Relative distance for points to be attracted by surface feature point
    //  or edge. True distance is this factor times local
    //  maximum edge length.
    tolerance 2.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;

    // Feature snapping

        //- Number of feature edge snapping iterations.
        //  Leave out altogether to disable.
        nFeatureSnapIter 15;

        //- Detect (geometric only) features by sampling the surface
        //  (default=false).
        implicitFeatureSnap false;

        //- Use castellatedMeshControls::features (default = true)
        explicitFeatureSnap true;

        //- Detect points on multiple surfaces (only for explicitFeatureSnap)
        multiRegionFeatureSnap false;
}



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

    // Per final patch (so not geometry!) the layer information
    layers; cube_cube is the patch name for cube
    {
        cube_cube

      {
        nSurfaceLayers 55;
      }    
    }

    // Expansion factor for layer mesh
    expansionRatio 1.1;

    // 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.
    firstLayerThickness 1.573E-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.
     minThickness 2.9E-2; 

    // 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.
    // Note: changed(corrected) w.r.t 17x! (didn't do anything in 17x)
    nGrow 0;

    // Advanced settings

    // When not to extrude surface. 0 is flat surface, 90 is when two faces
    // are perpendicular
    featureAngle 30;

    // At non-patched sides allow mesh to slip if extrusion direction makes
    // angle larger than slipFeatureAngle.
    slipFeatureAngle 30;

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

    // 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 17x! 90 degrees corresponds to 130 in 17x.
    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 quality of the tet formed by the face-centre
    //  and variable base point minimum decomposition triangles and
    //  the cell centre. This has to be a positive number for tracking
    //  to work. Set to very negative number (e.g. -1E30) to
    //  disable.
    //     <0 = inside out tet,
    //      0 = flat tet
    //      1 = regular tet
    minTetQuality 1e-30;

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

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


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

blockMeshDict

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2.2.1                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    object      blockMeshDict;
}

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

convertToMeters 1;

vertices
(
    (-1.5 -1.5 -1.5)
    (3 -1.5 -1.5)
    (3 1.5 -1.5)
    (-1.5 1.5 -1.5)
    (-1.5 -1.5 1.5)
    (3 -1.5 1.5)
    (3 1.5 1.5)
    (-1.5 1.5 1.5)

 );

blocks
(
    hex (0 1 2 3 4 5 6 7) (20 30 20) simpleGrading (1 1 1)
);

edges
(
);

boundary
(
    inlet
    {
        type patch;
        faces
        (
            (0 4 7 3)
        );
    }
    outlet
    {
        type patch;
        faces
        (
            (1 2 6 5)
        );
    }
    right
    {
        type symmetryPlane;
        faces
        (
            (0 1 5 4 )
        );
    }
    left
    {
        type symmetryPlane;
        faces
        (
            (3 7 6 2)
        );
    }
    top
    {
        type symmetryPlane;
        faces
        (
            (4 5 6 7)
        );
    }
    bottom
   {
        type symmetryPlane;
        faces
        (
            (0 3 2 1)
        );
    }

);

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

[me3840]

Those lines are just because you are viewing a cut of the mesh and in it's triangulated form. Turn on VTKpolyhedron or use crinkle slices to see the cells.

I really doubt you will get anywhere near 55 layers with snappy, the layer algorithm isn't that good. Do you really need 55 layers?

Your dictionary only has 5 layers set, not 55.

Also the surface you're telling it to make layers on is called cube_cube, but your cube is named cube.

[jiaodanuma]

Originally Posted by me3840

Those lines are just because you are viewing a cut of the mesh and in it's triangulated form. Turn on VTKpolyhedron or use crinkle slices to see the cells.

I really doubt you will get anywhere near 55 layers with snappy, the layer algorithm isn't that good. Do you really need 55 layers?

Your dictionary only has 5 layers set, not 55.

Also the surface you're telling it to make layers on is called cube_cube, but your cube is named cube.

Many thanks for your reply

I use DDES model for the simulation and the RANS employed is S-A model which is designed to solve viscous layer, therefore the y+ should be smaller than 1 and the y1 is very tiny. The side of the cube is 150 mm and the flow speed is 20 m/s, to ensure fine mesh quality in the physical boundary layer, I want to add 55 layers around the cube with a overall thickness about 20 mm.

You mentioned that the layer algorithm is not so good in openfoam. Since the version I used here is 2.2.1, how about the latest version? Do you think the problem could be improved changing to the latest version?

Yes, nSurfaceLayers set in the posted code is 5, I wanted to try small numbers to see the effect and forgot to change it back to 55. I'm sorry about that. About the cube_cube, the patch name for the cube generated in the boundary file is cube_cube, so cube_cube is used here. I'm sorry I didn't explain it clearly in the thread.

Can I ask you some more questions? I'm not sure about minThickness,

    // 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 2.9E-2;

There are different explanations about this parameter, one is the minimum thickness of cell layer as in
http://cfd.direct/openfoam/user-guide/snappyhexmesh/
another one is Minimum overall thickness of all layers as in
http://www.openfoam.com/documentatio...ppyHexMesh.php
I think the first explanation is correct, since all the code I've read including Motorbike and flange in the openfoam tutorial the value of minThickness is smaller than that of finalLayerThickness. I would like to check with you about the meaning of minThickness .

I tried to use relativeSizes employed by most examples, to generate 3 layers around the cube, and set minThickness smaller than finalLayerThickness. Three layers are generated around the cube as expected except for positions near the corners as illustrated in the attached picture. Can you explain the mesh around the corners? What's more, when I increase the number of layers, weird results appear.

addLayersControls
{
    // Are the thickness parameters below relative to the undistorted
    // size of the refined cell outside layer (true) or absolute sizes (false).
    relativeSizes true;

What do you think about it? Thank you very much. Since I'm alone to use snappyhexmesh in my work place, I desperately want to discuss with someone more experienced and it will be great if you can help me with it. Many many thanks!

Best
Yanan

[me3840]

You can have a y+ of 1 and still use far fewer layers, I would lower the height from 20mm as well. Prism layers aren't special cells by any means, they're just there to capture steep gradients. Considering your geometry is a cube having fine hex cells close to the surface serves precisely the same function as prisms without the quality issues. To get y+ of 1 at that Re should not be a challenge if you lower the number and height; getting refinement to capture the LE separation will be more difficult.

I believe your ideas behind the function of minThickness are correct.

Prism layer meshing is not really much better in newer versions.

However I think your biggest issue is that your cube is not a cube. If you zoom in to the edges of the cube, they're all rounded. That's why you get the corners all collapsing - you do not have the level of surface refinement on the cube to capture the curvature, so you just get the chamfer you see in your last image.

[LVDH]

Originally Posted by me3840

However I think your biggest issue is that your cube is not a cube. If you zoom in to the edges of the cube, they're all rounded. That's why you get the corners all collapsing - you do not have the level of surface refinement on the cube to capture the curvature, so you just get the chamfer you see in your last image.

Well that might be a meshing issue. The simplest fix could be to set implicit feature snapping or what is called to true.
Also I have seen that the plus version of OF is a bit better with surface layer meshing. And then if I am not mistaken the featureAngle can be massively increased in the layer part of the snappyHexMeshDict.

[LVDH]

Lately I have been wondering that the point of surface layers in shm is. I mean is it not simpler to just use small cells? I way shm works would the mesh be that much larger?
It would speed meshing up quite a lot and create cleaner meshes.

[me3840]

Originally Posted by LVDH

Well that might be a meshing issue. The simplest fix could be to set implicit feature snapping or what is called to true.
Also I have seen that the plus version of OF is a bit better with surface layer meshing. And then if I am not mistaken the featureAngle can be massively increased in the layer part of the snappyHexMeshDict.

It's not a meshing issue. If you open the geometry there's rounded corners. No amount of snapping to feature edges will help, because there are no feature edges for a completely edge-free cube.

[me3840]

Originally Posted by LVDH

Lately I have been wondering that the point of surface layers in shm is. I mean is it not simpler to just use small cells? I way shm works would the mesh be that much larger?
It would speed meshing up quite a lot and create cleaner meshes.

Layers are very useful at resolving near-wall flows because these flows travel tangentially to the wall - without the layers, we don't get any faces that are normal to the wall. In addition, the gradients in velocity as we approach the wall are very steep, and adding enough traditional hex cells to resolve this gradient would be really expensive. Layers however, due to their anisotropy, can resolve this in a much more efficient manner.

[LVDH]

I am aware of why you usually want them. But considering that in OF it is difficult to have a large growth rate of the layers why not just use small cells? They should be more or less as orthogonal to the geometry surface as the layers. And because in shm the cells are split all the time I think you should have more or less the same overall cell count.

Anyways in CFD everything is always about compromise. Just ditching the layers in shm should speed up user time, meshing time and solver time as you will probably have a better cell quality. For that you can buy more cells which can add accuracy.

It was just a suggestion. I will try it soon.

[jiaodanuma]

Originally Posted by LVDH

Well that might be a meshing issue. The simplest fix could be to set implicit feature snapping or what is called to true.
Also I have seen that the plus version of OF is a bit better with surface layer meshing. And then if I am not mistaken the featureAngle can be massively increased in the layer part of the snappyHexMeshDict.

Thank you very much and sorry for the late reply. I've tried to set implicit feature snapping to be true and the results are shown in the attached picture. Mesh around corners looks better but the layers around the cube are not uniform especially for the parts labeled as red. Can you explain about this and can you give me some advice about how to control the quality of these layers? Thank you very much! BTW, it would be great if you can give me more information about implicit feature snapping, I didn't find more reference about this utility. Many thanks

[LVDH]

The image is missing.

[me3840]

Originally Posted by jiaodanuma

Thank you very much and sorry for the late reply. I've tried to set implicit feature snapping to be true and the results are shown in the attached picture. Mesh around corners looks better but the layers around the cube are not uniform especially for the parts labeled as red. Can you explain about this and can you give me some advice about how to control the quality of these layers? Thank you very much! BTW, it would be great if you can give me more information about implicit feature snapping, I didn't find more reference about this utility. Many thanks

Are you sure turning on the implicit feature snapping is the only thing that changed? Unless your feature angle is really small, I don't see how this would help, there aren't any hard edges to mark in the model.

[jiaodanuma]

Originally Posted by me3840

You can have a y+ of 1 and still use far fewer layers, I would lower the height from 20mm as well. Prism layers aren't special cells by any means, they're just there to capture steep gradients. Considering your geometry is a cube having fine hex cells close to the surface serves precisely the same function as prisms without the quality issues. To get y+ of 1 at that Re should not be a challenge if you lower the number and height; getting refinement to capture the LE separation will be more difficult.

I believe your ideas behind the function of minThickness are correct.

Prism layer meshing is not really much better in newer versions.

However I think your biggest issue is that your cube is not a cube. If you zoom in to the edges of the cube, they're all rounded. That's why you get the corners all collapsing - you do not have the level of surface refinement on the cube to capture the curvature, so you just get the chamfer you see in your last image.

Many many thanks for your suggestion, which are really helpful and sorry for the late reply.

You are right, the corners of the cube are rounded to avoid unexpected high pressure distribution around the sharp corners.

Do you have any suggestion about how to capture the LE separation which is very important for my case. Thank you very much.

Originally Posted by me3840

Are you sure turning on the implicit feature snapping is the only thing that changed? Unless your feature angle is really small, I don't see how this would help, there aren't any hard edges to mark in the model.

Actually, I've tried several ways to generate the SHM. If I just refine edges and try to add 50 layers,

     features
    (
        {
            file "cube.eMesh";
            level 6;
        }
    );

mesh looks like picture named "refined edge" . In this picture the mesh is not uniform around the cube. If I turn on turning on the implicit feature snapping at the same time, the mesh around didn't change much.

If I just turning on the implicit feature snapping, adding 50 layers, mesh are shown in picture "implicit", in which mesh along two sides are refined but the overall mesh around the cube is still strange.

If I refined the edge and turn on implicit feature snapping at the same time to add 10 layers, it seems work properly, just as shown in picture "10 layer refined edge and implicit".

So can I say that SHM in OF are not suitable for adding large number prism layers now?

Do you have any experience for trimmed mesh generated by Star-CCM? Do you think Star is better to generate SHM compared with OF? Many thanks.

Best Yanan

[jiaodanuma]

Originally Posted by LVDH

The image is missing.

Sorry about this, the picture are as attached and I modified the featureAngle from 30 to 90

    // When not to extrude surface. 0 is flat surface, 90 is when two faces
    // are perpendicular
    featureAngle 90;

[me3840]

Yeah, you can see your mesh is still poor in the corners because you aren't refining that curvature enough.

I don't think you really need that many prisms here. The flow will be changing a lot tangentially to the cube, so I would say the 10 layer mesh is even fine, but the mesh away from the cube and at the corners is too poor/coarse.

I do have experience with STAR-CCM+, and it can make larger layers much more robustly, but I really don't think that will solve your problem any better. STAR-CCM+ meshes are difficult to run in other codes because that solver is much more robust for poor cells, so the meshes are generally not as high quality.

[LVDH]

Hi,

just a few comments.
I checked your blockMesh. The cells are not uniform. For shm it is much better to have cube cells.
And then 55 surface layers with a growth rate of 1.1 leads to very very large cells. You should check that.
Also I have checked your shmDict. There are a few odd things in there. I will try to fix at least some.
But shm is usually not good to generate more than about 8 surface layers.

The comment about start meshes is somewhat true. However the trimmed mesh in star should have a cell quality more than good enough for OF. Converting it for OF could potentially create more trouble. But as this case is so simple we should be able to get a good mesh out of shm.

[LVDH]

Originally Posted by LVDH

And then 55 surface layers with a growth rate of 1.1 leads to very very large cells. You should check that.

After checking once more it is not that crazy after all as the first cell is so small. My mistake.

[jiaodanuma]

Originally Posted by me3840

Yeah, you can see your mesh is still poor in the corners because you aren't refining that curvature enough.

I don't think you really need that many prisms here. The flow will be changing a lot tangentially to the cube, so I would say the 10 layer mesh is even fine, but the mesh away from the cube and at the corners is too poor/coarse.

I do have experience with STAR-CCM+, and it can make larger layers much more robustly, but I really don't think that will solve your problem any better. STAR-CCM+ meshes are difficult to run in other codes because that solver is much more robust for poor cells, so the meshes are generally not as high quality.

Thanks a lot! It's really helpful!

[jiaodanuma]

Originally Posted by LVDH

Hi,

just a few comments.
I checked your blockMesh. The cells are not uniform. For shm it is much better to have cube cells.
And then 55 surface layers with a growth rate of 1.1 leads to very very large cells. You should check that.
Also I have checked your shmDict. There are a few odd things in there. I will try to fix at least some.
But shm is usually not good to generate more than about 8 surface layers.

The comment about start meshes is somewhat true. However the trimmed mesh in star should have a cell quality more than good enough for OF. Converting it for OF could potentially create more trouble. But as this case is so simple we should be able to get a good mesh out of shm.

Many many thanks. I appreciate it very much!