[KateEisenhower]

Hello foamers,

I am trying to set up cyclic boundary condition for the front and back patch of my wind tunnel-like mesh. My /constant/polyMesh/boundary file looks as follows:

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2.3.1                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      binary;
    class       polyBoundaryMesh;
    location    "constant/polyMesh";
    object      boundary;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

7
(
    front
    {
        type            cyclic;
        nFaces          139111;
        startFace       16106807;
        matchTolerance  0.0001;
        neighbourPatch  back;

    }
    bottom
    {
        type            wall;
        physicalType    wall;
        nFaces          6981;
        startFace       16245918;
    }
    back
    {
        type            cyclic;
        nFaces          139111;
        startFace       16252899;
        matchTolerance  0.0001;
        neighbourPatch  front;
    }
    outlet
    {
        type            patch;
        physicalType    outlet;
        nFaces          15639;
        startFace       16392010;
    }
    object
    {
        type            wall;
        physicalType    wall;
        nFaces          16029;
        startFace       16407649;
    }
    top
    {
        type            wall;
        physicalType    wall;
        nFaces          9321;
        startFace       16423678;
    }
    inlet
    {
        type            patch;
        physicalType    inlet;
        nFaces          12168;
        startFace       16432999;
    }
)

My /0/U file is the following:

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

dimensions      [0 1 -1 0 0 0 0];

internalField   uniform (10 0 0);

boundaryField
{
    inlet
    {
        type            fixedValue;
        value           uniform (10 0 0);
    }

    outlet
    {
        type            zeroGradient;
    }

    object
    {
        type            fixedValue;
        value           uniform (0 0 0);
    }



    front
    {
        type            cyclic;
    }

    back
    {
        type            cyclic;
    }

    top
    {
        type            slip;
    }

    bottom
    {
        type            slip;
    }

}

The p, k, omega and nut files are set up accordingly.

When running potentialFoam on this case, I get the following:

/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2.3.1                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
Build  : 2.3.1-262087cdf8db
Exec   : potentialFoam
Date   : Oct 20 2015
Time   : 14:02:12
Host   : "asdf.asdf.local"
PID    : 43912
Case   : /Users/kateeisenhower/Documents/asdf/asdf_cyclic
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Allowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0



--> FOAM FATAL ERROR: 
face 6981 area does not match neighbour by 0.0936416% -- possible face ordering problem.
patch:front my area:9.84893e-10 neighbour area:9.85816e-10 matching tolerance:0.0001
Mesh face:16113788 fc:(0.750509 -0.05 -0.165463)
Neighbour fc:(0.750509 0.05 -0.165463)
If you are certain your matching is correct you can increase the 'matchTolerance' setting in the patch dictionary in the boundary file.
Rerun with cyclic debug flag set for more information.

    From function cyclicPolyPatch::calcTransforms()
    in file meshes/polyMesh/polyPatches/constraint/cyclic/cyclicPolyPatch.C at line 221.

FOAM exiting

Because I am relatively certain that my matching is correct, I increased my matchTolerance to 1. Then potentialFoam runs as expected. But I guess simply setting the matchTolerance to 1 is not the solution.

When I set the matchTolerance to 0.1, I get a similar Error as with 0.0001:

/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2.3.1                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
Build  : 2.3.1-262087cdf8db
Exec   : potentialFoam
Date   : Oct 20 2015
Time   : 14:36:32
Host   : "asdf.asdf.local"
PID    : 6940
Case   : /Users/kateeisenhower/Documents/asdf/asdf_cyclic
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Allowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0



--> FOAM FATAL ERROR: 
face 7012 area does not match neighbour by 10.2174% -- possible face ordering problem.
patch:front my area:4.48033e-09 neighbour area:4.96274e-09 matching tolerance:0.1
Mesh face:16113819 fc:(0.751172 -0.05 -0.163784)
Neighbour fc:(0.751174 0.05 -0.163784)
If you are certain your matching is correct you can increase the 'matchTolerance' setting in the patch dictionary in the boundary file.
Rerun with cyclic debug flag set for more information.

    From function cyclicPolyPatch::calcTransforms()
    in file meshes/polyMesh/polyPatches/constraint/cyclic/cyclicPolyPatch.C at line 221.

FOAM exiting

In order to solve this problem and to make sure my matching is correct, I would like to view the mentioned face 7012 in ParaView. Maybe I can get some clue then. How can I do that?

I'd appreciate any help/comments/ideas on this.

Best regards,

Kate

p.s.: Sorry but I'm not allowed to share my mesh.

Quick update: It seems to run with cyclicAMI instead of cyclic. Don't know why and don't know really what cyclicAMI is doing but I am looking into this right now.

Another update: I found this website (http://www.openfoam.org/version2.3.0/ami.php) which was part of the OpenFOAM 2.3.0 release notes. The first sentence of this document tells the reader that

AMI was introduced to enable simulation across disconnected, adjacent, mesh domains.

I don’t understand this. Disconnected is the opposite of adjacent, right? I’m not a native speaker, so please correct me if I’m wrong.

Next, as I understand it a face doesn’t have to match exactly with its counterpart. If this is the case, a face takes contributions from several counterpart-faces. This is no problem as far as the whole face is covered by parts of the counterpart faces. Then the weight of the face equals 1. But it may also be the case that the weight of a face deviats from 1.
Now my question is: How can this happen if the surface mesh doesn't have holes in it? Doesn’t the simulation diverge then? The only possibility I can imagine is, that the border lines of the two patches don’t match.

As already mentioned, in my case with cyclicAMI potentialFoam is working. But I get the following message:

AMI: Creating addressing and weights between 139111 source faces and 139111 target faces
AMI: Patch source sum(weights) min/max/average = 0.999985, 1.00001, 1
AMI: Patch target sum(weights) min/max/average = 0.999975, 1.00003, 1
No finite volume options present

I think this means that not all of my faces are completely matched. Do I have to worry about it?

Overall, you can only use cyclic boundary condition if the two patches are exactly the same. You have to use cyclicAMI for all the rest, right? This means if you work with an unstructured mesh, you have to use cyclicAMI?

[nimasam]

nice job!

I think this means that not all of my faces are completely matched. Do I have to worry about it?

1- you are right there is no exact match between faces.
2- nope, its ok!

Overall, you can only use cyclic boundary condition if the two patches are exactly the same. You have to use cyclicAMI for all the rest, right? This means if you work with an unstructured mesh, you have to use cyclicAMI?

1- again you right
2-absolutely true ,

[HannesGS]

Originally Posted by KateEisenhower

Overall, you can only use cyclic boundary condition if the two patches are exactly the same. You have to use cyclicAMI for all the rest, right? This means if you work with an unstructured mesh, you have to use cyclicAMI?

I disagree with this part. To my knowledge it is true that the cyclic boundary condition requires the location of all points to match. Patches with cyclicAMI can have non-matching points, but the patch boundaries should match, too.

Why should it be impossible to have matching connections with an unstructured mesh?

http://www.cfd-online.com/Forums/ope...ease-help.html

How do you generate your mesh? It seems odd to me that the matching error increases after you change your mesh tolerance. Can you read your mesh into Paraview? Are the cyclic boundaries rotational or translational?

[KateEisenhower]

Hello Hannes and thank you for your answer!

Your first paragraph is confusing to me. Are you refering to the nodes of the individual elements when you are talking of points?

Regarding the unstructered mesh, maybe there is a misunderstanding. In a unstructered mesh it is highly unlikely that all the faces on two different boundaries do match, isn't it?

I generated a structured mesh with gmsh and then imported it with gmshToFoam. My cyclic boundaries are translational and yes, I can read my mesh into paraview.

Best regards,

Kate

PS: Also many thanks to Nima for her input!

[HannesGS]

Originally Posted by KateEisenhower

Hello Hannes and thank you for your answer!

Your first paragraph is confusing to me. Are you refering to the nodes of the individual elements when you are talking of points?

Yes that's what I meant. I called them points since they are saved in the points file of OpenFOAM.

Regarding the unstructered mesh, maybe there is a misunderstanding. In a unstructered mesh it is highly unlikely that all the faces on two different boundaries do match, isn't it?

I would say it's a question of how the mesh is generated. There certainly are unstructured meshes with periodic connections.

I generated a structured mesh with gmsh and then imported it with gmshToFoam. My cyclic boundaries are translational and yes, I can read my mesh into paraview.

Anyway, if your connection is non-matching and you are happy with using cyclicAMI, there is no need for further discussion :-) I basically wanted to comment on the issue of periodic connections with unstructured meshes.

[PanPeter]

hi together,
I experience the same problem:
A structured mesh for a simple cylinder flow benchmark is generated in starccm+ and converted to openfoam with ccm26toFoam.
The periodic boundary is then created through the createPatch function in which I have to use an enormous match tolerance of 0.1 to avoid getting the same error as Ms Eisenhower, namely:

--> FOAM Serious Error : 
    From function cyclicPolyPatch::order(const primitivePatch&, labelList&, labelList&) const
    in file meshes/polyMesh/polyPatches/constraint/cyclic/cyclicPolyPatch.C at line 1402
    Patch:PB_A2 : Cannot match vectors to faces on both sides of patch
    Perhaps your faces do not match? The obj files written contain the current match.
    Continuing with incorrect face ordering from now on!


--> FOAM FATAL ERROR: 
face 175 area does not match neighbour by 18.5333% -- possible face ordering problem.
patch:PB_A1 my area:1e-06 neighbour area:8.30385e-07 matching tolerance:0.001
Mesh face:646158 fc:(-0.0435 0.0395 0.03)
Neighbour fc:(-0.0364698 0.0165608 -1.10462e-16)
If you are certain your matching is correct you can increase the 'matchTolerance' setting in the patch dictionary in the boundary file.
Rerun with cyclic debug flag set for more information.

    From function cyclicPolyPatch::calcTransforms()
    in file meshes/polyMesh/polyPatches/constraint/cyclic/cyclicPolyPatch.C at line 221.

FOAM exiting

This is my createPatch file:

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

pointSync true;

// Patches to create.
patches
(
    {
        name PB_A1;

        patchInfo
        {
            type cyclic;
            neighbourPatch PB_A2;
            matchTolerance  0.001;
        }

        constructFrom patches;
        patches (SymA1);
    }
    {
        name PB_A2;

        patchInfo
        {
            type cyclic;
            neighbourPatch PB_A1;
            matchTolerance  0.001;
        }

        constructFrom patches;
        patches (SymA2);
    }
);

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

This should be a very simple example for parallel periodic boundary surfaces and thus I want to see why I can't have a match tolerance of 1e-3. Furthermore, I refrain from trying cyclicAMI, as it sounds as it's doing some serious remapping and that should not be necessary for my simple test case.

Thanks for your help!

[ykanani]

I am not sure you have resolved you problem or not. Nut thought sharing my experience may help others.

I have had this problem for grids converted from ICEM. First I suspected that something is wrong with openfoam, but I realized nothing is wrong with openfoam and if it says there is some percentage of difference between cell area's, there is!

To solution is to go back to your Meshing software and make everything is "Prefect" especially near walls where cell face areas are very small. The cell coordinates that openfoam gives in the error is a good start point to start your inspection. Since the grids are so small, visually we my not see difference but you need zoom in very close to the area of the interest and find out what is the problem.

What I do in ICEM is that first I force cyclic block vertices to have the exact coordinate. Then for example if my cyclic patches are in z-direction, I set the camera exactly in the z direction. Normally each patch has the different color, so anywhere that you see a little mixture of the other color (representing the patch in the back) there is a problem in the cyclic grid and needs to be resolved.

Sometimes it gets frustrating but this significantly reduces the acceptable tolerance in the openfoam. And note the the tolerance is the "difference" in the face center respect to the owner face so if your multiply it by 100 you will get the precentage of the difference. So when you receive an error that :

face 175 area does not match neighbour by 18.5333% ...

it means that by setting tolerance to something greater than 0.185333 will suppress the error (for that specific face). But it is better to always to try and make the grid quality better in the meshing software.

Hope this helps you.
Yousef