GGI in OpenFOAM
 

Dear All,

I am happy to announce that I have now finished the implementation of the General Grid Interface (GGI) in OpenFOAM, including massive parallelisation and algebraic multigrid solver (this was a struggle). The SVN snapshot, including the updated tutorial will be uploaded later today.

Please note that as a part of parallelisation I have changed the domain decomposition tools AND the definition of the GGI - you will have to (slightly) update the existing cases.

Since GGI is pretty popular and quite tricky to set up, I would like to propose a skype teleconference with a demonstration, some background, tutorial and a series of slides on how to use the feature. Please drop me a line if you are interested and we at Wikki will do the organisation.

Many thanks to people who contributed to the code - you know who you are. I also expect to present the details of numerics, implementation and parallelisation on the Workshop in Montreal

Enjoy,

Hrv

Hrv,

that sounds great to me. Thank you very much. I will give it a try soon.

Regards BastiL

Thanks for all the efforts, and what is your skype account?
I am insterested in.
Anyone else?

Hi Hrv,

This sounds good to me. Please put me on the list for the proposed teleconf.

Thanks,
Helmut

Hello Hrv,

Thanks for this great work. I like to know more about Ggi, and how to work with that. Would you add my name to the list for teleconf?

Thank you
Mojab

Hrv,

I have run first tests now and everything works fine so far. Thank you very much.

I would like to join you skype session, but have no webcam and never used it before. Is it possible to just listen and watch? Would be nice :-)

Fabian

I'd like to be in too

Hi Hrv

Thanks for the huge amount of effort that this all must have taken. Would it be possible to record and post the video conference as a tutorial file in OpenFOAM? Also I am unable to find ggi on the subversion repository - What is it called and which package is it in?

Thanks again

Nick

Hello,

The GGI is now part of the main OpenFOAM-1.5-dev libraries, and is not provided as a separate package.

Martin

OpenFOAM GGI webcast
 

Dear All,

Thank you for your responses, both through the Forum and directly. We have picked Thursday 14/May/2009 14.00 GMT for the webcast, which will be done as a teleconference + pdf slides.

To register, please E-mail enquiries@wikki.co.uk with your name, affiliation and contact details.

Hrv

Thanks for your great work!
 

Hi,

I would like to thank you for this very useful development.

I'm sure that Martin Beaudoin 'knows who he is', but I would like to acknowledge him in name, as one of the guys who did much of the work.

Håkan.

missed OpenFOAM GGI webcast
 

Hi Hrv

Is there any available documentation about the GGI implementation, as video recordings or slides? Unfortunately I missed the webcast!

Thanks again

Daniele

Thats really crazy, Daniele... Tell me how to live in future... ;)

Marico,

You are right, and fortunately I am living in the present with some look to the future :). I just have not read the month correctly.
In any case Hrv please add me into your list

Daniele

GGI user report
 

First, I'd like to applaud Martin Beaudoin and Hrvoje Jasak for their amazing efforts with the GGI. Truly inspiring work!

It's now time to expose the GGI to the real world and begin to accumulate the experiences. Here is my brief report which includes both success stories and problems. (The story will continue in Montreal, but hopefully without the problems section.)

Case:
A single-blade pump in a volute. Incompressible, turbulent flow.

Mesh:
Two separately generated GridPro meshes, one for the impeller (rotor) and the other for the volute (casing). Total number of cells appr. 1.15M and on the impeller avg. y+~=42 (wall functions). The GGI patches were completely non-matching: insideGGI/outsideGGI = 10080/9744 faces.

MRFSimpleFoam:
I had no difficulty setting up the problem and computing a quasi-steady (frozen-rotor) solution with both kEpsilon and kOmegaSST turbulence models. The error in the mass flux across the GGI was:
GGI pair (insideGGI, outsideGGI) : 0.0588090734 0.0588615586 Diff = -8.7289918e-05 or 0.148429338 %.

turbDyMFoam:
I managed to start a single-processor time-accurate run using the quasi-steady solution as an initial guess, but I had great difficulties keeping the pressure under control (now I know why). Once the pressure did settle - I had to use a very small time step - I managed to compute about 1.2 revolutions with the deltaT corresponding to 0.5deg per time step. So, the GGI seems to work! The pressure behavior continued to be 'noisy', but remained sensible as you can see in the picture (head.jpg).

I stopped to update my dev installation to this latest version and followed the mixerGgi-tutorial's example in changing the setup. (Btw, the zone treatment is now much better than before.) I think I got everything right, but when I restarted the time-accurate computation, the pressure problems came back two fold. Now that I had to dig a bit deeper I noticed the following:

1. Mass flux (phi) across the impeller wall is, clearly, not zero.
2. Uz on the impeller wall is not zero. (The rotation axis is the z-axis.) See the picture (Uz_impeller.jpg). In fact, they had not been zero since I started the turbDyMFoam run.

I've checked my case setup many times, but I cannot find anything wrong with it. The wall velocities worked beautifully with the MRFSimpleFoam computations. So, I guess there is a bug in the mixerGgiFvMesh, but I'm unable to identify it. Perhaps this is a enough for Hrv and Martin to get to the bottom of this. The tutorial is 2D so it doesn't yield any help on this. Has anyone else seen something like this?

This story will continue in Montreal, where I hope to present something good. I hope this problem has an easy fix -- perhaps at my end.

Best regards,
- mikko

Hi Mikko

We are doing similar simulations except that I stayed in 2D for now. I did use MRFSimpleFoam and turbDyMFoam as well, using the ggi, and I had the same problem than you, having trouble with the pressure. I came to the same conclusion than you, having a small time step solves the problem, and that is quite logical, as the mesh is physically moving, the time step should be so that you rotate the mesh not more than one or two cells each step.

However, as I am in 2D I didn't see the problem with the walls, but I have seen a case quite recently where the wall boundaries were not correctly set, but it still worked in MRFSimpleFoam, as nothing really turned.
Did you put a zeroGradient for the pressure on your walls, and a fixedValue (0 0 0) for the velocity at the wall?

Good luck!

Olivier

Hi Olivier,

The tangential velocities on the rotating wall computed by MRFZone (for MRFSimpleFoam) and mixerGgiFvMesh (for turbDyMFoam) agree nicely. It's the z-direction that is faulty. It can be easily seen how the wall velocities are computed by the MRFZone, but I cannot say the same about mixerGgiFvMesh. Hopefully someone with greater code fluency can bring further light onto this issue.

I added a new picture with a tighter scale to show how the Uz follows the z-component of the face normals, with maximum/minimum values around 45deg. If you're working with 2D geometries, you won't see this at all. You wouldn't have any 3D geometries lying around?

Perhaps the cylindrical coordinate system is at the root of this problem.

Yours,
- mikko

Hi Mikko

I see what you mean. As you said with my 2D geometry, I don't have this problem. I do however have a 3D geometry of the ercoftac pump, meshed already, maybe I could share it with you if you want. I need to clean it a bit though and to work on it a bit first.

Olivier

Hi Mikko,

What you need is is called a movingWallVelocity boundary condition: this will make sure the velocity on the surface of the impeller (which MUST be in global Cartesian coordinates) is automatically updated to make sure the mass flux is exactly zero.

Looking forward to some updates + pretty pictures to show everybody what an open source effort can lead to.

Best,

Hrv