further data
 

Hello Hrvoje,

I am using the movingWallVelocity BC. Let me provide some hard ascii data to be more specific.

When I stopped the GGI run, with the previous dev version, U and phi demonstrated the following:

U
impellerWall
{
type movingWallVelocity;
value nonuniform List<vector>
18488
(
(4.9647339 -5.2771553 -0.0018872856)
(4.7601108 -5.3303373 -0.0020557974)
(4.5670492 -5.3605736 -0.0019166547)
(4.3854936 -5.3684121 -0.0014655788)
(4.2141501 -5.3542863 -0.00090790046)
(4.0513943 -5.3195429 -0.00031373207)
(3.8939149 -5.2681244 0.00025266462)
...

phi
impellerWall
{
type calculated;
value nonuniform List<scalar>
18488
(
-1.6940659e-21
-1.6940659e-21
1.6940659e-21
0
0
0
0
...

So, we have strange non-zero z-velocities (comparatively small however) on the impeller wall, but the mass flux across it is practically zero. Up until now I had no severe problems - except at the very beginning - but then I went ahead and updated the dev version to the current one and the same results, after a very small time step, depict this:

U
impellerWall
{
type movingWallVelocity;
value nonuniform List<vector>
18488
(
(4.9682308 -5.2911397 -2.0632922e-05)
(4.762548 -5.346407 -2.2850246e-05)
(4.5680695 -5.3785635 -1.9691256e-05)
(4.3844853 -5.388396 -1.4211187e-05)
(4.2105156 -5.3759217 -8.5769172e-06)
(4.0448415 -5.3421346 -2.9240217e-06)
(3.8852911 -5.2907393 2.8557031e-06)
...

phi
impellerWall
{
type calculated;
value nonuniform List<scalar>
18488
(
-3.432816e-12
-2.0036404e-11
6.8836892e-11
5.7797203e-11
1.764198e-10
-2.6405148e-11
7.8682583e-11
-1.7541699e-10
...


The velocity values are now little different and the z-components still non-zero (still comparatively small, but a little scrolling revealed values upto 0.012). The problem is the mass flux values, which can no longer be labeled as 'practically zero'. Little scrolling revealed values upto 1.0e-7 which lie in the same ball park with the internal face values. Within this same time step the pressure had gone wild and so far I've been unable to tame it with my trials. This is where I need a second opinion.

Yours,
- mikko

Hallo, foamer,
Can anybody confirm me that turbDyMFoam working on GGI is fully paralleled? I mean whether the movingCells zone can be cut through.
And in which code module is this machenism located? I would just look it through to get a deep feeling.

Regards.

Hai

Skype failed...
 

Did anyone record the conference call? My skype bandwidth was too low to hear anything useful.

Example/Tutorial
 

Dear Foamers,
Is there any example/tutorial case working with the current 1.5-dev version? My old cases don't run anymore and I missed the skype presentation...
Any help much appreciated,
Pal

Hello all,

I missed this tutorial conference, can anyone please point me to some tutorial or examples of how to set GGI run on OF?

Thanks,
-Pablo

Some pdf were mentionned. Is it possibly to gain access to them ?

Hello,

If you want a working case with the GGI and some hints on how to set up a case with a GGI, you can go to the OpenFOAM Wiki, to the turbomachinery wiki page, there is a tutorial on how to set up a case with a GGI in it. To go there, just follow the following link, http://openfoamwiki.net/index.php/Si...vaned_diffuser.

And the tutorials are available on the svn. Just follow the steps written on the wiki page.

Good luck.

Moving part of GGI-mesh cutting a boundary
 

Hello,

allow me to bother you with a question. Before I pose it, please see the attached image

Attachment 1605.
red = static part of the GGI-mesh, blue = moving part of the GGI-mesh, black = boundaryPatch ("wheel"), gray = boundaryPatch ("road").

As you can see the moving part of the mesh is cutting the boundaryPatch ("road").

Can the present GGI implementation (svn-revision 1503 of /src) treat this behavior correctly? (Simulation is run with turbDyMFoam [svn-revision 1197])

Yes, it will work, but I am not sure if this is what you want. Do you want to impose a boundary condition on the exposed part of the rotating mesh below the road or you simply don't care what happens there?

Hrv

What I actually want is to quantitatively compare (especially Cl, besides Cd) an MRF approach and a GGI approach for automotive simulations with turning wheels and moving floor.

On the first shot I did not care about the boundary condidtion on the exposed rotating part but ran into difficulties.

Do you have any recommendation on how to treat this kind of simulations in a proper way?

We are getting too close to answering support questions on an open forum: I would need to understand much better what you are trying to do and what kind of results you expect to see.

Sorry, we should really deal with this directly - I am sure you understand.

Hrv

The goal is to use the GGI approach for automotive simulations with turning wheels and moving floor. Therefore I already ran a siumulation with MRF approach (MRFSimpleFoam) and now wanted to run the same car with GGI approach and compare coefficients. [I know MRFSimpleFoam is steady-state and turbDyMFoam not, but I wanted to give it a try.]

Sure

Hello,

I am trying to use ggi for a noncomformal interface without any motion as an alternative to stitchMesh. I created the two meshes with snappyHexMesh and merged them with mergeMeshes. I set the typ the interfacing boundaries to ggi type with:
GGI_OUT_BLOCK_maxX_1
{
type ggi;
// type patch;
nFaces 6108;
startFace 10116664;
shadowPatch GGI_IN_BLOCK_minX;
zone GGI_OUT_BLOCK_maxX_1_Zone;
bridgeOverlap true;
}

GGI_IN_BLOCK_minX
{
// type patch;
type ggi;
nFaces 5626;
startFace 10991895;
shadowPatch GGI_OUT_BLOCK_maxX_1;
zone GGI_IN_BLOCK_minX_Zone;
bridgeOverlap true;
}

Unfortunately, I get this error, when running with simpleFoam:
--> FOAM Warning :
From function GGIInterpolation<MasterPatch, SlavePatch>::calcAddressing()
in file /opt/OpenFOAM/OpenFOAM-1.5-dev/src/OpenFOAM/lnInclude/GGIInterpolationWeights.C at line 412
polygonIntersection is returning a zero surface area between
Master face: 6092 and Neighbour face: 1197 intersection area = 0
Please check the two quick-check algorithms for GGIInterpolation. Something is missing.

From function void GGIInterpolation<MasterPatch, SlavePatch>::rescaleWeightingFactors() const
in file /opt/OpenFOAM/OpenFOAM-1.5-dev/src/OpenFOAM/lnInclude/GGIInterpolationWeights.C at line 533
Uncovered faces found. On master: 23 on slave: 0
Largest slave weighting factor correction : 0.9994067 average: 0.001887828
Largest master weighting factor correction: 0.9991873 average: 0.00420317

Floating point exception



Somehow, the 'intersection area = 0' is a bit strange to me...
Does anyone have a suggestion, what I am doing wrong!? Both patches should have the the same size (but might vary slightly due to snappyHexMesh).

Regards!
Fabian

Fabian,

it should work but setup is little tricky. Did you create faceZones from patches? Do you run in parallel? If yes did you ensure correct parallelisation (globalFaceZones)? Do the Zones match? Did you check this in Paraview?
Btw. Running it in parallel is quite slow for parallel cases. Are you happy with stitchMesh? I have lots of problems with it.

Regards BastiL

Hello,
based on the ercoftac pump tutorial, I am trying to set a turbine computation but I have few difficulties.
- I would like to simulate only one runner channel (instead of the full 360°), how should I set the GGI parameters (is there any "pitch angle" to specify ?).
I guess that I have 2 cyclicGGI bondary condition, a wall for the blade, what about the interface rotor/stator ?
Here are my BC:
10
(
SP_HIGHP
{
type patch;
nFaces 1017;
startFace 10749226;
}
SP_LOWP // this is the interface stator side (360°)
{
type ggi;
nFaces 17350;
startFace 10750243;
shadowPatch INTERFACEGGI;
bridgeOverlap false;
zone SP_LOWP_ZONE;
}
SP_WALL
{
type wall;
nFaces 143896;
startFace 10767593;
}
STAY
{
type wall;
nFaces 49852;
startFace 10911489;
}
GUIDE
{
type wall;
nFaces 45575;
startFace 10961341;
}
BLADE
{
type wall;
nFaces 24016;
startFace 11006916;
}
INTERFACEGGI // this is the rotor/stator interface - rotor side (51°)
{
type ggi;
nFaces 3136;
startFace 11030932;
shadowPatch SP_LOWP;
bridgeOverlap false;
zone INTERFACEGGI_ZONE;
}
PERIODSIDE1
{
type cyclicGgi;
nFaces 5488;
startFace 11034068;
shadowPatch PERIODSIDE2;
zone PERIODSIDE1_ZONE;
bridgeOverlap false;
rotationAxis (0 0 1);
rotationAngle 51.42857143;
separationOffset (0 0 0);
}
PERIODSIDE2
{
type cyclicGgi;
nFaces 5488;
startFace 11039556;
shadowPatch PERIODSIDE1;
zone PERIODSIDE1_ZONE;
bridgeOverlap false;
rotationAxis (0 0 1);
rotationAngle -51.42857143;
separationOffset (0 0 0);
}
INLET
{
type patch;
nFaces 3360;
startFace 11045044;
}
)

- Secondly, I think I don't totally understand the difference between MRFSimpleFoam and simpleTurboMRFFoam. The first one is frozen-rotor and is the second one what CFX call "stage" ?

Is there any tutorial using simpleTurboMRFFoam or turbDyMFoam ?

Thanks a lot !
Flo

Hello Fabian,

Check your mesh for concave faces on the GGI patches.

The cutting algorithm being used by the actual GGI implementation cannot handle concave faces on the GGI patches.

snappyHexMesh is known to generate mesh with concave faces.

You can check your mesh for the presence of concave faces using checkMesh. But watch out, checkMesh concave angle threshold is 10 degree, so all concave angles from 10 degree and less will not be reported.

You can change this default setting in your main controlDict by changing the tolerance parameter primitiveMeshFaceAngleThreshold.

Martin

Hi Learned Ones

I have a similar problem that works/rotates with icoDyMFoam but gives a floating point error after the first step with turbDyMFoam. I'm using the movingWallVelocity boundary condition in the U file for the blade which I assume is also necessary for the icoDyMFoam to work.

The GGI is working for the icoDyMFoam case so I don't think it's a mesh interface problem.

I've tried reducing the time and changing the number of p correctors enough that I don't get any changes with further iterations but am clueless as to what to try next.

Any suggestions would be gratefully received

Thanks

Nick

This is the output

Initializing the GGI interpolator between master/shadow patches: InterT/InterR
Evaluation of GGI weighting factors:
Largest slave weighting factor correction : 2.85271e-05 average: 2.77807e-06
Largest master weighting factor correction: 4.47993e-05 average: 7.11812e-07

BiCGStab: Solving for Ux, Initial residual = 1, Final residual = 2.71511e-08, No Iterations 7
BiCGStab: Solving for Uy, Initial residual = 1, Final residual = 4.66166e-08, No Iterations 8
BiCGStab: Solving for Uz, Initial residual = 1, Final residual = 4.14282e-09, No Iterations 6
BiCGStab: Solving for p, Initial residual = 1, Final residual = 9.96992e-08, No Iterations 267
BiCGStab: Solving for p, Initial residual = 0.705496, Final residual = 9.4242e-08, No Iterations 211
BiCGStab: Solving for p, Initial residual = 0.0302484, Final residual = 3.65547e-08, No Iterations 199
time step continuity errors : sum local = 9.62158e-14, global = 2.47271e-15, cumulative = 2.47271e-15
BiCGStab: Solving for p, Initial residual = 0.046603, Final residual = 5.78336e-08, No Iterations 206
BiCGStab: Solving for p, Initial residual = 0.00832937, Final residual = 4.69163e-08, No Iterations 147
BiCGStab: Solving for p, Initial residual = 0.000697974, Final residual = 9.73038e-08, No Iterations 78
time step continuity errors : sum local = 2.45325e-13, global = 5.62079e-14, cumulative = 5.86806e-14
BiCGStab: Solving for p, Initial residual = 0.00268834, Final residual = 6.2455e-08, No Iterations 178
BiCGStab: Solving for p, Initial residual = 0.000414399, Final residual = 4.79598e-08, No Iterations 125
BiCGStab: Solving for p, Initial residual = 3.51465e-05, Final residual = 9.8068e-08, No Iterations 34
time step continuity errors : sum local = 2.47464e-13, global = -1.67022e-13, cumulative = -1.08342e-13
BiCGStab: Solving for p, Initial residual = 0.000847403, Final residual = 2.87118e-08, No Iterations 154
BiCGStab: Solving for p, Initial residual = 0.000142032, Final residual = 9.4255e-08, No Iterations 127
BiCGStab: Solving for p, Initial residual = 1.09702e-05, Final residual = 9.90043e-08, No Iterations 20
time step continuity errors : sum local = 2.4977e-13, global = 1.42343e-13, cumulative = 3.40009e-14
Floating point exception


Thanks again

Hey Nick, could you upload your case file so we could have a look at what you're trying to simulate?

Hi James

These are the case files less the mesh which was too big to upload with this lot. If you need it just say. I've got about three iterations running now before a floating point error again.

Thanks Nick