[philippose]

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]

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

Originally Posted by philippose

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]

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]

Hi Philippose

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]

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]

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]

Hi Jason,

sorry, no idea about that . Never used AMI.

Best,
Klaus

[immortality]

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.