[mbecker]

I am using OpenFoam to simulate the waterflow in an axial turbine runner. I constructed a mesh for one blade channel and tried to simulate it using the cyclicGgi interface (OpenFoam 1.5-dev rev. 1238 as suggested by the SIG Turbomachinery).

Unfortunately, I see errors on the cyclic interface. Pressure as well as velocity is discontinous on the interface, that leads to unphysical results with bad convergence.

I'm using the simpleSRFFoam solver, but I also saw the same problems in my wicked gate simulation using simpleFoam.

I attached some pictures and the output of the simulation:
- cyclicGgi_channel.jpg: the four blades and the computational domain. cyclicGgi interfaces are coloured green and red

- cyclicGgi_channel_2.jpg: one side of the interface is rotated onto the other -> surfaces are congruent

- cyclicGgi_channel_problem.jpg: flow calculated with cyclicGgi interface, see the discontinuities at the interface (pressure on cylindrical cut)

- cyclicGgi_360deg.jpg: same case, same boundary conditions, but calculated with 360° mesh (without cyclicGgi) -> very good results (here: pressure on cylindrical cut)

simpleSRFFoam_out.txt: simulation output

My Ggi weighting factors look fine:
Initializing the GGI interpolator between master/shadow patches:
perio1/perio2
Evaluation of GGI weighting factors:
Largest slave weighting factor correction : 3.33067e-16 average:
6.04589e-17
Largest master weighting factor correction: 1.26787e-13 average:
4.43631e-16

Here is my cyclicGgi patch definition in (constant/polymesh/boundary):
perio1
{
type cyclicGgi;
nFaces 4600;
startFace 614376;
shadowPatch perio2;
zone perio1_zone;
bridgeOverlap off;
rotationAxis (0 0 1);
rotationAngle 90;
separationOffset (0 0 0);
}
perio2
{
type cyclicGgi;
nFaces 4600;
startFace 618976;
shadowPatch perio1;
zone perio2_zone;
bridgeOverlap off;
rotationAxis (0 0 1);
rotationAngle 90;
separationOffset (0 0 0);
}


What is the current status of cyclicGgi?
Are the problems I described common ("known bug")?
What about enableGgiNonOrthogonalCorrection? Could that help me?

Any help is greatly appreciated!

Martin

[mbeaudoin]

Hello Martin,

One little clarification is necessary here:

Originally Posted by mbecker

I am using OpenFoam to simulate the waterflow in an axial turbine runner. I constructed a mesh for one blade channel and tried to simulate it using the cyclicGgi interface (OpenFoam 1.5-dev rev. 1238 as suggested by the SIG Turbomachinery).

The recommendation to stick to revision 1238 is uniquely related to the ERCOFTAC Centrifugal Pump test case published on the Wiki, and the usage of MRFSimpleFoam.

This has nothing to do with the GGI, and you should upgrade your 1.5-dev installation to the latest 1.5-dev release available in order to get the best GGI implementation available.

The problem lies with MRFSimpleFoam that basically stopped working for the ECP test case when we upgraded to a version newer that rev. 1238.

My group is working on a different MFR implementation. See here for a little sneak peek preview:
http://openfoamwiki.net/index.php/Si...leTurboMFRFoam

We hope to release simpleTurboMFRFoam in a near future.

Regards,

Martin

[NickG]

Hi Martin

Is this the case with turbDyMFoam as I have a similar problem where the fluid does not cross the interface

Regards

Nick

[kurne]

Dear All
Will anyone please tell me whether the GGI is available with the OpenFOAM 1.7.1 or not.Also the simpleTurboMRFFoam will be Run with the OpenFOAM 1.7.1 or not.

[claco]

Originally Posted by mbecker

I am using OpenFoam to simulate the waterflow in an axial turbine runner. I constructed a mesh for one blade channel and tried to simulate it using the cyclicGgi interface (OpenFoam 1.5-dev rev. 1238 as suggested by the SIG Turbomachinery).

Unfortunately, I see errors on the cyclic interface. Pressure as well as velocity is discontinous on the interface, that leads to unphysical results with bad convergence.

I'm using the simpleSRFFoam solver, but I also saw the same problems in my wicked gate simulation using simpleFoam.

I attached some pictures and the output of the simulation:
- cyclicGgi_channel.jpg: the four blades and the computational domain. cyclicGgi interfaces are coloured green and red

- cyclicGgi_channel_2.jpg: one side of the interface is rotated onto the other -> surfaces are congruent

- cyclicGgi_channel_problem.jpg: flow calculated with cyclicGgi interface, see the discontinuities at the interface (pressure on cylindrical cut)

- cyclicGgi_360deg.jpg: same case, same boundary conditions, but calculated with 360° mesh (without cyclicGgi) -> very good results (here: pressure on cylindrical cut)

simpleSRFFoam_out.txt: simulation output

My Ggi weighting factors look fine:
Initializing the GGI interpolator between master/shadow patches:
perio1/perio2
Evaluation of GGI weighting factors:
Largest slave weighting factor correction : 3.33067e-16 average:
6.04589e-17
Largest master weighting factor correction: 1.26787e-13 average:
4.43631e-16

Here is my cyclicGgi patch definition in (constant/polymesh/boundary):
perio1
{
type cyclicGgi;
nFaces 4600;
startFace 614376;
shadowPatch perio2;
zone perio1_zone;
bridgeOverlap off;
rotationAxis (0 0 1);
rotationAngle 90;
separationOffset (0 0 0);
}
perio2
{
type cyclicGgi;
nFaces 4600;
startFace 618976;
shadowPatch perio1;
zone perio2_zone;
bridgeOverlap off;
rotationAxis (0 0 1);
rotationAngle 90;
separationOffset (0 0 0);
}


What is the current status of cyclicGgi?
Are the problems I described common ("known bug")?
What about enableGgiNonOrthogonalCorrection? Could that help me?

Any help is greatly appreciated!

Martin

Dear Martin,

I am investigating a case similar to Yours, that is a blade channel of a radial pump with seven blades.
So I have to use cyclicGgi patches (together with some ggi between the
rotor and the stator part).
I use the 1.5-dev version.


The problem is that when I decompose my case, the following error
occurs.



/*---------------------------------------------------------------------------*\
| ========= |
|
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox
|
| \\ / O peration | Version: 1.5-dev
|
| \\ / A nd | Revision: 1861
|
| \\/ M anipulation | Web: http://www.OpenFOAM.org
|
\*---------------------------------------------------------------------------*/
Exec : decomposePar
Date : Feb 25 2011
Time : 16:20:37
Host : claudio-laptop
PID : 6163
Case : /root/OpenFOAM/root-1.5-dev/run/pompa
nProcs : 1

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * //
Create time

Time = 0
Create mesh for region region0

Calculating distribution of cells
Selecting decompositionMethod simple

Finished decomposition in 0.02 s

Calculating original mesh data

Distributing cells to processors

Distributing faces to processors
Preserving global face zone Per2Zone
Preserving global face zone Per1Zone
Preserving global face zone OutInter2Zone
Preserving global face zone OutInter1Zone
Preserving global face zone InInter2Zone
Preserving global face zone InInter1Zone

Calculating processor boundary addressing

Distributing points to processors

Constructing processor meshes
Segmentation fault


I run the setSet -batch setBatch and setsToZones -noFlipMap
applications before decomposing the domain, and they work properly.

The case runs in serial mode, so there aren't macro problems as regards the settings.


Could You kindly help me to understand the reason for this problem?

Thank You in advance.


Claudio


P.S.: Does the cyclicGGi b.c.,( nowaday, in Your opinion) work properly or not?

[mbecker]

Dear Claudio,

as far as I can see from your text, your procedure looks OK. You can be sure that cyclicGgi works as it should.
Your segmentation fault can have various reasons. Did you try to debug it?

Maybe it is useful to post more details of your case (boundary file etc.).
Did you try another version of OpenFoam as well (e.g. 1.6-ext)?

Martin