[Tellur]

Hi Louis,

Thank you for the response.

Yes I did try changing the rotation of the fan and the wind direction seemed to change.

The problem was though that as the solution was converging, the downward flow was getting lost and the turbulent flow developed has an upward flow pattern. The only thing I believe I can blame atm is boundary conditions and/or model.

Most of the cases are small square rooms with a fan in the middle, an open window (fixedValue velocity, always quite low, <0.2m/s), and an open door (as a typical outlet). I was wondering if the problem is this set up or the window being close to the fan. For this reason I tried an 'external case' where I have a blockmesh blowing wind towards the room, which now has no boundary surfaces for window or door, is modeled as an open room. Same pattern again unfortunately, with the initially downward flow getting lost as the solution converges. Additionally, wind speeds below the fan are much lower than expected.

Is rotation and direction really tied to the type of geometry of the fan or is it a convention of OF? I haven't been able to clarify that yet. I imagine it's the first if we want validity.

Is it perhaps the size of my MRF zone? It is atm quite small, located around the fan. I show in some studies MRF zones extending to almost 2m length.

Finally, I was also looking about this but nothing clear on the site. Is it possible to model an open window in openfoam, with no 'outlet' boundary? I went through the posts about outflow, but they are all seemed to start with it as a problem to fix. Also, most of them are focused on outlets that appear to have inflow. My case is the opposite, I want to enable outflow on an inlet. Is that possible?

Sorry if I diverged from the subject a bit, hope this helps to understand my case.

Edit: Added pressure and velocity vector plots on a cross section parallel to the wind flow, under the fan. Also forgot to mention this is CCW direction (- rad/s in MRF properties).

Edit2: Added two velocity plots. They are from both cases (CW and CCW rotation) at a very early stage (only 100 iterations). Still, you can clearly see I think that CW is producing the required pattern, which relates well to the shape of the fan geometry. Problem is that pattern is lost as solution converges. I am at a loss. After making the whole MRF work, this seems like a silly issue to have. Still, it invalidates all my previous work

Kind regards,
Theodore.

[louisgag]

Hi Theodore,

My experience is limited to GGI/AMI interfaces, so I can't comment on the MRF.

As for the outlet that allows incoming flow, I think you can use the inletOutlet boundary condition for the inlet as well. See section "5.2.3.1 The inlet/outlet condition" of http://cfd.direct/openfoam/user-guide/boundaries/

Finally, for the imposed rotation direction convention, I doubt there is one as OpenFOAM solves the flow using finite volumes and I don't see where this would come in.

That said, my knowledge on the subject is limited and hopefully someone else may add useful comments.

Regards,

-Louis

[Tellur]

Hello Louis,

Thank you very much for your input.

I have started testing the inletOutlet condition with fairly similar results. The latest simulations have been with only an open window, that is only an inletOutlet and without any kind of outlet boundary condition. The simulation works which means the inletOutlet implementation is (physically) correct, so thank you for that.

Unfortunately, I still get the same weird patterns. To be fair, I'm on a desperate clock here and most of my tests are around 500 to 750 iterations which I can understand is FAR from being converged. Still there should be a semblance of a downward pattern even at this early stage should it not?

I am attaching screenshots from both CCW and CW orientations. The fan design should allow for downward flow for the CW orientation but both of them look kind of horrid tbh. CW is even more of an 'upward' flow than the CCW.

I am also attaching my case setup (minus the geometry due to file size), since I know that this is probably a physics set up issue and not really a rotation issue. Hoping someone has any insights for me.

If not, I hope the set up helps people design and perform MRF simulations. That would provide more knowledge for all of us in the long run. The command sequence would be smth like:

blockMesh
snappyHexMesh
topoSet
simpleFoam

Kind regards,
Theodore.

[amintalezade]

Originally Posted by linnemann

The regions on each side of the AMI Connections are not allowed to be of different sizes and have non-overlap regions.

Hi linnemann

I have a question about your above statement : "AMI Connections are not allowed to be of different sizes and have non-overlap regions"

I am trying to simulate the propeller tutorial periodically. the two AMI connections in blade zone and the stationary zone moves besides each other and the the min value in the AMI patch target goes to zero and causes error like this:

Courant Number mean: 0.00113213 max: 0.683572
deltaT = 5e-06
Time = 0.00013

solidBodyMotionFunctions::rotatingMotion::transformation(): Time = 0.00013 transformation: ((0 0 0) (0.999947 (0 0.0102698 0)))
AMI: Creating addressing and weights between 2467 source faces and 2367 target faces
AMI: Patch source sum(weights) min/max/average = 0.635783, 1.00003, 0.997899
AMI: Patch target sum(weights) min/max/average = 0.785625, 1.0004, 0.999555
AMI: Creating addressing and weights between 6477 source faces and 6477 target faces
AMI: Patch source sum(weights) min/max/average = 0.999997, 1, 1
AMI: Patch target sum(weights) min/max/average = 0.999997, 1, 1
AMI: Creating addressing and weights between 6328 source faces and 6984 target faces
AMI: Patch source sum(weights) min/max/average = 0, 1.02797, 0.990961
AMI: Patch target sum(weights) min/max/average = :confused::confused:0.00514256, 1.00165, 0.988335
PIMPLE: iteration 1
smoothSolver:  Solving for Ux, Initial residual = 4.24196e-06, Final residual = 1.23042e-08, No Iterations 1
smoothSolver:  Solving for Uy, Initial residual = 5.83482e-06, Final residual = 1.76498e-08, No Iterations 1
smoothSolver:  Solving for Uz, Initial residual = 9.60301e-05, Final residual = 2.06976e-07, No Iterations 1
#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::sigFpe::sigHandler(int) at ??:?
#2  ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3  Foam::divide(Foam::Field<double>&, double const&, Foam::UList<double> const&) at ??:?
#4  Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > Foam::operator/<Foam::fvPatchField, Foam::volMesh>(Foam::dimensioned<double> const&, Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > const&) at ??:?
#5  ? at ??:?
#6  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#7  ? at ??:?
Floating point exception (core dumped)

so is cyclicAMI a suitable boundary condition for here?
how can I fix the problem?
and finally what do you mean by "1:1 geometry"? does it means that each cyclic AMI should contain only one face? my cyclicAMI faces are 3 as depicted below.

Best Regard

[atoof]

I think that the Arbitrary Coupled Mesh Interface (ACMI) would be a better B.C. for such cases.

Originally Posted by amintalezade

so is cyclicAMI a suitable boundary condition for here?
how can I fix the problem?
and finally what do you mean by "1:1 geometry"? does it means that each cyclic AMI should contain only one face? my cyclicAMI faces are 3 as depicted below.

[andrea.mala]

Hi all,
it is the first time that I write, but I follow you a few months. Thanks to your previous post, I was able to adapt the propeller tutorial to my case of a fan of an industrial oven (I used SHM propellerTip.obj replacing the file with a propeller STL files and varying parameters such as epsilon, k , nu, Maxco). The simulation converges and everything seems to be good.
At this point, I tried to replicate the same case using an external meshing (Hexpress of Numeca) instead of SHM.
First street, I built two meshes (external hollow cylinder and a small cylinder inside) and I used mergeMeshes and createPatch following your advice (I've also tried it with createBaffles) to create AMI1 and AMI2. When I start the simulations, however, I have weights problems (I think because the two interfaces have a different number of faces and align bad. Unfortunately I was not able to overcome this problem by using directly Hexpress (any advice on this point is appreciated).
Second road, I built a mesh with inside the fan and I used topoSet and createBaffles (as done in the propeller tutorial editing these files) to create AMI1 and AMI2. In this case, I get interfaces with the same number of faces that are well aligned in terms of weight. The simulation, however, diverges immediately. Opening the geometry with paraview, known that AMI1 and AMI2 not have a cylindrical contour, but are constituted by a "step" cells (which is not the case using SHM). This leads me to think it is due to the fact of not having a "guide" cylinder inside the mesh (as innerCylinderSmall for SHM).
So, third street, I built a single mesh with the small cylinder inside and the fan. But if at this point I try to create AMI1 and AMI2 with topoSet (as in the propeller tutorial, building a cylinder with cellToCylinder the same size as the one inside the mesh) the faceZone (amiCylinderFace) is empty.

I kindly ask you tips or ideas on how to proceed, because these roads do not seem to work. Thank you.
Andrea

[louisgag]

Hi Andrea and welcome to the forum,
To me it seems your problem is rather linked to the mesher you use. Perhaps you should seek support from them ?
Best Regards,
-Louis

[hoemmaria]

Hi, Louis.

I am having troubles with mesh generation using SnappyHexMesh. I am simulating a wind turbine in a wind tunnel with the use of a CAD model of the turbine and AMI.
So far I have managed to get the AMI weights to around 1 which was accomplished by using the faceType Baffles; as mentioned earlier in this thread.
However, both checkAMI and checkMesh does not like til mesh and I get 5 failed checks. This happens with and without the turbine, so I guess the problem is with the AMI somehow.

My snappyHexMeshDict looks as follows:

castellatedMesh true;
snap            true;
addLayers       false;

geometry
{
    refinementCylinder1
    {
    type searchableCylinder;
    point1 (-0.4 0 0);
    point2 (9 0 0);    
    radius 0.8;       
    }

    T1.stlb
    {
        type        triSurfaceMesh;
        name        T1;
    }

    innerCylinderSmall_tight.stl
    {
        type        triSurfaceMesh;
    name        innerCylinderSmall; 
    }

};


castellatedMeshControls
{

    // Refinement parameters
    // ~~~~~~~~~~~~~~~~~~~~~
    maxLocalCells 100000;
    maxGlobalCells 2000000;
    minRefinementCells 0;
    maxLoadUnbalance 0.10;
    nCellsBetweenLevels 3; 


    // Explicit feature edge refinement
    // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    features
    (
        {
            file        "innerCylinderSmall_tight.eMesh";
            level       5;
        }
        {
            file        "T1.eMesh";
            level       6;
        }
    );


    // Surface based refinement
    // ~~~~~~~~~~~~~~~~~~~~~~~~

    refinementSurfaces
    {
        innerCylinderSmall
        {
            level       (5 5);
            faceType    baffle; 
            cellZone    innerCylinderSmall;
            faceZone    innerCylinderSmall;
            cellZoneInside  inside;
        }
        T1
        {
            level       (5 7);
        }
    }

    resolveFeatureAngle 30;


    // Region-wise refinement
    // ~~~~~~~~~~~~~~~~~~~~~~

    refinementRegions
    {
        refinementCylinder1
        {
            mode        distance; //inside; 
            levels      (1E15 4);
        }

        innerCylinderSmall
        {
            mode        inside;
            levels      ((1E15 5));
        }
    }


    // Mesh selection
    // ~~~~~~~~~~~~~~
    locationInMesh (-1.3 0 0);

    allowFreeStandingZoneFaces false;
}


// Settings for the snapping.
snapControls
{
    nSmoothPatch 3;
    tolerance 1.0; // 
    nSolveIter 300;
    nRelaxIter 10;

    // Feature snapping
        nFeatureSnapIter 25; 
        implicitFeatureSnap true; //false; 
        explicitFeatureSnap false; //true; 
        multiRegionFeatureSnap false; 
        detectNearSurfacesSnap true; 
}


// Settings for the layer addition.
addLayersControls
{
    relativeSizes true;

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

    }

    expansionRatio 1.0;
    finalLayerThickness 0.3;
    minThickness 0.1;
    nGrow 0;

    // Advanced settings
    featureAngle 30;
    nRelaxIter 3;
    nSmoothSurfaceNormals 1;
    nSmoothNormals 3;
    nSmoothThickness 10;
    maxFaceThicknessRatio 0.5;
    maxThicknessToMedialRatio 0.3;
    minMedianAxisAngle 90;
    nBufferCellsNoExtrude 0;
    nLayerIter 50;
}



// Generic mesh quality settings. At any undoable phase these determine
// where to undo.
meshQualityControls
{
    maxNonOrtho 65;
    maxBoundarySkewness 20;
    maxInternalSkewness 4;
    maxConcave 80; //70;
    minVol 1e-13; //1e-16;
    minTetQuality -1; // 1e-30;
    minArea -1; //1e-13;
    minTwist 0.01; //0.025;
    minDeterminant 0.001; //0.002; 
    minFaceWeight 0.05; //0.02; 
    minVolRatio 0.01;
    minTriangleTwist -1;


    // Advanced

    nSmoothScale 4;
    errorReduction 0.75;
    relaxed
    {
        //- Maximum non-orthogonality allowed. Set to 180 to disable.
        maxNonOrtho 75; //95;
    }
}


mergeTolerance 1e-6;


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

And the feedback from checkAMI is:

Time = 0.08
PIMPLE: iteration 1
PIMPLE: iteration 2
    Point usage OK.
    Upper triangular ordering OK.
    Topological cell zip-up check OK.
    Face vertices OK.
    Number of identical duplicate faces (baffle faces): 384982
  <<Number of duplicate (not baffle) faces found: 7. This might indicate a problem.
  <<Number of faces with non-consecutive shared points: 7. This might indicate a problem.
    Mesh topology OK.
    Boundary openness (-1.1520507e-16 -5.2876705e-16 -1.2753255e-15) OK.
 ***High aspect ratio cells found, Max aspect ratio: 9.4997529e+96, number of cells 90035
    Minimum face area = 7.8491957e-10. Maximum face area = 0.0097616627.  Face area magnitudes OK.
 ***Zero or negative cell volume detected.  Minimum negative volume: -1.7082009e-06, Number of negative volume cells: 89799
    Mesh non-orthogonality Max: 179.9898 average: 22.450004
   *Number of severely non-orthogonal (> 70 degrees) faces: 473027.
 ***Number of non-orthogonality errors: 233232.
 ***Error in face pyramids: 671138 faces are incorrectly oriented.
 ***Max skewness = 3518830.2, 452361 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 384982 source faces and 384982 target faces
AMI: Patch source sum(weights) min/max/average = 1, 4.9054261, 1.0000555
AMI: Patch target sum(weights) min/max/average = 1, 3.1922214, 1.0000484
ExecutionTime = 791.42 s  ClockTime = 792 s

Do you see what I might be doing wrong of do you have some tips on how to to the meshing right?

Kind regards,
Maria

[louisgag]

Hi Maria,
It seems that the mesh has unacceptable non-orthogonality and skewness: did snappyHexMesh properly complete? Did it stop because it reached the maximum number of cells? If you can post your snappyHexMesh log it could give some hints.
Kind regards,
-Louis

[hoemmaria]

Thank you for such a quick reply!

SnappyHexMesh runs to the end stating "Finished meshing without any errors".
However, it does not run without troubles, and the following message is displayed a lot:

--> FOAM Warning : 
    From function void Foam::snappySnapDriver::calcNearestFace(Foam::label, const indirectPrimitivePatch&, const scalarField&, Foam::vectorField&, Foam::vectorField&, Foam::labelList&, Foam::vectorField&) const
    in file snappyHexMeshDriver/snappySnapDriverFeature.C at line 333
    Did not find surface near face centre (0.032849473 0.36393482 0.35608885)

It appears for A LOT of points. The file is too long to post here, 100 991 lines and 9.3MB (it even becomes too big to send as a zip-file).... So I guess there is a problem here, yes.

The end of snappyHexMeshDict says:

Checking final mesh ...
Checking faces in error :
    non-orthogonality > 65  degrees                        : 0
    faces with face pyramid volume < 1e-13                 : 0
    faces with face-decomposition tet quality < -1         : 0
    faces with concavity > 80  degrees                     : 0
    faces with skewness > 4   (internal) or 20  (boundary) : 0
    faces with interpolation weights (0..1)  < 0.05        : 0
    faces with volume ratio of neighbour cells < 0.01      : 0
    faces with face twist < 0.01                           : 0
    faces on cells with determinant < 0.001                : 0
Finished meshing without any errors
Finished meshing in = 9636.33 s.
End

Both innerCylinderSmall (for AMI) and T1 (turbine) shows as patches of type wall in the beginning, and they do apear as such in paraView.

[hoemmaria]

This is what appears at the first time something looks odd in log.snappyHexMesh

Morph iteration 0
-----------------
Calculating patchDisplacement as distance to nearest surface point ...
--> FOAM Warning : 
    From function static Foam::vectorField Foam::snappySnapDriver::calcNearestSurface(const Foam::meshRefinement&, const scalarField&, const indirectPrimitivePatch&, Foam::pointField&, Foam::vectorField&)
    in file snappyHexMeshDriver/snappySnapDriver.C at line 1638
    For point:111 coordinate:(0.0017006904 -0.038190952 0.046531304) did not find any surface within:0.00077963914 metre.

and then the end of that "error":

--> FOAM Warning : 
    From function void Foam::snappySnapDriver::calcNearestFace(Foam::label, const indirectPrimitivePatch&, const scalarField&, Foam::vectorField&, Foam::vectorField&, Foam::labelList&, Foam::vectorField&) const
    in file snappyHexMeshDriver/snappySnapDriverFeature.C at line 397
    Did not find surface near face centre (-0.0048429234 -0.0028452753 -0.057680117)
Attraction:
     linear   : max:(-0.0017834549 -0.00135829 -0.0018018673) avg:(-1.1809928e-05 -9.9177178e-07 -3.4400299e-06)
     feature  : max:(-0.00015530245 -0.0042471306 -0.00019065496) avg:(-1.2218327e-05 -4.0699936e-07 -3.7050001e-06)
Feature analysis : total master points:576407 attraction to :
    feature point   : 55
    feature edge    : 15418
    nearest surface : 560934
    rest            : 0

[louisgag]

Hi Maria,

I have two further suggestions:

- try to do a much coarser mesh and see what happens (reduce all or most levels by 2 for example); do the same error messages appear?
-- doing so will allow you to perform a "debugging" much faster
-- maybe the snappy log will also be easy to post here ;-)

- do all the problems of the non-ortho, skewed, and not-found faces also occur with a) the coarser mesh and b) as mesh without baffles or without the actual cylinder interfaces ?

Hope this helps,


-Louis

[hoemmaria]

Thank you for your advice, Louis!

I have now tried to have a coarser mesh, and it does get all the same five geometry failures.

The only odd thing I get out of the snappyHexMesh log is that it says:

--> FOAM Warning : Displacement (-1.4793118e-06 -4.3506502e-05 5.1446667e-05) at mesh point 747934 coord (0.0027575758 -0.040337193 0.048917823) points through the surrounding patch faces
Smoothing displacement ...

This occurs even without the turbine when I mesh only the AMI from the cylinder. And no change to the five geometry failures.

When I try running meshing without the AMI cylinder and only the turbine I get the same warning as above. Here, checkMesh only reports errors with skewness.

I have added the snappyHexMesh log and the moveDynamicMesh log in the attached folder. There is also added the case files without the turbine - the design is not mine to share.


Kind regards,
Maria

[louisgag]

How coarse is the baffle? The innerCycl...stl cell sizes are, I think, much too small. Is the baffle much coarser? Otherwise, trying making is coarser.

I'm not sure if this "Displacement points through the surrounding patch faces" warning you point out is something to worry about, I would say no but I cannot guarantee it is not causing some weird mesh rearrangement, perhaps someone else can pitch in...

I've had a quick look at your files, one idea that comes to mind is that you could have an imposed movement not compatible with the mesh. It's easy to check, just run checkMesh before moveDynamicMesh -checkAMI in your script... If the mesh at time 0 is fine, then the imposed movement is not and you can probably see how using paraview and running moveDynamicMesh with a very small timestep...

Also, this line "cp -rf 0.orig 0" should go before doing moveDynamicMesh and checkMesh.

You can also test the results of using a 10x or 100x larger "matchTolerance 0.0001;" in your createPatchDict file and increase "maxNonOrtho 65;" to 75 in snappyHexMesh...

Hope this helps, otherwise write again but keep in mind I will not be checking during the vacations.

-Louis

[hoemmaria]

Thank you, Louis.

You were right, there is something wrong happening when the mesh is rotated.
I have been trying different things over the holiday and I can't make the "faceType baffles;" work - it creates a distorted mesh when rotated where there is no sliding interface between the stationary and rotating mesh, see added pictures.
When having the a solid body with rotatingMotion dynamicmesh I can make progress when using "faceType boundary;" such as in the Propeller tutorial.
This markes only high skewness for the mesh check which occurs at the tail edge of the turbine.
However, now I am back at having a few faces with zero weight for the AMI. I am trying to solve this problem with using "lowWeightCorrection 0.2" in the "CreatePatchDict" for the AMI.
There are only a few faces, ~5, that have low weights, the average is close to 1.
This takes quite a long time to test, so I will report back whether or not it works to just exclude the few zero-weighted cells.

I have followed your tip of having coarser innerCylinderSmall for the AMI, this helped to get fewer cells with low weights. And I have increased the "matchTollerance" to 0.01 and "maxNonOrtho" to 75 as you suggested.

Have you made a simulation work with AMI defined as baffles or boundary before that is somewhat similar to mine? Just curious if it is just my case setup that does not work with baffles or not.

Thank you for your input, do you have more ideas?


Happy New Year!
- Maria

[louisgag]

Hi Maria and happy new year,

If your mesh deforms instead of "sliding" it probably means that the zones you are defining as rotating using the AMI algorithm do not correspond to the cylinders you created with snappyHexMesh.

Yes, I have done both 2D and 3D simulations with AMI/baffles and such deformations usually occur to me when I misplace the center of rotation or use an offset cylindrical zone with respect to the mesh's cyclinder. Do keep in mind that defining the mesh as baffle in snappyHexMesh is not obligatory, it just tells the mesher to create an interface, but alternatively you can do it manually afterwards if snappy doesn't create the two faces itself (inner AMI and outer AMI).

At this point, if even with a coarser mesh testing is slow, I would recommended doing it with a 2D mesh first, and once you have a case moving properly switch to a really coarse 3D mesh because to test mesh motion it doesn't really matter how fine is the mesh.. To avoid changing mesher I think you could force snappyHexMesh to make a 2D mesh by feeding it a thin 1-cell thick mesh and removing the propellers...

Hope this helps, let me know.


-Louis

[hoemmaria]

Thank you, Louis!

You were right, my cylinder was a little offset, so by correcting the location helped a little.
However, it didn't do the full job, but I went back some pages in the forum and saw your previous post about using mergeOrSplitBaffles -split and that helped!

Now the mesh is sliding and the AMI weights are quite good. There are some very few cells with low weigts so I still use lowWeightCorrection 0.2.

Again, thank you for all your input and help! I appreciate it

- Maria

[Bashar]

Hi,

I am facing an issues in my oprnFoam 5x case. I am using cyclicAMI for interfaces inside my mesh. I decompose the case and run it perfectly without any issues. I need to reconstruct the case, however when I use reconstruct command I get the following error:

Reconstructing fields for mesh region0

Time = 30.00003

Reconstructing FV fields

    Reconstructing volScalarFields

        nut
AMI: Creating addressing and weights between 1538 source faces and 1642 target faces


--> FOAM FATAL ERROR: 
Unable to set source and target faces

    From function void Foam::faceAreaWeightAMI<SourcePatch, TargetPatch>::setNextFaces(Foam::label&, Foam::label&, Foam::label&, const boolList&, Foam::labelList&, const Foam::DynamicList<long int>&, bool) const [with SourcePatch = Foam::PrimitivePatch<Foam::face, Foam::SubList, const Foam::Field<Foam::Vector<double> >&>; TargetPatch = Foam::PrimitivePatch<Foam::face, Foam::SubList, const Foam::Field<Foam::Vector<double> >&>; Foam::label = long int; Foam::boolList = Foam::List<bool>; Foam::labelList = Foam::List<long int>]
    in file lnInclude/faceAreaWeightAMI.C at line 287.

FOAM aborting

#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::error::abort() at ??:?
#2  Foam::faceAreaWeightAMI<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::calcAddressing(Foam::List<Foam::DynamicList<long, 0u, 2u, 1u> >&, Foam::List<Foam::DynamicList<double, 0u, 2u, 1u> >&, Foam::List<Foam::DynamicList<long, 0u, 2u, 1u> >&, Foam::List<Foam::DynamicList<double, 0u, 2u, 1u> >&, long, long) at ??:?
#3  Foam::faceAreaWeightAMI<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::calculate(Foam::List<Foam::List<long> >&, Foam::List<Foam::List<double> >&, Foam::List<Foam::List<long> >&, Foam::List<Foam::List<double> >&, long, long) at ??:?
#4  Foam::AMIInterpolation<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::update(Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&) at ??:?
#5  Foam::AMIInterpolation<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::constructFromSurface(Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&, Foam::autoPtr<Foam::searchableSurface> const&) at ??:?
#6  Foam::AMIInterpolation<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::AMIInterpolation(Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&, Foam::autoPtr<Foam::searchableSurface> const&, Foam::faceAreaIntersect::triangulationMode const&, bool, Foam::AMIInterpolation<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::interpolationMethod const&, double, bool) at ??:?
#7  Foam::cyclicAMIPolyPatch::resetAMI(Foam::AMIInterpolation<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::interpolationMethod const&) const at ??:?
#8  Foam::cyclicAMIPolyPatch::AMI() const at ??:?
#9  Foam::cyclicAMIPolyPatch::applyLowWeightCorrection() const at ??:?
#10  Foam::cyclicAMIFvPatch::makeWeights(Foam::Field<double>&) const at ??:?
#11  Foam::surfaceInterpolation::makeWeights() const at ??:?
#12  Foam::surfaceInterpolation::weights() const at ??:?
#13  Foam::fvPatch::weights() const at ??:?
#14  Foam::coupledFvPatchField<double>::evaluate(Foam::UPstream::commsTypes) at ??:?
#15  Foam::cyclicFvPatchField<double>::cyclicFvPatchField(Foam::fvPatch const&, Foam::DimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) at ??:?
#16  Foam::fvPatchField<double>::adddictionaryConstructorToTable<Foam::cyclicFvPatchField<double> >::New(Foam::fvPatch const&, Foam::DimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) at ??:?
#17  Foam::fvPatchField<double>::New(Foam::fvPatch const&, Foam::DimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) at ??:?
#18  Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::Boundary::readField(Foam::DimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) at ??:?
#19  Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::readFields(Foam::dictionary const&) at ??:?
#20  Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::readFields() at ??:?
#21  Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::GeometricField(Foam::IOobject const&, Foam::fvMesh const&) at ??:?
#22  ? at ??:?
#23  ? at ??:?
#24  ? at ??:?
#25  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#26  ? at ??:?
Aborted (core dumped)

My creratePatch sample is :

FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    object      createPatchDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

// This application/dictionary controls:
// - optional: create new patches from boundary faces (either given as
//   a set of patches or as a faceSet)
// - always: order faces on coupled patches such that they are opposite. This
//   is done for all coupled faces, not just for any patches created.
// - optional: synchronise points on coupled patches.
// - always: remove zero-sized (non-coupled) patches (that were not added)

// 1. Create cyclic:
// - specify where the faces should come from
// - specify the type of cyclic. If a rotational specify the rotationAxis
//   and centre to make matching easier
// - always create both halves in one invocation with correct 'neighbourPatch'
//   setting.
// - optionally pointSync true to guarantee points to line up.

// 2. Correct incorrect cyclic:
// This will usually fail upon loading:
//  "face 0 area does not match neighbour 2 by 0.0100005%"
//  " -- possible face ordering problem."
// - in polyMesh/boundary file:
//      - loosen matchTolerance of all cyclics to get case to load
//      - or change patch type from 'cyclic' to 'patch'
//        and regenerate cyclic as above

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



    {
        // Name of new patch
        name cycAMI_1;

        // Dictionary to construct new patch from
        patchInfo
        {
            type cyclicAMI;
            neighbourPatch cycAMI_2;

            // Optional: explicitly set transformation tensor.
            // Used when matching and synchronising points.
            //transform rotational;
            //rotationAxis (1 0 0);
            //rotationCentre (0 0 0);
             transform coincidentFullMatch;
            // separationVector (1 0 0);

            // Optional non-default tolerance to be able to define cyclics
            // on bad meshes
            //matchTolerance 1E-2;
        }

        // How to construct: either from 'patches' or 'set'
        constructFrom patches;

        // If constructFrom = patches : names of patches. Wildcards allowed.
        patches (d_l);

        // If constructFrom = set : name of faceSet
        //set f0;
    }
    {
        // Name of new patch
        name cycAMI_2;

        // Dictionary to construct new patch from
        patchInfo
        {
            type cyclicAMI;
            neighbourPatch cycAMI_1;

            // Optional: explicitly set transformation tensor.
            // Used when matching and synchronising points.
            //transform rotational;
            //rotationAxis (1 0 0);
            //rotationCentre (0 0 0);
            transform coincidentFullMatch;
            // separationVector (1 0 0);
        }

        // How to construct: either from 'patches' or 'set'
        constructFrom patches;

        // If constructFrom = patches : names of patches. Wildcards allowed.
        patches (d_s);

        // If constructFrom = set : name of faceSet
        //set f0;
    }
























/*
    {

       
       // Name of new patch
        name cyc_1;

        // Dictionary to construct new patch from
        patchInfo
        {
            type cyclic;
            neighbourPatch cyc_2;

            // Optional: explicitly set transformation tensor.
            // Used when matching and synchronising points.
            //transform rotational;
            //rotationAxis (1 0 0);
            //rotationCentre (0 0 0);
            // transform translational;
            // separationVector (1 0 0);

            // Optional non-default tolerance to be able to define cyclics
            // on bad meshes
            //matchTolerance 1E-2;
        }

        // How to construct: either from 'patches' or 'set'
        constructFrom patches;

        // If constructFrom = patches : names of patches. Wildcards allowed.
        patches (symmetry1);

        // If constructFrom = set : name of faceSet
        //set f0;
    }
    {
        // Name of new patch
        name cyc_2;

        // Dictionary to construct new patch from
        patchInfo
        {
            type cyclic;
            neighbourPatch cyc_1;

            // Optional: explicitly set transformation tensor.
            // Used when matching and synchronising points.
            //transform rotational;
            //rotationAxis (1 0 0);
            //rotationCentre (0 0 0);
            // transform translational;
            // separationVector (1 0 0);
        }

        // How to construct: either from 'patches' or 'set'
        constructFrom patches;

        // If constructFrom = patches : names of patches. Wildcards allowed.
        patches (symmetry2);

        // If constructFrom = set : name of faceSet
        //set f0;





    }




    {
        // Name of new patch
        name symmetry2;

        // Dictionary to construct new patch from
        patchInfo
        {
            type patch;
            //neighbourPatch cyc_half1;

            // Optional: explicitly set transformation tensor.
            // Used when matching and synchronising points.
           // transform rotational;
            //rotationAxis (1 0 0);
           // rotationCentre (0 0 0);
            // transform translational;
            // separationVector (1 0 0);

            // Optional non-default tolerance to be able to define cyclics
            // on bad meshes
            //matchTolerance 1E-2;
        }

        // How to construct: either from 'patches' or 'set'
        constructFrom patches;

        // If constructFrom = patches : names of patches. Wildcards allowed.
        patches (FaceGroup17  FaceGroup8);

        // If constructFrom = set : name of faceSet
        //set f0;
    }



*/


);

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

I tried to use reconstruParMesh first but same error.
Any adivce will be really apprciated , unfortunatlly its very computationally expensive simulation sine its LES and I need to reconstruct the case .

Thanks
Bashar

[otaolafr]

Hello everybody,
I am seeking help with the cyclicAMI boundary condition,
I am meshing a geometry with snappy and after this step, I create my cyclicAMI patches with the createPatch function. my issue seems to comme from the difference in number of faces between the inlet and outlet patches see error:

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

I have looked my geometry in paraview it looks correctly, the bc are selected correctly and they are really similar (at least from a human point of view) and the difference in faces is minimal. 0.02%! anyone have faced this issue? and solved? I made a thread in the forum without a lot of luck.... Creating mesh for cyclicAMI boundaries any help would be appreciated!

[louisgag]

Having different number of cells on the two neighboring patches is not an issue.
It sounds like you have one cell face that doesn't find any neighbor, that's an issue.
There are some parameters to ignore this type of issue or you can verify visually that all faces properly match with one or more neighbors