CFD Online Discussion Forums - Cyclic Boundary Condition

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

- OpenFOAM Running, Solving & CFD (https://www.cfd-online.com/Forums/openfoam-solving/)

- - Cyclic Boundary Condition (https://www.cfd-online.com/Forums/openfoam-solving/58041-cyclic-boundary-condition.html)

I suffered with same problem before. I made completely same thing. It worked. Only thing, I changed the matchTolerance in createPatchDict to 3e-3

Quote:

Originally Posted by mcjicpm2 (Post 217437)

Hi, I am having difficulty in creating cyclic boundary condition, I have done it this way:
1- I created a mesh in Gambit (Quarter of a cylinder) and I called the two planes symmetrya and symmetryb. and I set them to be symmetry for periodic bc.
2-set the writePrecision in system/controlDict to 12.
3-In the end of *.msh file I saw
(0 "Cells:")
(12 (0 1 5eb78 0))
(12 (2 1 5eb78 1 4))

(0 "Zones:")
(45 (2 fluid fluid)())
(45 (3 mass-flow-inlet ariinlet2)())
(45 (4 symmetry symmetryb)())
(45 (5 symmetry symmetrya)())
(45 (6 pressure-outlet outlet)())
(45 (7 wall wall)())
(45 (8 mass-flow-inlet airinlet1)())
(45 (9 mass-flow-inlet fuelinlet)())
(45 (11 interior default-interior)())

I did not change anything here, and leave it as it is.
3-then I ran fluentMeshTofoam *.msh :

Building boundary and internal patches.
Creating patch 0 for zone: 3 start: 1 end: 25 type: mass-flow-inlet name: ariinlet2
Creating patch 1 for zone: 4 start: 26 end: 10345 type: symmetry name: symmetryb
Creating patch 2 for zone: 5 start: 10346 end: 20665 type: symmetry name: symmetrya
Creating patch 3 for zone: 6 start: 20666 end: 23898 type: pressure-outlet name: outlet
Creating patch 4 for zone: 7 start: 23899 end: 34233 type: wall name: wall
Creating patch 5 for zone: 8 start: 34234 end: 34263 type: mass-flow-inlet name: airinlet1
Creating patch 6 for zone: 9 start: 34264 end: 34306 type: mass-flow-inlet name: fuelinlet
Creating patch 7 for zone: 11 start: 34307 end: 1181033 type: interior name: default-interior
Adding new patch ariinlet2 of type patch as patch 0
Adding new patch symmetryb of type symmetryPlane as patch 1
Adding new patch symmetrya of type symmetryPlane as patch 2
Adding new patch outlet of type patch as patch 3
Adding new patch wall of type wall as patch 4
Adding new patch airinlet1 of type patch as patch 5
Adding new patch fuelinlet of type patch as patch 6
Patch default-interior is internal to the mesh and is not being added to the boundary.

Default patch type set to empty

Writing mesh... to "constant/polyMesh" done.

End

4-It creates in the constant/polymesh ---> boundary :

7
(
ariinlet2
{
type patch;
nFaces 25;
startFace 1146727;
}
symmetryb
{
type symmetryPlane;
nFaces 10320;
startFace 1146752;
}
symmetrya
{
type symmetryPlane;
nFaces 10320;
startFace 1157072;
}
outlet
{
type patch;
nFaces 3233;
startFace 1167392;
}
wall
{
type wall;
nFaces 10335;
startFace 1170625;
}
airinlet1
{
type patch;
nFaces 30;
startFace 1180960;
}
fuelinlet
{
type patch;
nFaces 43;
startFace 1180990;
}
)

5-then I define the createPatchDict in /system and within that I have:
matchTolerance 1E-3;
pointSync true;
patches
(
{
name symmetrya;

type cyclic;

constructFrom patches;

patches (symmetrya symmetryb);
}
);

6-then I ran createPatch, this was the outcome:
Create time

Reading createPatchDict.

Using relative tolerance 0.001 to match up faces and points

Create polyMesh for time = 0

Moving faces from patch symmetrya to patch 2
Moving faces from patch symmetryb to patch 2

Doing topology modification to order faces.

Synchronising points.
Points changed by average:0 max:0

Removing patches with no faces in them.

Removing empty patch symmetryb at position 1
Removing patches.
Writing repatched mesh to 1

End
7-It creates a folder /1/polyMesh and within that:
[]$ ls
boundary cellZones faces faceZones neighbour owner points pointZones

8-vi boundary :
6
(
ariinlet2
{
type patch;
nFaces 25;
startFace 1146727;
}
symmetrya
{
type symmetryPlane;
nFaces 20640;
startFace 1146752;
}
outlet
{
type patch;
nFaces 3233;
startFace 1167392;
}
wall
{
type wall;
nFaces 10335;
startFace 1170625;
}
airinlet1
{
type patch;
nFaces 30;
startFace 1180960;
}
fuelinlet
{
type patch;
nFaces 43;
startFace 1180990;
}
)

8-I copy all the contents of this folder to constant/polymesh/

9- I did changed the symmetryplane type now to cyclic for symmetrya

10-I did the simpleFoam and I received this error:

Create time
Create mesh for time = 0
face 0 area does not match neighbour 10320 by 21.8435% -- possible face ordering problem.
patch:symmetrya my area:0.000277 neighbour area:0.000344925 matching tolerance:0.001
Mesh face:1146752 vertices:4((0 0 0.1123) (0.05 0 0.1123) (0.05 0 0.11784) (0 0 0.11784))
Neighbour face:1157072 vertices:4((0 0.043315 0) (0 0.0502135 0) (0.05 0.0502135 0) (0.05 0.043315 0))
Rerun with cyclic debug flag set for more information.

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

FOAM exiting

Can anyone help me with this problem?

Quote:

Originally Posted by Brandon Field (Field) (Post 202942)

Hi,

I hope you don't mind if I pick this thread back up, since it is clearly the area where my question falls.

If I were to try to incorporate this into a multi-phase simulation, could I just copy the createGradP.H and writeGradP.H files and make the appropriate changes to the interFoam.C file (including the modifications to the governing equations) and then re-compile interFoam into something like channelInterFoam? Or is this implementation specific to anything in single-phase or turbulence and thus cause problems with the two-phases?

thanks,
brandon.

@Brandon: Did you have any success with cyclic multiphase flow? I believe I implemented something similar through Fluent UDFs but I am having some issues so I am considering moving to openFOAM where I could have a bit more of a freedom of coding. Do you have any new thoughts about the topic?

Yes it is possible

Quote:

Originally Posted by AlmostSurelyRob (Post 284616)

@Robert I had this same question a while ago and yes it is possible (http://www.cfd-online.com/Forums/ope...tml#post284703) That might be a better spot to talk about it than in the current thread.

Summary of experiences with Cyclic BCs

What I found out about cyclic boundary conditions is:

1.) Care has to be taken when running in parallel: Every single processor has to have both corresponding cell sets of a cyclic patch within its computational region. Experience with various geometries has shown that the distribution of 2 "cyclical" cells (cells from different faces but same cyclic patch) into 2 different processor regions results in faulty matching, but the simulation can still be run. Without warning the user, the unwanted matches then obviously produce errors.

-> This means that for e.g. a squareDuct with 4 cyclic walls one can only split the computational domain in streamwise direction. Zero spanwise, only streamwise cuts (in this particular case).

2.) The patch type of cyclic patches has to be set to cyclic (within blockMeshDict respectively constant/polyMesh/boundary). Also the boundary conditions for all fields in the time folders have to be set to cyclic as well, logically.

3.) To avoid improper and unwanted matches, every cyclic patch should only consist of 2 faces. These are the faces that have to be connected.
It is possible to include more than 2 faces within a cyclic patch, though. But it might be that they will not be matched properly, if the order of the definition of faces is incorrect.

-> Does someone know how faces should be ordered, if a cyclic patch comprises more than two faces? Pairwise in sequence?

4.) Cyclic patches seem to have issues when refining with refineMesh

Please correct me if statements 1 to 4 turn out to be wrong. Additional posting of experiences is appreciated.

Regards,
Bernhard

Hi everyone,

I have been doing a lot of channel flows using anything from 4 processor folders up to 36. Decomposed using the metis method.

Bernhard, how do you see the effects of what happens under number 1 in your list? I don't see weird things going on in paraview and my velocity profiles seem reasonable.

I have used both meshes from blockMesh and meshes imported from Star-CCM.

Quote:

Originally Posted by stevenvanharen (Post 285216)

Bernhard, how do you see the effects of what happens under number 1 in your list? I don't see weird things going on in paraview and my velocity profiles seem reasonable.

Hello Steven,

I was refering to a LES on rod bundles where I expected secondary vortices after averaging the flow field for several 100'000 timesteps, but none of them appeared at the supposed locations. Then I extracted some cuts through my flow field and I realized that fields were not matching on the cyclic patches.
I changed the decomposition method from single (0 2 16) to single (0 0 32), with z being the streamwise coordinate, and cyclic patches matched perfectly. Also, secondary vortices seemed to be alright.
Conclusions were drawn..

Regards,
Bernhard

Mmmm...I also pay attention do this. So far all my fields appear continious at the cyclic patches.

Just for the record, which version of OpenFoam are you using? I am using 1.7.

Quote:

Originally Posted by BernhardGrieser (Post 284763)

Care has to be taken when running in parallel: Every single processor has to have both corresponding cell sets of a cyclic patch within its computational region. Experience with various geometries has shown that the distribution of 2 "cyclical" cells (cells from different faces but same cyclic patch) into 2 different processor regions results in faulty matching, but the simulation can still be run. Without warning the user, the unwanted matches then obviously produce errors.

mmm... would the preserveFaceZones option in decomposeParDict avoid the problem?

mad

Quote:

Originally Posted by stevenvanharen (Post 285372)

Just for the record, which version of OpenFoam are you using? I am using 1.7.

Me too.

Quote:

Originally Posted by maddalena (Post 285377)

mmm... would the preserveFaceZones option in decomposeParDict avoid the problem?

I'll give it a try, thanks for the hint.

Hi Bernhard,

Did you ever observe strange results using metis decomposition? Could the decomposition method influence this?

By the way, I only used channels and pipes. No complex geometries. But used both hex and polygrids. Could your complexer geometry produce these errors in the decomposition. Did you ever try a simple geometry?

Quote:

Originally Posted by stevenvanharen (Post 285404)

Did you ever observe strange results using metis decomposition? Could the decomposition method influence this?

I don't use metis because I'm not familiar with its implementation. I tried it once on a fairly simple geometry without cyclic patches, but the simulation ran quite slow compared to simple, so I didn't see the necessity to deal with it further on.

Steven, since you're using metis, can you explain to me how it decomposes geometries?

Quote:

Originally Posted by stevenvanharen (Post 285404)

By the way, I only used channels and pipes. No complex geometries. But used both hex and polygrids. Could your complexer geometry produce these errors in the decomposition. Did you ever try a simple geometry?

I only used hex grids so far. Although I have run simple geometries with cyclic patches once, I don't remember the decomposition setup. I'll have a look in my old case files.

Actually, I have no idea. What I have read about it is that it minimizes the faces at processor boundaries. But that is basically all I know.

It was standard practice to use this in the company where I work now when I arrived. I never looked into the different decomposition methods.

I found an answer to my question no. 3 in OpenFOAM Wiki:

http://openfoamwiki.net/index.php/Write_OpenFOAM_meshes

Quote:

cyclics:
should be ordered such that face 'i' is coupled to face 'i + size()/2' where size() is the number of faces of the patch. Additionally the 0th point of a face is considered coupled to the 0th point of its coupled face.

This means one is indeed able to include more than one face pair into one cyclic patch. But not pairwise in sequence.

Example:

face0-1 are neighbouring faces on one side of the channel, face2-3 on the other side. Linking face0 to face2 and face1 to face3 results in the following definition order in blockMeshDict:

cyclic Wall
(
face0 // to be matched with face2
face1 // to be matched with face3
face2
face3
)

Ok, so we can conclude that there will be no problems if we use only two faces for a cyclic patch?

Quote:

Originally Posted by stevenvanharen (Post 286170)

Ok, so we can conclude that there will be no problems if we use only two faces for a cyclic patch?

Unfortunately that's not the only restriction that can be excerpted from the previous post. Additionally your first points, when declaring faces, have to be matching points as well.

Example of a correct declaration:

cyclic nameOfPatch
(
(P1a P2a P3a P4a)
(P1b P4b P3b P2b) // order reversed (right hand rule)
)

But... there's still more restrictions that apply to a successful mapping of cyclic face pairs:

I played around with cyclic patch formations in the last few days and found out that graded cells along any edge of the cyclic patch (when pairs do not belong to the same block) return error messages when compiling with blockMesh, even if the previous rules were respected. You can run them with the cyclic debug flag set. Paraview is able to display the resulting files.

(How to run the cyclic debug flag set? Go to your installation folder of OF and look for the blockMesh file in the /etc folder. Change the file mode as a root to write access, open it and search for "cyclic". It's currently set to 0, so switch to 1 and save.)

Instead of trusting solely on blockMesh, I recommend the following procedure (which worked perfectly for all tested geometries):

Design your geometry as usual. When it comes to defining patches, create temporary patches of type "patch" for each side you want to "cycle" later. Say we have a channel where we want to map the left to the right side. Each side consists of 3 faces with different gradings and cell numbers on the edges. So theres a "top", "middle" and "bottom" face on each side. There's 2 temporary patches to be created now:

patch left_temp
(
(TL1 TL2 TL3 TL4) // left top face
(ML1 ML2 ML3 ML4) // left middle face
(BL1 BL2 BL3 BL4) // left bottom face
)

patch right_temp
(
(TR1 TR4 TR3 TR2) // right top face, pay attention to the order of points
(MR1 MR4 MR3 MR2) // right middle face (right hand rule)
(BR1 BR4 BR3 BR2) // right bottom face (right hand rule)
)

(The point numbers identify corresponding points, so TL1 will be matched with TR1 later etc. )

After running blockMesh, you copy a file called "createPatchDict" into your /system directory. It has the following content (just copy & paste):

matchTolerance 1E-5;

pointSync true;

patchInfo
(
{
name cyclicpatch;
dictionary
{
type cyclic;
}
constructFrom patches;
patches ( "left_temp" "right_temp" );
}
);

Now run "createPatch" in your terminal. This will take the temporary patches and map them into one cyclic patch called "cyclicpatch", which you can find in the /constant/polyMesh/boundary file. If you run "checkMesh" afterwards with activated cyclic debug flag set, you can even check if your matching vectors are correctly displayed in Paraview.

Long story short: It's complicated, but yes, it works :-)

Regards,
Bernhard

Hi

I am experiencing problems using RSTM turbulence model to compute the flow in a section of an annular combustor, bounded by cyclic patches.

The solver seams to diverge when computing Ryy or Ryz components in the cyclic patch, and there's the reason why I posted this here.

Does anybody knows any problem concerning RSTM models and cyclic BCs? With other RANS models and even LES it seems to work fine.

Thx
Jose

Quote:

Originally Posted by Marta (Post 238943)

Hi AirS,
I don't think that is a problem for your simulation, because uniform 0 is just the initial value used, but during the simulation the boundary condition will be a traditional cyclic.
To be sure that there is no difference in the final solution, you can perform a simple test:
use the traditional cyclic boundary condition with and without the 'value uniform 0' specification, then see if the result changes.

Anyway I used these specifications for my new cyclic boundary condition for velocity and everything worked correctly:

type spongeCyclic;
patchType cyclic;
value uniform (0 0 0);

Hope this helps!

Marta

Dear Marta,

Could you sent me your new spongeCyclic BC? I also met the problem that I find that cyclic patches can not accept other BCs. I want to set 0/zeroGradient for the cyclic inlet/outlet patches.

Many thanks,
Jian
zhongjian6739@gmail.com