# Cyclic boundary conditions rotated 180 deg

 Register Blogs Members List Search Today's Posts Mark Forums Read

September 7, 2015, 12:37
Cyclic boundary conditions rotated 180 deg
#1
New Member

Nikolai Tauber
Join Date: Sep 2015
Location: Aarhus, Denmark
Posts: 14
Rep Power: 9
Dear all,

I am trying to reduce my existing domain with with cyclic boundaries even further by halving it. I have attached both the working whole unit cell, and a mesh of the half. As it is now, i use fixedJump bc on the pressure to drive the flow:

outlet
{
type fixedJump;
patchType cyclic;
jump uniform 5;
value \$internalField;
}

inlet
{
type fixedJump;
patchType cyclic;
value \$internalField;
}

My problem is, that on the half unit cell, the cyclic boundaries have to be rotated 180 deg. Is this possible?
Attached Images
 Unit cell.jpg (122.7 KB, 150 views) Half unit cell.jpg (129.0 KB, 92 views)

 September 8, 2015, 06:22 I may have to use createPatchDict? #2 New Member   Nikolai Tauber Join Date: Sep 2015 Location: Aarhus, Denmark Posts: 14 Rep Power: 9 I have been doing some research, and found that I may have to use createPatchDict. First I define the boundaries in blockMeshDict: Code: ```boundary ( inlet { type patch; faces ( (0 14 25 11) (11 10 24 25) ); } outlet { type patch; faces ( (6 5 19 20) (5 4 18 19) ); }``` Then I set up createPatchDict and try rotating around the x-axis at y = 0.0035 (The domain has height 0.007) Code: ```pointSync false; patches ( { name rotatedInlet; patchInfo { type cyclic; neighbourPatch rotatedOutlet; transform rotational; rotationAxis (1 0 0); rotationCentre (0 0.0035 0); rotationAngle 180; } constructFrom patches; patches (inlet); } { name rotatedOutlet; // Dictionary to construct new patch from patchInfo { type cyclic; neighbourPatch rotatedInlet; transform rotational; rotationAxis (1 0 0); rotationCentre (0 0.0035 0); rotationAngle 180; } constructFrom patches; patches (outlet); } );``` Then I run blockMesh and createPatch, but i get the error: Code: ```Moving faces from patch inlet to patch 7 Moving faces from patch outlet to patch 8 Doing topology modification to order faces. Cannot find point in pts1 matching point 10 coord:(0.01212 0.00501223 0) in pts0 when using tolerance 5.0015e-08 Searching started from:19 in pts1 Compared coord: (0 0.00695 0) at index 19 with difference to point 0.0122739 Cannot find point in pts1 matching point 11 coord:(0.01212 0.00504027 0) in pts0 when using tolerance 5.0025e-08 Searching started from:19 in pts1 Compared coord: (0 0.00695 0) at index 19 with difference to point 0.0122695 Cannot find point in pts1 matc..........``` and Code: ```--> FOAM FATAL ERROR: face 10 area does not match neighbour by 163.636% -- possible face ordering problem. patch:rotatedInlet my area:2.44681e-07 neighbour area:2.44681e-08 matching tolerance:0.0001 Mesh face:5660 fc:(0 0.00112234 0) Neighbour fc:(0.01212 0.00501223 0) 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.``` Any suggestions are appreciated.

 September 8, 2015, 06:57 #3 New Member   Rodrigo Join Date: Jul 2015 Posts: 18 Rep Power: 9 Dude, Good day! I dont know if I got your question. Anyway, if you want to halve it, why don't you define just a symmetry boundary condition and then you don't need to solve all the geometry. Even though from your picture it doens't look like really simmetric. Probably I didn't help you... Rodrigo Correa

September 8, 2015, 07:17
#4
New Member

Nikolai Tauber
Join Date: Sep 2015
Location: Aarhus, Denmark
Posts: 14
Rep Power: 9
I see now, that I have not been thorough enough with my problem description. It's my first post, so please bear with me. I am trying to simulate the flow through a staggered tube bank heat exchanger and want to reduce the domain to as little as possible. Inlet (to the left) and outlet (to the right) are neighbouring patches. I have made a sketch. Please se attachment.
Attached Images
 Screen Shot 2015-09-08 at 12.17.24.jpg (86.6 KB, 98 views)

 September 8, 2015, 07:42 #5 New Member   Rodrigo Join Date: Jul 2015 Posts: 18 Rep Power: 9 Nice Sketch! I was wondering if you could use symmetry rather than cyclic patch as you will use it for repeated geometries. As I've never calculated heat exchanger I don't know if it works. I hope someone will solve your question! Best Regards, Rodrigo Correa

 September 8, 2015, 08:12 #6 New Member   Nikolai Tauber Join Date: Sep 2015 Location: Aarhus, Denmark Posts: 14 Rep Power: 9 Thanks for your reply, but I need to have cyclic boundaries on inlet/outlet for a fully developed flow. It's still only working with the first whole unit cell, but not the half.

 September 9, 2015, 08:26 #7 New Member   Join Date: Aug 2015 Posts: 17 Rep Power: 9 Hi Niko, Im working on a similar problem, trying to flip my flow 180deg at the outlet (shown on attached picture) with cyclicAMI boundary conditions on the inlet and outlet. The cyclicAMI patchType is set in my blockMeshDict file and all 0 files. I apply the rotation in my blockMeshDict as following: outlet { pointSync true; type cyclicAMI; neighbourPatch rotatedInlet; type patch; faces ( (6 5 19 20) (5 4 18 19) ); transform rotational; rotationAxis (1 0 0); rotationCentre (0 0.006 0); rotationAngle 180; matchTolerance 1e-4; } inlet { pointSync true; type cyclicAMI; neighbourPatch rotatedOutlet; type patch; faces ( (0 11 25 14) (11 10 24 25) ); transform rotational; rotationAxis (1 0 0); rotationCentre (0 0.006 0); rotationAngle -180; matchTolerance 1e-4; } Unfortunately when I run the case i get an error "Unable to find initial target face" which I do not know how to solve. The error also occurs if I use a createPatchDict file to create the rotation separately of the blockMeshDict file... Maybe you have experienced similar problem and resolved it? Hope you or others can help! Best regards Admir

 September 11, 2015, 05:25 createPatchDict does not read the rotationAngle #8 New Member   Join Date: Aug 2015 Posts: 17 Rep Power: 9 Dear all, I have experienced some rather strange actions when I use the createPatchDict file. I'm applying cyclic BC on my inlet and outlet with different rotational angles on each surface. However I have my doubts that it reads the rotational angle at all, since I have tried just writing: rotationalAngle ; (without applying any angle) and it still executes the createPatch utility? Is this a bug in the createPatchDict or does it read a default angle value?? Code: ```pointSync false; patches ( { name rotatedInlet; patchInfo { type cyclic; neighbourPatch rotatedOutlet; transform rotational; rotationAngle 0; rotationAxis (1 0 0); rotationCentre (0 0.001 0); matchTolerance 0.1; } constructFrom patches; patches (inlet); } { name rotatedOutlet; // Dictionary to construct new patch from patchInfo { type cyclic; neighbourPatch rotatedInlet; transform rotational; rotationAngle 180; rotationAxis (1 0 0); rotationCentre (0 0.006 0); matchTolerance 0.1; } constructFrom patches; patches (outlet); } );``` Best regards Admir

September 11, 2015, 12:22
#9
New Member

Join Date: Aug 2015
Posts: 17
Rep Power: 9
Additionally I did another test with the createPatchDict. Attached are three pictures with the following procedure:

1. I created my mesh using blockMesh and did a checkMesh
2. I executed the command createPatchDict with the code in the #1 post
3. I did a checkMesh and got 2 failed mesh as shown below

Code:
```Checking geometry...
Overall domain bounding box (-9.18455e-19 0 -0.000139962) (0.01212 0.007 0.000139962)
Mesh (non-empty, non-wedge) directions (1 1 0)
Mesh (non-empty) directions (1 1 0)
All edges aligned with or perpendicular to non-empty directions.
Boundary openness (3.41834e-18 8.46726e-18 -1.77491e-18) OK.
Max cell openness = 1.83457e-16 OK.
Max aspect ratio = 1.69197 OK.
Minimum face area = 1.91039e-08. Maximum face area = 9.14739e-08.  Face area magnitudes OK.
Min volume = 5.34765e-12. Max volume = 1.76239e-11.  Total volume = 1.27593e-08.  Cell volumes OK.
Mesh non-orthogonality Max: 164.09 average: 9.35083
***Number of non-orthogonality errors: 20.
<<Writing 20 non-orthogonal faces to set nonOrthoFaces
Face pyramids OK.
Max skewness = 0.921354 OK.
**Error in coupled point location: 10 faces have their 0th or consecutive vertex not opposite their coupled equivalent. Average mismatch 0.
<<Writing 10 faces with incorrectly matched 0th (or consecutive) vertex to set coupledFaces

Failed 2 mesh checks.```
Why do the nonOrthoFaces and coupledFaces appear when I perform a createPatch?

A visualisation are also attached on the last picture.

Suggestions are much appreciated!

Attached Images
 meshCheck after executing blockMesh.jpg (115.7 KB, 28 views) executing createPatch.jpg (209.1 KB, 28 views) nonOrthoFaces and coupledFaces.png (70.1 KB, 55 views)

 September 12, 2015, 15:16 #10 Retired Super Moderator   Bruno Santos Join Date: Mar 2009 Location: Lisbon, Portugal Posts: 10,969 Blog Entries: 45 Rep Power: 126 Greetings to all! Since Admir sent me a PM, I came to check the posts on this topic. At least with OpenFOAM 2.3 and 2.4, there are a few "issues" with irregular transformations, because:checkMesh doesn't know how to interpret them, which is why Admir got the latest error message: http://www.openfoam.org/mantisbt/view.php?id=1692 The "rotationAngle" entry is completely ignored. I believe this was used in older versions of OpenFOAM and possibly it still is used in foam-extend 3.1 (I haven't checked). Once the transformation selected is "rotational", the algorithm will calculate automatically the angle... at least in theory. This is mostly also why checkMesh gets confused. edit: Forgot to say that Admir's latest dictionary seems to work, at least in theory. Best regards, Bruno __________________ OpenFOAM: FAQ | Getting started Forum: How to get help, to post code/output and forum guide Read this before sending me PM Last edited by wyldckat; September 12, 2015 at 15:16. Reason: see "edit:"

 September 13, 2015, 05:45 #11 New Member   Join Date: Aug 2015 Posts: 17 Rep Power: 9 Dear Bruno, Thank you very much for the reply! Just to sum up what I have tried after I read your comment. 1. I've had a look into some of the extended versions of the cyclic utilities on: http://sourceforge.net/p/openfoam-ex...traint/cyclic/, but it seems like I can not find any sign of the "rotationAngle" use as in the older versions. (Maybe I am looking in a wrong place) 2. Another thing i can not understand is, if I remove the cyclic files from my OpenFOAM dictionary "OpenFOAM-2.3/src/finiteVolume/fields/fvPatchFields/constraint/cyclic/", and still try to create the cyclic boundaries with the createPatch file it has no problem executing the commands. How is this possible? Does the createPatch even read the cyclic utilities? Best regards Admir Jonuz

September 13, 2015, 17:03
#12
Retired Super Moderator

Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,969
Blog Entries: 45
Rep Power: 126
Quote:
 Originally Posted by ajonuz 2. Another thing i can not understand is, if I remove the cyclic files from my OpenFOAM dictionary "OpenFOAM-2.3/src/finiteVolume/fields/fvPatchFields/constraint/cyclic/", and still try to create the cyclic boundaries with the createPatch file it has no problem executing the commands. How is this possible? Does the createPatch even read the cyclic utilities?
Quick answer: Uhm... if you don't run wmake, then any changes in the source code are not built into the binaries. And if you delete files, wmake will very likely not run with success.

 September 13, 2015, 17:58 #13 New Member   Join Date: Aug 2015 Posts: 17 Rep Power: 9 Dear Bruno, I ran the Allwmake file from the dictionary: "OpenFOAM-2.3/src/" and it runs without any problems, even when the cyclic dictionary are not present in "OpenFOAM-2.3/src/finiteVolume/fields/fvPatchFields/constraint/", it seems wrong.. I still can not figure out how I can rotate my velocity profile 180 deg at my outlet, when the rotationAngle are not read at all. Have you maybe had any experience of others resolving this issue? Thank you in advance! Best regards Admir

September 13, 2015, 18:27
#14
Retired Super Moderator

Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,969
Blog Entries: 45
Rep Power: 126
Quote:
 Originally Posted by ajonuz Have you maybe had any experience of others resolving this issue?
Quick answer: I don't remember ever dealing with such a case. And without a test case, there is little anyone can do to help.
__________________

 September 14, 2015, 03:21 #15 New Member   Join Date: Aug 2015 Posts: 17 Rep Power: 9 By test case, do you mean that I attach my files of the case?

September 14, 2015, 18:37
#16
Retired Super Moderator

Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,969
Blog Entries: 45
Rep Power: 126
Quote:
 Originally Posted by ajonuz By test case, do you mean that I attach my files of the case?
Quick answer: Either provide your own case, or provide a simpler test case.
Because setting up a test case also takes time, which I and others on the forum don't have much to spare .

September 15, 2015, 05:22
#17
New Member

Join Date: Aug 2015
Posts: 17
Rep Power: 9
Dear Bruno,

I have now uploaded my case of my half staggered unit cell and a quick sketch of how the blockMesh is carried out. (notice that in blockMesh, I only look on the right half side).

Furthermore, the uploaded case uses simpleFoam as solver with cyclic boundary conditions on inlet and outlet.

As mentioned earlier my problem and challenge now is to flip all outlet field values 180 deg and use them at the inlet. For that I have both tried using createPatchDict to apply the rotation and the blockMesh file. However, I have had no luck solving the problem.

If you find some spare time and manage to solve it/or, I will be so thankful, that I will send you my favorite Danish beer to Portugal. This applies to everybody

Best regards
Attached Files
 150915FlipFlowHalfstaggeredUnitCell.zip (18.5 KB, 9 views) 150902staggeredUnitCellMesh.pdf (159.6 KB, 27 views)

 September 19, 2015, 15:36 #18 Retired Super Moderator   Bruno Santos Join Date: Mar 2009 Location: Lisbon, Portugal Posts: 10,969 Blog Entries: 45 Rep Power: 126 Hi Admir, The correct configuration for "createPatchDict" is as follows: Code: ```pointSync false; patches ( { name rotatedInlet; patchInfo { type cyclic; neighbourPatch rotatedOutlet; transform rotational; rotationAxis (0 0 1); rotationCentre (6.06e-3 3.5e-3 0); //rotationAngle 0; //matchTolerance 0.1; } constructFrom patches; patches (inlet); } { name rotatedOutlet; // Dictionary to construct new patch from patchInfo { type cyclic; neighbourPatch rotatedInlet; transform rotational; rotationAxis (0 0 1); rotationCentre (6.06e-3 3.5e-3 0); //rotationAngle 180; //matchTolerance 0.1; } constructFrom patches; patches (outlet); } );``` Here's what was wrong: In "blockMeshDict", you should not define the patches as "cyclic". Or at least you should have used all of the parameters, as shown above. Anyway, using createPatch does give more details about the creation and seems the more correct way of doing this. "pointSync" should be false. Being "true" resulted in problems when using createPatch. It seems that you disregarded or completely forgot about the real dimensions of your geometry. Notice that the settings above provide the correct rotation axis and rotation centre. The rotation angle isn't needed. The match tolerance wasn't needed, once the correct parameters were given In "run.sh", you should use the "-overwrite" option when using createPatch: Code: `createPatch -overwrite` By the way, checkMesh will complain about some weird things going on with the mesh, after creating the cyclics: Code: ``` *Number of severely non-orthogonal (> 70 degrees) faces: 1. ***Number of non-orthogonality errors: 50. <

September 21, 2015, 04:29
#19
New Member

Join Date: Aug 2015
Posts: 17
Rep Power: 9
Hi Bruno,

Thank you for the feedback! I have had a look into the details you have made in the createPatchDict, however the rotation you are applying around the z axis does not yield the correct solution, since the rotated velocity at the outlet will have a negative direction when applied to the inlet as shown on attached picture.

I tried running the case, and after few iterations i notice that the pressure blows up to extreme negative values. I suspect this is a consequence of the applied rotation. As i have sketched, mass is only leaving the domain and thus continuity is not satisfied.

Have you tried running the case?

My thought of the configuration to the createPatchDict is:
1. Make a rotation of the rotatedOutlet around the x-axis with a rotationcentre (12.12e-3 6e-6 0)
2. Make a translation of the rotatedOutlet from point (12.12e-3 6e-6 0) to the rotatedInlet at point (0 1e-3 0).

But I have had no luck rotating and translating in the createPatchDict. I have attached the updated case as I tried running it.

Best regards
Attached Files
 150921forCDFOnline.pdf (129.1 KB, 21 views) 150915flipFlowHalfstaggeredUnitCell.zip (25.9 KB, 4 views)

September 21, 2015, 14:59
#20
Retired Super Moderator

Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,969
Blog Entries: 45
Rep Power: 126

Quote:
 Originally Posted by ajonuz I have had a look into the details you have made in the createPatchDict, however the rotation you are applying around the z axis does not yield the correct solution, since the rotated velocity at the outlet will have a negative direction when applied to the inlet as shown on attached picture.
Oops... I went along with your objective of rotating 180 degrees and I completely forgot that this rotation would make the flow non-physical.

Quote:
 Originally Posted by ajonuz My thought of the configuration to the createPatchDict is: 1. Make a rotation of the rotatedOutlet around the x-axis with a rotationcentre (12.12e-3 6e-6 0) 2. Make a translation of the rotatedOutlet from point (12.12e-3 6e-6 0) to the rotatedInlet at point (0 1e-3 0).
Technically, the 180 rotation cannot be used, because it will always make the flow non-physical. Either way, only one transformation can be done, i.e. either it's one rotation or one translation.

Technically in this case, only a translation can be used. Which means that:
1. The "cyclic" type cannot be used, because the faces are not identical when the translation is used.
2. Instead the "cyclicAMI" should be used, but the problem with that is that you will loose a bit of numerical precision because of how the flow has to change between different cell resolutions.
Best regards,
Bruno

 Tags cyclic, cyclicami, rotate