CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (http://www.cfd-online.com/Forums/openfoam-solving/)
-   -   Difference between ggi and overlapGgi? GGI Tips and Tricks? (http://www.cfd-online.com/Forums/openfoam-solving/69397-difference-between-ggi-overlapggi-ggi-tips-tricks.html)

philippose October 21, 2009 15:54

Difference between ggi and overlapGgi? GGI Tips and Tricks?
 
A Very Good Evening :-)!

Over the last few weeks I have been working on trying to simulate the linear motion of a spool which starts off in either the fully closed or fully open position and opens (or closes) the orifice moving at a specified linear velocity.

Earlier I had tried this out with the sliding mesh interface, but since OpenFOAM-dev now also has the GGI option, I switched over to GGI.

Basically, I made a new dynamicFvMesh class which is a modified (adapted?) version of the mixerGgi dynamicFvMesh class to handle linear motion rather than rotational motion... with the rest of the code remaining essentially the same (except for some small changes to the way in which the moving region is marked out).

Some particular requirements when it comes to simulating spool valves are:

1. The need to support cases where the two ggi patches are partially overlapped or in the worst case, completely separated out.... with the exposed parts being of boundary type "wall".

2. The geometry of the overlapping area changes with each time step (for example, a circular orifice being opened or closed would cause the overlapping region to have a variable diameter (area) which is a function of the position of the spool.

So far... I have been able to simulate static cases with GGI interfaces without any problems, with cases converging well, and the GGI patches behaving well.

When I simulate the system with motion (I use a modified transient simpleFoam which I call simpleDyMFoam), things seem to work well for a while, and then suddenly within one iteration, the simulation blows up and crashes...

At that stage, if I start the simulation from the last written time step, with a change (more or less) in the number of Outer Correctors, the simulation goes past the point when it crashed last, but crashes again after a while...

I have also tried with adaptive time stepping (based on the usual.... Maximum Courant number approach)... but this did not help too.

Today I noticed that in addition to the "ggi" boundary patch type... there also exists an "overlapGgi" boundary patch type.... would this be more relevant when it comes to partially overlapped ggi patches? When should "overlapGgi" be used, and when would it be better to use "ggi"?

Currently I do use the "bridgeOverlap" option.... and have also enabled non-orthogonal correction for GGI.

Any pointers towards the things I need to be careful about when using the GGI system would be great....


Have a great evening ahead!

Thanks a lot!

Philippose

mbeaudoin July 13, 2010 06:06

Hello,

>Earlier I had tried this out with the sliding mesh interface, but since OpenFOAM-dev now also has the GGI option, I switched over to GGI.

From your problem description, the current GGI design is not suitable. I would recommend you switch back to a sliding mesh approach.

> Some particular requirements when it comes to simulating spool valves are:
> 1. The need to support cases where the two ggi patches are partially overlapped or in the worst case, completely separated out.... with the exposed parts being of boundary type "wall".

The current design of the GGI does not support this. A sliding mesh approach is more suitable for your problem.

Martin

Quote:

Originally Posted by philippose (Post 233585)
A Very Good Evening :-)!

Over the last few weeks I have been working on trying to simulate the linear motion of a spool which starts off in either the fully closed or fully open position and opens (or closes) the orifice moving at a specified linear velocity.

Earlier I had tried this out with the sliding mesh interface, but since OpenFOAM-dev now also has the GGI option, I switched over to GGI.

Basically, I made a new dynamicFvMesh class which is a modified (adapted?) version of the mixerGgi dynamicFvMesh class to handle linear motion rather than rotational motion... with the rest of the code remaining essentially the same (except for some small changes to the way in which the moving region is marked out).

Some particular requirements when it comes to simulating spool valves are:

1. The need to support cases where the two ggi patches are partially overlapped or in the worst case, completely separated out.... with the exposed parts being of boundary type "wall".

2. The geometry of the overlapping area changes with each time step (for example, a circular orifice being opened or closed would cause the overlapping region to have a variable diameter (area) which is a function of the position of the spool.

So far... I have been able to simulate static cases with GGI interfaces without any problems, with cases converging well, and the GGI patches behaving well.

When I simulate the system with motion (I use a modified transient simpleFoam which I call simpleDyMFoam), things seem to work well for a while, and then suddenly within one iteration, the simulation blows up and crashes...

At that stage, if I start the simulation from the last written time step, with a change (more or less) in the number of Outer Correctors, the simulation goes past the point when it crashed last, but crashes again after a while...

I have also tried with adaptive time stepping (based on the usual.... Maximum Courant number approach)... but this did not help too.

Today I noticed that in addition to the "ggi" boundary patch type... there also exists an "overlapGgi" boundary patch type.... would this be more relevant when it comes to partially overlapped ggi patches? When should "overlapGgi" be used, and when would it be better to use "ggi"?

Currently I do use the "bridgeOverlap" option.... and have also enabled non-orthogonal correction for GGI.

Any pointers towards the things I need to be careful about when using the GGI system would be great....


Have a great evening ahead!

Thanks a lot!

Philippose


philippose July 3, 2012 15:21

Hello Martin,

A Good Evening to you! Hope everything is going great on your side :-)!

Sorry for having to dredge up this post again!

I was looking through the OpenFOAM Training PDF for Turbomachinery (held during the 7th OpenFOAM Workshop), and found the following line (page 42):

"Setting bridgeOverlap false disallows partially or completely uncovered
faces, where true sets a wall boundary condition."


Does this mean that the GGI system in OpenFOAM-ext now converts uncovered faces automatically to a "wall" boundary? Or is it an oversight or typo?

If this is true, GGI would again be very interesting for cases with large sections of "non-overlapping", moving geometries....... or have I misinterpreted something?

Have a great day ahead!

Philippose

strakakl December 21, 2012 05:56

Hi Philippose

Quote:

Does this mean that the GGI system in OpenFOAM-ext now converts uncovered faces automatically to a "wall" boundary? Or is it an oversight or typo?
Have you already found out if uncovered faces are set to a wall bc?

Best, Klaus

philippose December 21, 2012 06:41

Hello Klaus,

A Good day to you :-)!

I am sorry to say, that as far as I can understand, and as far as I can see in the code, the current implementation of GGI in OpenFOAM-extend, as well as the AMI implementation in the official OpenFOAM release does NOT support the conversion of uncovered patch faces into a "wall" type of boundary.

The GGI implementation converts all uncovered faces to a "slip" boundary, and furthermore, since the patch is not identified as a type "wall", the turbulence models also do not consider the uncovered faces to be a wall.

The current implementation is mainly targeted at Turbomachinery simulations, where there are usually almost no uncovered faces.

Hope this helps!

Have a nice day!

Philippose

jason January 14, 2013 16:55

Hi,

Not sure where to post this but this looks like a good place.

Would you know if pimpleDyMFoam and AMI is able to deal with porous regions or would this need implementing?

Im interested in having the AMI running right through a porous region.

Many Thanks

Jason

strakakl January 15, 2013 03:39

Hi Jason,

sorry, no idea about that :(. Never used AMI.

Best,
Klaus

immortality January 16, 2013 10:40

hi philipose.i need to work on a similar problem(with sliding mesh) but im unfamiliar with moving mesh.could you send your case to me please? Here or at:Force.of.love@gmail.com
Thank you very much.


All times are GMT -4. The time now is 00:56.