CFD Online Discussion Forums - Cyclic bc. and overlapGgi

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

- OpenFOAM (https://www.cfd-online.com/Forums/openfoam/)

- - Cyclic bc. and overlapGgi (https://www.cfd-online.com/Forums/openfoam/81244-cyclic-bc-overlapggi.html)

Cyclic bc. and overlapGgi

Hi Foamers,

I have troubles with the cyclic boundary conditions and overlapGgi interfaces. In my case the rotor stator pair is with a different pitch (rotor slice is 5 degrees and stator 6 degrees). The cyclic boundary conditions work when the rotor and the stator is in the same line i.e so that both sides of the rotor stator interface is 0.5 degrees overlaps, but then overlapGgi does not work. When I rotate the rotor 0.5 degrees so that the other side of the rotors and the stators cyclic patches are in the same plane and the overlap is only on the other side then the overlapGgi works but the cyclic boundary conditions do not. The rotor cyclic bc. gives the error:

face 1319 area does not match neighbour 2679 by 0.163395% -- possible face ordering problem.
...

I run tests so that i change cyclic bc. to symmetry bc. on the rotor sides and the overlapGgi works. The rotor stator pair is made by mergeMeshes command, the pure rotor model works with cyclic bc. even if is it rotated.

Is it the same kind of limitations on the overlapGgi interfaces? I mean that it is not possible put the other interfaces pair in arbitrary position. How about cyclic bc, is it some kind of accuracy problem or what?

Thank you in advance.

I have just uploaded a nice movie showing what overlapGGI can do - thanks due to Oliver Borm of TU Munich:

http://powerlab.fsb.hr/ped/kturbo/Op...lapChannel.mpg

Enjoy,

Hrv

Hi Hrvoje

Looks awesome :-)

will it be possible to get hold of this case (other case) showing how to use the features of overlapGGI?

Best

Hi Hrvoje,

Thanks a lot for the reply, the video is nice and I trust that overlapGgi works.

Unfortunately I cannot find an answer to the problem why the overlapGgi interface doesn't work in the situation when the rotor and the stator is on the same line. When I try to run simleFoam or MRFSimpleFoam the pressure solver gives “Floating point exception” error.

Code:

Create time



Create mesh for time = 0



Reading field p



Initializing the GGI interpolator between master/shadow patches: interface_st/interface_rt

Number of slave copies: 2

Evaluation of GGI weighting factors:



    From function void GGIInterpolation<MasterPatch, SlavePatch>::rescaleWeightingFactors() const

    in file /home/Pekka/OpenFOAM/OpenFOAM-1.5-dev/src/OpenFOAM/lnInclude/GGIInterpolationWeights.C at line 534

    Uncovered faces found.  On master: 30 on slave: 360

  Largest slave weighting factor correction : 0.0705433 average: 0.000882577

  Largest master weighting factor correction: 0.606291 average: 0.015158



Reading field U



Reading/calculating face flux field phi



Selecting incompressible transport model Newtonian

Selecting RAS turbulence model kEpsilon

kEpsilonCoeffs

{

    Cmu             0.09;

    C1              1.44;

    C2              1.92;

    alphaEps        0.76923;

}





MRFZone movingCells : did not find a faceZone; using 52300 faces from the cellZone instead.



Starting time loop



Creating ggi check

Time = 0.001



smoothSolver:  Solving for Ux, Initial residual = 1, Final residual = 0.0199075, No Iterations 2

smoothSolver:  Solving for Uy, Initial residual = 1, Final residual = 6.55461e-05, No Iterations 2

smoothSolver:  Solving for Uz, Initial residual = 1, Final residual = 0.00296884, No Iterations 2

Floating point exception

And respectively by dynamic mesh solver for example IcoDyMSimpleFoam it gives the following error:

Code:



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

Create time



Create dynamic mesh for time = 0



Selecting dynamicFvMesh mixerGgiFvMesh

void mixerGgiFvMesh::addZonesAndModifiers() : Zones and modifiers already present.  Skipping.

Mixer mesh:

    origin: (0 0 0)

    axis  : (0 0 1)

    rpm   : 954.93

Reading transportProperties



Reading field p



Initializing the GGI interpolator between master/shadow patches: interface_st/interface_rt

Number of slave copies: 2

Evaluation of GGI weighting factors:



    From function void GGIInterpolation<MasterPatch, SlavePatch>::rescaleWeightingFactors() const

    in file /home/Pekka/OpenFOAM/OpenFOAM-1.5-dev/src/OpenFOAM/lnInclude/GGIInterpolationWeights.C at line 534

    Uncovered faces found.  On master: 30 on slave: 360

  Largest slave weighting factor correction : 0.0705433 average: 0.000882577

  Largest master weighting factor correction: 0.606291 average: 0.015158



Reading field U



Reading/calculating face flux field phi





Starting time loop



Volume: new = 4.49822e-05 old = 4.49822e-05 change = 0

Courant Number mean: 0.0975777 max: 3.99953 velocity magnitude: 4.99976

deltaT = 0.000125015

--> FOAM Warning : 

    From function dlLibraryTable::open(const dictionary& dict, const word& libsEntry, const TablePtr tablePtr)

    in file lnInclude/dlLibraryTableTemplates.C at line 68

    library "libsampling.so" did not introduce any new entries



Creating ggi check

Time = 0.000125015







Attempt to cast type overlapGgi to type ggi



    From function refCast<To>(From&)

    in file /home/Pekka/OpenFOAM/OpenFOAM-1.5-dev/src/OpenFOAM/lnInclude/typeInfo.H at line 106.



FOAM aborting

How is the angle defined on boundary file? Is it a sector angle of the model or?

In the attachment is a model of the rotor stator pair. It is possible to rotate the rotor 0.5 degrees when uncomment line 35 on the “create_rt_st_pair.sh” file and run it on the stator director. On rotated rotor overlapGgi works but rotor cyclic bc. must be changed to for example symmetry bc. I am very grateful for all comments and tips.

Thanks again.

BR/Pekka

Cyclic patch problem

Dear Foamers,

Continuing rotor stator pair practice is founded some interesting noticed.

First: The surfaceNormalFixedValue boundary condition on the inflow velocity seem to give velocity always in the same direction despite mesh rotation. I tested the bc by printing mass flow on inflow boundary conditions a function of time. In the starting point ( t=0 s) the mass flow is -0.001 and when the rotor is rotated 90 degrees the mass flow is 0 and when it rotates 180 degrees (t=0.03 s) mass flow in 0.001 so in the opposite direction. We can see this in the attached graph. It's seems that the inflow direction does not change even if the direction of patch normal change.

Is there any possibility to set the velocity boundary conditions to the moving patch?

Second: Cyclic boundary conditions still causing pain in the ass. Cyclic boundary conditions does not work if the rotor is rotated to a different angle than the stator. Rotor cyclic bc works fine when CFD model have only rotor and pure rotor is possible rotate arbitrary position. Problems start when model consists of more than one region and the different regions of the cyclic boundaries are not in the same plane. Following error occurred:

Code:

face 24 area does not match neighbour 234 by 0.181011% -- possible face ordering problem.

patch:PER_rt my area:2.9249e-07 neighbour area:2.9302e-07 matching tolerance:0.001

Mesh face:26250 vertices:4((0.0122268 0.35013 0.00314778) (0.0122268 0.35013 0.004) (0.0122148 0.349787 0.004) (0.0122148 0.349787 0.00314778))

Neighbour face:26460 vertices:4((-0.0244387 0.34949 0.00314778) (-0.0244148 0.349147 0.00314778) (-0.0244148 0.349147 0.004) (-0.0244387 0.34949 0.004))

Other errors also exist, only the largest is reported. Please rerun with cyclic debug flag set for more information.



    From function cyclicPolyPatch::calcTransforms()

    in file meshes/polyMesh/polyPatches/constraint/cyclic/cyclicPolyPatch.C at line 197.

In the attached model it is possible to run with the OF 1.5-dev version by using MRFSimpleFoam or turbDyMFoam solvers. The rotor initial position can be adjusted by angle on line 32 on the Allrun script. If someone finds mistakes or something else wrong what I have done, I would be very pleased if you could tell me.

BR/Pekka

I have fixed the b.c. - all updates will follow in 1.6-ext

uncovered faces and two cars passing by each other

Quote:

Originally Posted by hjasak (Post 283897)

I have fixed the b.c. - all updates will follow in 1.6-ext

hello, Hrv,
Could you please read my post and help me out?
http://www.cfd-online.com/Forums/ope...tml#post341060
I am not sure about which kind of boundary condition I should use. in the totorial case turboPassengeRotating, the geometry boundary is the blade, which then is defined as "movingwall".
but for my case, the geometry boundary is just only AIR, my car(cube) is inside the outer geometry.
So I really feel confused what kind of boundary conditions i should use in p and u for the geometry boundary, in the purple circle of the attached picture.

Thank you so much!!
Aqua

hello， pekka，
Did you solve the problem as "face 391 area does not match neighbour 791 by 0.0136179% -- possible face ordering problem."?
I have been struggling for a long time for this, but no results..
Plus, I use blockMesh then snappyHexMesh to creat my mesh.
Thank you so much!
Aqua

Hi,

Unfortunately I can not solve cyclic problem, I thinks that is "hard coded" to older OF's. Have you ggi or overlapGgi on the interface patches? Can you send model maybe is easier find errors.

BR/Pekka

Quote:

Originally Posted by Pekka (Post 342294)

Thank you so much for your reply!
Please find attached my mesh:
1. there are two region: iblock, oblock. both blocks contain a cube(stands for a car) inside.
2. iblock and oblock will move towards each other, to simulate the situation of two cars passing by each other.
3. interfaceo and interfacei are setted as overlapGgi.
4 there are also cyclicGgi and cyclic boundary, as you can see in the picture.
5 my problem is, when run creatPatch to set cyclic, the error occurs..

Thank you so much!
and my case is too big (1.11MB) to up load, could you please tell me your email in private message so that i can send to you by email?
Thank you again!
Aqua

Hi,

Firstly try rotate other part (iblock or oblock) so that both meshes are on the same angle.

Useful command is " transformPoints -rotateAlongVector '(0 0 1) 10' " ,where (0 0 1) means the rotation axis and 10 rotation angle.

Second hint: If you know that on the cyclic patch has an equal grid, you can try change the batch type on the boundary file directly to the cyclic.

example:

Code:

    periodic

    {

//        type            symmetryPlane;

        type            cyclic;

        transform       rotational;

        rotationAxis    (0 0 -1);

        rotationCentre  (0 0 0);

        rotationAngle    6;

        nFaces          1120;

        startFace       126830;

 //       featureCos      0.9;

    }

BR/Pekka

hi, Pekka,
Thank you so much for your reply!
I will try that and see whether it will work.
Thank you!
Aqua

Hello Hrv，
About GGI and rotation simulation, may I have questions that:
1. can the rotation center be other points apart from (0 0 0)? In your case "turbopassengeRotating", the rotation center is (0 0 0).
What if my geometry has to rotate around (-1000 0 0) with rotation axis of Z ?

2 How should I define the dynamicMeshDict for my own case?

3 in the file of boundary, how should i define rotationAxis for the GGI patch?

Thank you so much!

Aqua