usage of overlapGgi in 1.5-dev
 

Hi everybody,

I am setting up a case trying to use to overlapGgi Patch as a basic rotor/stator interface. There are no error messages in the GGI-checks, but I get a "Floating point exception" when solving the h-equation in the first iteration, when trying to run the case.

This does not happen, when I compute just the separate parts of the cases, meaning without the overlapGgi-patch. Therefore I believe the error lies in the interface.

Does anybody have any experience with the overlapGgi patch? There is not tutorial using it and there is not much of explanation in the doxygen either. For example, it requires the "angle"-keyword, but I couldnt find any explanation what this means. I assumed it meaning something like the "rotationAngle" in cyclicGgi.
How far do the patches have to overlap/coincide? Any other ideas what could be wrong?

kind regards,
-astein

I'm also very interested in this, i wont to setup a rotor/stator case with partially overlapped interfaces. Have you found any tutorials about it? Or can you post the constant/polymesh/boundary and 0/U 0/p files here to give them a look. If i have this information then i can also set up a case troubleshoot it a bit by my self and post here if i found something so to help each other since it seems that no-one else has used overlapGgi (from my search around in the forum that is).

Stelios

Hi!
So do I, let's see how far we get.
No, unfortunately not.
There is nothing special with the p-file, set it up the normal way. The boundary I set up looks for this patch like

Outlet_stator
{
type overlapGgi;
shadowPatch Inlet_rotor;
rotationAxis (0 0 1);
angle 15.652174;
nFaces 576;
// bridgeOverlap true;
startFace 225840;
}

and the rotor-Inlet vice versa. As I said, I did not get the meaning of the "angle"-keyword. Again, there are no errors in the ggi-checks but there are problems during solving which I relate to this interface. Any help is appreciated.

-astein

Thnaks Astein, I'll give it a try with my case and document you about what happens (i think angle is correlate with domain scaling i.e. if i have a two bladed rotor and 10 bladed stator then the angle for one rotor channel is 360/2 and for one stator channel is 360/10, but thats just an assumption) i'll try to set up the case today and test it ..

regards
Stelios

Oich it seems that rotor and stator have to be aligned at one edge, thats kind of impossible in my case :/ for the moment at least!

But i think you are missing the zone definition (setSet -batch setBatch, setsToZones -noFlipMap), i estimate that you should have something like this :

GGISTATOR
{
type overlapGgi
rotationAxis (0 0 1);
angle 15.652174;
nFaces 36864;
startFace 14739376;
shadowPatch RUNNERGGI;
zone GGISTATOR_ZONE;
bridgeOverlap true;
}

Stelios

Hi and thanks for your effort!

...that was my impression as well, but this is also not possible for me.

Well, I already set the zones as you described, though I don't think there is a need to state the names in the patch-definition as well. If it would be needed, it would complain about the missing keyword, I guess.

That is what my assumption was as well up to now. Nevertheless, there might/should be a reason that a different keyword is used compared to the cyclicGgi-patch ("angle" vs. "rotationAngle"). Therefore I wouldnt be too sure that our assumption is correct.

I keep you updated when I find out anything relevant to this. Some documentation or even a small tutorial would really help with that thing...

regards, astein

"Well, I already set the zones as you described, though I don't think there is a need to state the names in the patch-definition as well. If it would be needed, it would complain about the missing keyword, I guess."

Yes correct, you just have to have them defined in the constant/polymesh/faceZones, i followed the instructions of icoDyMfoam/mixerGgi tutorial.

"That is what my assumption was as well up to now. Nevertheless, there might/should be a reason that a different keyword is used compared to the cyclicGgi-patch ("angle" vs. "rotationAngle"). Therefore I wouldnt be too sure that our assumption is correct."

That makes perfect sense i just hope the programmer will see this thread and enlighten as with half a sentence :)

I'll be waiting for any news you have and i'll post everything i can find

Stelios
p.s. there is also some partially overlapped rotor-stator interfaces within the turbomachinery addendum by i didn't had time to really check them out yet. (http://openfoamwiki.net/index.php/Si..._OpenFoamTurbo )