[niko0807]

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?

[niko0807]

I have been doing some research, and found that I may have to use createPatchDict. First I define the boundaries in blockMeshDict:

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)

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:

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

--> 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.

[Rodrigo Correa]

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

[niko0807]

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.

[Rodrigo Correa]

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

[niko0807]

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.

[ajonuz]

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

[ajonuz]

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??

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

[ajonuz]

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

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!

/Admir

[wyldckat]

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:

1. 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
2. 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).
3. 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

[ajonuz]

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

[wyldckat]

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.

[ajonuz]

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

[wyldckat]

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.

[ajonuz]

By test case, do you mean that I attach my files of the case?

[wyldckat]

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 .

[ajonuz]

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
Admir

[wyldckat]

Hi Admir,

The correct configuration for "createPatchDict" is as follows:

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:

1. 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.
2. "pointSync" should be false. Being "true" resulted in problems when using createPatch.
3. 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.
4. The rotation angle isn't needed.
5. The match tolerance wasn't needed, once the correct parameters were given
6. In "run.sh", you should use the "-overwrite" option when using createPatch:
   

   createPatch -overwrite

By the way, checkMesh will complain about some weird things going on with the mesh, after creating the cyclics:

   *Number of severely non-orthogonal (> 70 degrees) faces: 1.
 ***Number of non-orthogonality errors: 50.
  <<Writing 51 non-orthogonal faces to set nonOrthoFaces
    Face pyramids OK.
 ***Max skewness = 10.6157, 3 highly skew faces detected which may impair the quality of the results
  <<Writing 6 skew faces to set skewFaces
  **Error in coupled point location: 50 faces have their 0th or consecutive vertex not opposite their coupled equivalent. Average mismatch 9.27025e-19.
  <<Writing 50 faces with incorrectly matched 0th (or consecutive) vertex to set coupledFaces

This might seem odd, but this is a bug in checkMesh: http://www.openfoam.org/mantisbt/view.php?id=1692


Best regards,
Bruno

[ajonuz]

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
Admir Jonuz

[wyldckat]

Hi Admir,

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.

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.
   • AMI stands for Arbitrary Mesh Interface: http://www.openfoam.org/version2.1.0/ami.php - which allows for different surface mesh resolutions to communicate via "cyclicAMI".

Best regards,
Bruno