CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Meshing & Mesh Conversion (https://www.cfd-online.com/Forums/openfoam-meshing/)
-   -   [snappyHexMesh] Creating mesh for cyclicAMI boundaries (https://www.cfd-online.com/Forums/openfoam-meshing/236158-creating-mesh-cyclicami-boundaries.html)

otaolafr May 16, 2021 14:17
Creating mesh for cyclicAMI boundaries
 
1 Attachment(s)
Hello,
I am trying to simulate the flow inside a periodic structure, therefore I am trying to use the cyclicAMI as boundary condition for the Inlet and Outlet patch.
my workflow is the following:
blockMesh (without defining any patch)
surfaceFeatureExtract
snappyHexMesh -overwrite (recovering the patchs from the stl: Inlet, Outlet,sym_1, sym_2, Walls)
createPatch-overwrite (using createPatch to create InletAMI and OutletAMI from the Inlet and Outlet patches created in snappyHex)

the Inlet and Outlet patches looks at least really similar in paraview (see figures at the end of the thread), they are separate in a distance of (9,0,0) but I am having a lot of troubles with the cyclicAMI implementation, when I run the checkMesh -allTopology -allGeometry sometimes i get the following 2 different errors (when I play a little bit with snappy and createPatch settings):
Code:
Calculating AMI weights between owner patch: InletAMI and neighbour patch: OutletAMI
AMI: Creating addressing and weights between 31721 source faces and 31730 target faces
[0]
[0]
[0] --> FOAM FATAL ERROR: (openfoam-2012)
[0] Unable to set target face for source face 31714
[0]
[0]    From virtual bool Foam::faceAreaWeightAMI::setNextFaces(Foam::label&, Foam::label&, Foam::label&, const Foam::bitSet&, Foam::labelList&, const Foam::DynamicList<int>&, bool) const
[0]    in file AMIInterpolation/AMIInterpolation/faceAreaWeightAMI/faceAreaWeightAMI.C at line 347.
[0]
FOAM parallel run aborting
and other times I get a target box span : (-2e+150 -2e+150 -2e+150) and the weghts equal to zero.

the geometry at least visually is correctly described and I have used snapping to features (and the features are correctly detected)
I tried to play with the number of iterations of snapping right now I am at 25.
I have searched in the forum without a lot of luck in these subject, any help would be appreciated.
the two patches
https://i.ibb.co/QkyHXGh/fig1.png
the patches one over the other one
https://i.ibb.co/pwHvVSB/fig2.png
and one of the patch with the captured features.
https://i.ibb.co/30MP8Vr/fig3.png
I also add the snappy dict and createPatch dict (I know that there is a problem with the sym_1 and sym_2 patches in the createPatchDict but at these moment it is not the issue.)
I am using OF v2012

Code:
/*--------------------------------*- C++ -*----------------------------------*\
| =========                |                                                |
| \\      /  F ield        | OpenFOAM: The Open Source CFD Toolbox          |
|  \\    /  O peration    | Version:  v2012                                |
|  \\  /    A nd          | Website:  www.openfoam.com                      |
|    \\/    M anipulation  |                                                |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version    2.0;
    format      ascii;
    class      dictionary;
    object      createPatchDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

pointSync false;

patches
(
    {
        //- Inlet
        name            InletAMI;
        patchInfo
        {
            type            cyclicAMI;
            matchTolerance  1;
            neighbourPatch  OutletAMI;
            transform      translational;
            separationVector (-9 0 0);
        }
        constructFrom patches;
        patches (Inlet);
    }

    {
        //- Outlet
        name            OutletAMI;
        patchInfo
        {
            type            cyclicAMI;
            matchTolerance  1;
            neighbourPatch  InletAMI;
            transform      translational;
            separationVector (9 0 0);
        }
        constructFrom patches;
        patches (Outlet);
    }
        {
        name            sym_1;
        patchInfo
        {
            type            symmetry;
        }
        constructFrom patches;
        patches (sym_1);
    }
        {
        name            sym_2;
        patchInfo
        {
            type            symmetry;
        }
        constructFrom patches;
        patches (sym_2);
    }
);

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

otaolafr May 18, 2021 05:11
I am answering my own post for anyone that find in the same situation.
I found at least a partial solution for my issue and made it work.
the problem was coming from the feature snapping. I was using a quarter of the geometry (that had two symmetry planes) as the input mesh for the snappy. and when I was doing this the features were perfectly detected, but that brought some problems.I tryied another workflow where I introduce a bigger surface mesh than my simulation volume (instead of the quarter a 360°) and "cut it" with my background mesh therefore the features detected were less (as the ones in the cut will not be detected by surfaceFeatureExtract). this solved my issue. it is not a perfect solution but at least it works.... here is a image showing the difference in the features detected (in right the previews features in left the new ones) and in red the simulation volume (that is, the surface mesh intersected with the background mesh).
https://i.ibb.co/Js5wkGW/dif-Features.png

mactone October 10, 2022 22:13
Do you mean by using bigger (full) geometry file and cut by smaller blockMesh?
Will this solve the cyclic boundary issue?


Quote:
Originally Posted by otaolafr (Post 804080)
I am answering my own post for anyone that find in the same situation.
I found at least a partial solution for my issue and made it work.
the problem was coming from the feature snapping. I was using a quarter of the geometry (that had two symmetry planes) as the input mesh for the snappy. and when I was doing this the features were perfectly detected, but that brought some problems.I tryied another workflow where I introduce a bigger surface mesh than my simulation volume (instead of the quarter a 360°) and "cut it" with my background mesh therefore the features detected were less (as the ones in the cut will not be detected by surfaceFeatureExtract). this solved my issue. it is not a perfect solution but at least it works.... here is a image showing the difference in the features detected (in right the previews features in left the new ones) and in red the simulation volume (that is, the surface mesh intersected with the background mesh).
https://i.ibb.co/Js5wkGW/dif-Features.png

otaolafr October 11, 2022 00:07
Quote:
Originally Posted by mactone (Post 837238)
Do you mean by using bigger (full) geometry file and cut by smaller blockMesh?
Will this solve the cyclic boundary issue?
It will not solve it, but help, this will increase the quality of your mesh by a lot. Keep in mind that you will not be able to use explicit features by doing this (or as I do myself you can prepare another stl only for the feature edges. Nevertheless, to make it work always you can add a keyword in the creation of the cyclicami patches lowWeightCorrection if I remember by memory. This will allow you to "ignore" the zero weight cells. Which only one cell will not affect your results but nevertheless if you have one zero weight ratio cell the simulation will not run. Also use cyclciAMI no cyclic as boundary condition, cyclic requires exactly the same cells in the two boundaries that this is almost impossible to do in SnappyHexMesh while cyclciAMI accepts slightly differences between de source and the target.
Regards


All times are GMT -4. The time now is 15:49.