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:

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.

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.

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.

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?

I would need to understand much better what you are trying to do and what kind of results you expect to see.

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

Quote:

Originally Posted by hjasak

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

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;
}

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.

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

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.

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

Quote:

Originally Posted by braennstroem

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;
}

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.

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

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.