[ajonuz]

Hi Bruno,

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.

I quite don't understand why a rotation around the x-axis isn't possible? Since for me it looks like the only logic rotation to make the flow physical. ('Correct' velocity profile as sketch in the previous attachement).

If I perform a translation the velocity profile would not be correct, hence a wrong solution will be obtained.

So I tried rotating the outlet flow around the x-axis, and the thing I notice when createPatch is executed, is that I get the following message:

Cannot find point in pts1 matching point 60 coord:(0.01212 0.00500556 0) in pts0 when using tolerance 5.00031e-08
Searching started from:149 in pts1
    Compared coord: (0 0.00699167 0) at index 149 with difference to point 0.0122817
Cannot find point in pts1 matching point 61 coord:(0.01212 0.00501667 0) in pts0 when using tolerance 5.00031e-08
Searching started from:149 in pts1
    Compared coord: (0 0.00699167 0) at index 149 with difference to point 0.0122799
Cannot find point in pts1 matching point 62 coord:(0.01212 0.00502778 0) in pts0 when using tolerance 5.00031e-08
Searching started from:149 in pts1
    Compared coord: (0 0.00699167 0) at index 149 with difference to point 0.0122781
Cannot find point in pts1 matching point 63 coord:(0.01212 0.00503889 0) in pts0 when using tolerance 5.00031e-08
Searching started from:149 in pts1
    Compared coord: (0 0.00699167 0) at index 149 with difference to point 0.0122763
Cannot find point in pts1 matching point 64 coord:(0.01212 0.00505 0) in pts0 when using tolerance 5.00031e-08
Searching started from:149 in pts1

I'm still able to carry out the simulation and convergence is reached after 4108 iterations as shown on the residual plot attached. However the final results are still not satisfying. I suspect that the warnings above can have a impact on the result.

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.

Finally I have also tried using cyclicAMI with a rotation, but when rotating around the x-axis I get the warning:

AMI: Creating addressing and weights between 150 source faces and 150 target faces
--> FOAM Warning : 
    From function AMIMethod<SourcePatch, TargetPatch>::checkPatches()
    in file lnInclude/AMIMethod.C at line 57
    Source and target patch bounding boxes are not similar
    source box span     : (0 0.002 0.001)
    target box span     : (0 0.002 0.001)
    source box          : (0 0 -0.0005) (0 0.002 0.0005)
    target box          : (0.01212 0 -0.0005) (0.01212 0.002 0.0005)
    inflated target box : (0.0120082 -0.000111803 -0.000611803) (0.0122318 0.0021118 0.000611803)

--> FOAM FATAL ERROR: 
Unable to find initial target face

How is the initial target face set?

Best regards
Admir

[wyldckat]

Hi Admir,

Originally Posted by ajonuz

I quite don't understand why a rotation around the x-axis isn't possible?

Mmm... OK, now I'm getting the idea, although... well, the problem is that the transformation is meant to be used for transforming the position of one patch onto the position of the other patch. That is why I had defined this transformation:

rotationAxis (0 0 1);
rotationCentre (6.06e-3 3.5e-3 0);

Simply rotating around the x-axis results in the patch overlaying itself.

If I understand your idea correctly, what you want is to rotate over X for switching over the geometrical perspective; but you will also need the translation that will move the position from one side to the other, so that the positions are transformed onto the same locations on the other patch. Problem is that such a two or more steps transformation is not possible with the current capabilities that OpenFOAM provides for cyclic patches.

As far as I can figure out, there are at least three possible solutions that come to mind:

1. To use groovyBC for mapping the values from one patch onto the other... although I've never done something like this, i.e. something that requires such a transformation. Either way, an example along these lines is provided here: http://openfoamwiki.net/index.php/Co...ing_of_patches
2. To implement a new class that uses a generic transformation, preferably using a single 4x4 transformation matrix, which has the ability to cumulatively handle several transformations in a single matrix. This should actually already exist in OpenFOAM, but I guess it doesn't exist yet because it's not very practical...
3. There is a group of boundary conditions with the prefix "mapped", problem is that I've never managed to use them properly. But they are meant to be able to map values from patch onto another. You can find some more information from here:
   • http://foam.sourceforge.net/docs/cpp/
     • Use the link "Boundary Conditions" at the bottom of the page.
       • Use the link "Coupled boundary Conditions".
         • The following two might do what you want: "mappedFieldFvPatchField" and "mappedFixedValueFvPatchField".

And I guess that the "cyclicAMI" is useless for your case, given that a 2 step transformation is needed, which isn't available.

Best regards,
Bruno