CFD Online Discussion Forums - [mesh manipulation] Splitting the mesh for AMI

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- OpenFOAM Meshing & Mesh Conversion (https://www.cfd-online.com/Forums/openfoam-meshing/)

- - [mesh manipulation] Splitting the mesh for AMI (https://www.cfd-online.com/Forums/openfoam-meshing/163257-splitting-mesh-ami.html)

Splitting the mesh for AMI

Hey Everybody!

I am working for a while now with OpenFoam and like the solver a lot. There is however a problem which keeps repeating it self, and I can't figure out what I am doing wrong. I try to simulate a rotating wing using the AMI interface (I deliberately did not choose for SRF or MRF for now). I make my mesh as shown in the propellor case using this as my snappyHexMeshDict:

Code:

/*--------------------------------*- C++ -*----------------------------------*\

| =========                 |                                                 |

| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |

|  \\    /   O peration     | Version:  3.0.0                                 |

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

{

    sphere.stl

    {

        type        triSurfaceMesh;

        name        sphere;

    }

    wing.stl

    {

        type        triSurfaceMesh;

        name        wing;

    }

};







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



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



    // 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        "sphere.eMesh";

            level       4;

        }



        {

            file        "wing.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

    {

        sphere

        {

            level       (4 4);



            faceType    boundary;

            cellZone    cylinder;

            faceZone    cylinder;

            cellZoneInside  inside;

        }

        

        wing

        {

            level       (6 7);

        }

    }



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

    {

        //sphere

        //{

        //    mode        inside;

        //    levels      ((1E15 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 (0.0001 -0.005 0.0001);





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

}







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



    //- Number of mesh displacement relaxation iterations.

    nSolveIter 300;



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



        // Detect (geometric only) features by sampling the surface

        // (default=false).

        implicitFeatureSnap false;



        // Use castellatedMeshControls::features (default = true)

        explicitFeatureSnap true;



        // Detect features between multiple surfaces

        // (only for explicitFeatureSnap, default = false)

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



    // Per final patch (so not geometry!) the layer information

    layers

    {

    }



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

    // See relativeSizes parameter.

    finalLayerThickness 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.

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



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



    //- 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 -1; // 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.01;



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



    // Optional : some meshing phases allow usage of relaxed rules.

    // See e.g. addLayersControls::nRelaxedIter.

    relaxed

    {

        //- Maximum non-orthogonality allowed. Set to 180 to disable.

        maxNonOrtho 75;

    }

}







// Merge tolerance. Is fraction of overall bounding box of initial mesh.

// Note: the write tolerance needs to be higher than this.

mergeTolerance 1e-6;





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

Then I use createPatch to generate the separate AMI interfaces:

Code:

/*--------------------------------*- C++ -*----------------------------------*\

| =========                 |                                                 |

| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |

|  \\    /   O peration     | Version:  3.0.0                                 |

|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |

|    \\/     M anipulation  |                                                 |

\*---------------------------------------------------------------------------*/

FoamFile

{

    version     2.0;

    format      ascii;

    class       dictionary;

    object      createPatchDict;

}

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



// Do a synchronisation of coupled points after creation of any patches.

// Note: this does not work with points that are on multiple coupled patches

//       with transformations (i.e. cyclics).

pointSync false;



// Patches to create.

patches

(

    {

        //- Master side patch

        name            AMI1;

        patchInfo

        {

            type            cyclicAMI;

            matchTolerance  0.0001;

            neighbourPatch  AMI2;

            transform       noOrdering;

        }

        constructFrom patches;

        patches (sphere);

    }



    {

        //- Slave side patch

        name            AMI2;

        patchInfo

        {

            type            cyclicAMI;

            matchTolerance  0.0001;

            neighbourPatch  AMI1;

            transform       noOrdering;

        }

        constructFrom patches;

        patches (sphere_slave);

    }

);



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

The problem is now that when I rotate my mesh the inner AMI (AMI2) has points in the outer AMI creating stretched cells (as shown in the attached image).

Does anybody know where I went wrong? I am using OpenFoam 3.0x by the way.

Thank you in advance!

Greetings Wouter,

I've got the feeling that this is a bug in OpenFOAM or that something went wrong in the mesh generation step.
Can you please share the case you have, but without the wing inside it, so that I or anyone else can test it more easily?

Best regards,
Bruno

Hey wyldckat

I have solved the problem by meshing the inner and the outer part separate and using mergmesh to merge both meshes. So I think the problem lies complete in the meshing part. I have added my case files to this post. I hope it helps! I have used a cylinder in this case since the sphere is to big for the upload!

Wouter

Hi Wouter,

Many thanks for the test case! Can you please tell me which commit you're using from 3.0.x? To see which one it is, run the following commands:

Code:

foam

git log -1

I need to know if it's a recent commit or if you got a bad commit that happened a few days ago (which was partially my fault, as I was the one who committed the patch and had hoped it would work as intended).

Best regards,
Bruno

Hey Bruno,

I have not installed it using git, so I don't get a response from git. I have followed the instructions listed here : http://www.openfoam.org/download/ubuntu.php

I have installed it at least 3 weeks ago. So no recent update.

Wouter

PS Thank you for implementing this in the code! It is really an awsome feature.

Hi Wouter,

Quote:

Originally Posted by wgvanveen (Post 575467)

I have not installed it using git, so I don't get a response from git. I have followed the instructions listed here : http://www.openfoam.org/download/ubuntu.php

I have installed it at least 3 weeks ago. So no recent update.

Then you have installed OpenFOAM 3.0.0 and not 3.0.x. OK, now I'm confused, because I tested the case you provided with OpenFOAM 3.0.0 and I didn't get the problem with the points on the AMI patches being dragged around.

Quote:

Originally Posted by wgvanveen (Post 575467)

PS Thank you for implementing this in the code! It is really an awsome feature.

:confused: Mmm... I'm not sure we are referring to the same issue. I was referring to this bug report and respective fix: http://www.openfoam.org/mantisbt/view.php?id=1479
The bad commit is related to this comment and respective patch: http://www.openfoam.org/mantisbt/view.php?id=1479#c5493 - namely the patch was integrated in this commit: https://github.com/OpenFOAM/OpenFOAM...33942e88f3a855
It was reverted a few days later and recently I managed to figure out the proper fix (or at least I hope so), which is already in the latest 3.0.x.

If you only get the problem with the sphere, please provide the case without the wing and sphere geometries and let me know the centre and radius of the sphere, so that I will create a new one with ParaView.

Best regards,
Bruno

Hey Bruno,

I am indeed using 3.0.0. If I use the command:

Code:

moveDynamicMesh -checkAMI

On the case I have provided I get the following result:

Code:

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

Create time



Create mesh for time = 0



Selecting dynamicFvMesh solidBodyMotionFvMesh

Selecting solid-body motion function rotatingMotion

Applying solid body motion to cellZone cylinder

Writing VTK files with weights of AMI patches.



Time = 0.001

solidBodyMotionFunctions::rotatingMotion::transformation(): Time = 0.001 transformation: ((0 0 0) (0.955336 (0 0.29552 0)))

--> FOAM Warning : 

    From function solidBodyMotionFvMesh::update()

    in file solidBodyMotionFvMesh/solidBodyMotionFvMesh.C at line 237

    Did not find volVectorField U Not updating Uboundary conditions.

solidBodyMotionFunctions::rotatingMotion::transformation(): Time = 0.001 transformation: ((0 0 0) (0.955336 (0 0.29552 0)))

    Point usage OK.

    Upper triangular ordering OK.

    Topological cell zip-up check OK.

    Face vertices OK.

    Face-face connectivity OK.

    Mesh topology OK.

    Boundary openness (-1.71547e-16 5.89183e-17 3.35615e-17) OK.

 ***High aspect ratio cells found, Max aspect ratio: 1.11519e+93, number of cells 1

    Minimum face area = 2.14152e-09. Maximum face area = 8.42446e-07.  Face area magnitudes OK.

 ***Zero or negative cell volume detected.  Minimum negative volume: -4.27564e-12, Number of negative volume cells: 1

    Mesh non-orthogonality Max: 129.19 average: 9.75379

   *Number of severely non-orthogonal (> 70 degrees) faces: 2.

 ***Number of non-orthogonality errors: 3.

 ***Error in face pyramids: 6 faces are incorrectly oriented.

 ***Max skewness = 4.22197, 1 highly skew faces detected which may impair the quality of the results

    Failed 5 mesh geometry checks.

    Failed 1 mesh checks.

Calculating AMI weights between owner patch: AMI1 and neighbour patch: AMI2

AMI: Creating addressing and weights between 19272 source faces and 19273 target faces

AMI: Patch source sum(weights) min/max/average = 0.653138, 1.27705, 0.998826

AMI: Patch target sum(weights) min/max/average = 0, 1.48334, 1.00933

ExecutionTime = 6.51 s  ClockTime = 6 s

With the cylinder it is less clear than with the sphere, but there is still clearly one cell dragged along the surface (see picture attached).

Wouter

Hi Wouter,

OK, now I'm really worried. I got this instead:

Code:

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

Create time



Create mesh for time = 0



Selecting dynamicFvMesh solidBodyMotionFvMesh

Selecting solid-body motion function rotatingMotion

Applying solid body motion to cellZone cylinder

Writing VTK files with weights of AMI patches.



Time = 0.001

solidBodyMotionFunctions::rotatingMotion::transformation(): Time = 0.001 transformation: ((0 0 0) (0.955336 (0 0.29552 0)))

--> FOAM Warning : 

    From function solidBodyMotionFvMesh::update()

    in file solidBodyMotionFvMesh/solidBodyMotionFvMesh.C at line 237

    Did not find volVectorField U Not updating Uboundary conditions.

solidBodyMotionFunctions::rotatingMotion::transformation(): Time = 0.001 transformation: ((0 0 0) (0.955336 (0 0.29552 0)))

    Point usage OK.

    Upper triangular ordering OK.

    Topological cell zip-up check OK.

    Face vertices OK.

    Face-face connectivity OK.

    Mesh topology OK.

    Boundary openness (-6.61809e-16 -4.23473e-17 6.62949e-16) OK.

    Max cell openness = 3.05605e-16 OK.

    Max aspect ratio = 7.56945 OK.

    Minimum face area = 2.14152e-09. Maximum face area = 8.42241e-07.  Face area magnitudes OK.

    Min volume = 1.48721e-13. Max volume = 7.01262e-10.  Total volume = 1.59999e-05.  Cell volumes OK.

    Mesh non-orthogonality Max: 58.5724 average: 9.75085

    Non-orthogonality check OK.

    Face pyramids OK.

    Max skewness = 2.74585 OK.

    Mesh geometry OK.

Mesh OK.

Calculating AMI weights between owner patch: AMI1 and neighbour patch: AMI2

AMI: Creating addressing and weights between 19272 source faces and 19272 target faces

AMI: Patch source sum(weights) min/max/average = 0.735122, 1.07488, 0.998849

AMI: Patch target sum(weights) min/max/average = 0.999911, 1.48334, 1.00955

ExecutionTime = 5.5 s  ClockTime = 5 s

In other words, mine is OK.

I ran the case with the following commands:

Code:

blockMesh

foamJob snappyHexMesh -overwrite

createPatch -overwrite

moveDynamicMesh -checkAMI

And I changed in "system/controlDict" to use:

Code:

stopAt nextWrite;

Which exact version/package of OpenFOAM 3.0.0 did you install and in which Linux Distribution?
Because my suspicion is regarding a possible problem with a specific build... which once in a while happens due to a compiler flaw/bug.

Best regards,
Bruno

Hey Bruno,

Where do I find the exact build number? I am running it on Ubuntu 15.10. I have tested it on two different computers both running Ubuntu 15.10, both giving the exact same problems. I am running the same commands as your are running, except I am running:

Code:

decomposePar 

mpirun -np 2 snappyHexMesh -parallel

reconstructParMesh 

createPatch -overwrite

moveDynamicMesh -checkAMI

Before I run the createrPatch I manually copy the data from 0.002/ to constant

Thank you for all your help!

Wouter

Hi Wouter,

Quote:

Originally Posted by wgvanveen (Post 575583)

Where do I find the exact build number? I am running it on Ubuntu 15.10. I have tested it on two different computers both running Ubuntu 15.10, both giving the exact same problems.

I'm guessing you are installing the Deb package as instructed here: http://www.openfoam.org/download/ubuntu.php ??
The exact version is given by any application that is executed from OpenFOAM. For example:

Code:

blockMesh -help

will tell you something like the following near the end:

Code:

Using: OpenFOAM-3.0.0 (see www.OpenFOAM.org)

Build: 3.0.0-6abec57f5449

Quote:

Originally Posted by wgvanveen (Post 575583)

I am running the same commands as your are running, except I am running:

Code:

decomposePar 

mpirun -np 2 snappyHexMesh -parallel

reconstructParMesh 

createPatch -overwrite

moveDynamicMesh -checkAMI

Before I run the createrPatch I manually copy the data from 0.002/ to constant

:eek: OK... that certainly can add enough entropy to make things break... I gotta try the same steps...
Oh, definitely... Wow! OK, I managed to reproduce the error with the steps you've pointed out!

Now, let me see if OpenFOAM-3.0.x does it better... nope. Same problem.

OK, I've ran with the latest OpenFOAM-history - https://github.com/OpenCFD/OpenFOAM-history - and it didn't give me any problems for the same situations that would break when using 3.0.0 and 3.0.x.

So my question to you now is this: Can we use this test case for reporting this issue on the bug tracker? Because this means that the missing code has to be ported from OpenFOAM-history to OpenFOAM-dev/3.0.x and I/we can use this case for testing if things work as intended.

Best regards,
Bruno

Hey Bruno,

I am sort of happy that you've gotten the same error. Are the steps wrong that I took? My build number is:

Code:

Using: OpenFOAM-3.0.0 (see www.OpenFOAM.org)

Build: 3.0.0-8b097f6d8dd9

Yes this case can be used to report a bug! How should I report it?

Wouter

Hi Wouter,

Quote:

Originally Posted by wgvanveen (Post 575742)

Are the steps wrong that I took?

Well, they are not wrong, it's a flaw in snappyHexMesh.

The workaround until the bug is fixed is for you to mesh in serial mode instead of parallel mode. In other words, to use the same commands I did.

Quote:

Originally Posted by wgvanveen (Post 575742)

My build number is:

Code:

Using: OpenFOAM-3.0.0 (see www.OpenFOAM.org)

Build: 3.0.0-8b097f6d8dd9

OK, you installed the Deb package.

Quote:

Originally Posted by wgvanveen (Post 575742)

Yes this case can be used to report a bug! How should I report it?

The bug tracker for OpenFOAM is accessible through here: http://www.openfoam.org/bugs/
Please provide as much information as possible (related to reproducing the bug), along with the test case. Add a link to this thread only as a fallback, in case you feel like you might have missed some details.
I'll come by the bug tracker as soon as I can, in case you miss any details and to add more details as I find more about this issue.

Best regards,
Bruno

hey Bruno,

I will add this bug to the bug tracker. The problem is also found when meshing in serial (not in this case, but in other cases it was irrelevant if I used serial or parallel compuation).

Thank you for your help!

Wouter

Hi Wouter,

Many thanks for reporting this! I see you reported it here: http://www.openfoam.org/mantisbt/view.php?id=1936

I'll try to take a look into this starting today and in the next couple of days. Nonetheless, in the meantime, can you please also provide the test case that fails when running in serial mode?

Best regards,
Bruno

Hey Bruno,

This week is very busy at work, I hope to give you a case which fails this weekend! I will share it through dropbox, since the forum upload is to small.

Wouter

Hi Wouter,

Quote:

Originally Posted by wgvanveen (Post 577048)

This week is very busy at work, I hope to give you a case which fails this weekend! I will share it through dropbox, since the forum upload is to small.

No problem. I haven't been able yet to look into this yet either.
The forum has a limit of 200kB. If the package is 2MB or less, I believe the bug tracker can handle it.

Best regards,
Bruno

Thank you both, nice discussion. It helped me to settle the case.

no parallel for SnappyHexMesh

Meshing with snappy one one processor solved my problem of AMI weight going to zero.

This bug has to be reported