CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Pre-Processing (http://www.cfd-online.com/Forums/openfoam-pre-processing/)
-   -   usage of overlapGgi in 1.5-dev (http://www.cfd-online.com/Forums/openfoam-pre-processing/74322-usage-overlapggi-1-5-dev.html)

astein March 30, 2010 05:39

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

Stylianos March 30, 2010 06:34

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

astein March 30, 2010 07:18

Hi!
Quote:

Originally Posted by Stylianos (Post 252261)
I'm also very interested in this, i wont to setup a rotor/stator case with partially overlapped interfaces.

So do I, let's see how far we get.
Quote:

Originally Posted by Stylianos (Post 252261)
Have you found any tutorials about it?

No, unfortunately not.
Quote:

Originally Posted by Stylianos (Post 252261)
Or can you post the constant/polymesh/boundary and 0/U 0/p files here to give them a look.

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

Stylianos March 30, 2010 07:34

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

Stylianos March 30, 2010 10:34

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

astein March 31, 2010 03:07

Hi and thanks for your effort!

Quote:

Originally Posted by Stylianos (Post 252311)
Oich it seems that rotor and stator have to be aligned at one edge, thats kind of impossible in my case

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

Quote:

Originally Posted by Stylianos (Post 252311)
But i think you are missing the zone definition (setSet -batch setBatch, setsToZones -noFlipMap)

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.

Quote:

Originally Posted by Stylianos (Post 252311)
(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)

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

Stylianos March 31, 2010 05:37

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


All times are GMT -4. The time now is 17:48.