[philippose]

Hello and a Good Evening to everyone,

Looks like summer hit late but hard here :-)!! Happy that its atleast drizzling lightly now! Craaazy!

Over the last few days, I have been looking into GGI again.... I think I have mentioned this earlier.... I am trying to get GGI working for a linear motion case, with partially overlapping patches.

Well.... the results have not been very positive so far, and I am sure I am missing something regarding the basic usage of the GGI concept.

Just a few questions which I hope someone would be kind enough to answer :-)!

1. Does GGI work for Tetrahedral meshes?

2. Other than the fact that the GGI patches are not allowed to physically touch or cross each other, are there any other specific requirements which need to be fulfilled in order to use GGI?

3. When using GGI for transient simulations, do I need to use a specific scheme for the time variable (so far I have used Euler)?

4. Does it require any specific type of div, laplacian or grad schemes? Or are the following ok?

.... grad: Gauss linear
.... div: Gauss upwind
.... laplacian: Gauss linear corrected
.... and linear interpolation

5. Do I need to be careful about the type of solvers I use for the p, U and turbulence variables? (I always use GAMG for pressure, and PBiCG with DILU for the U, k, and omega/epsilon variables)

6. Currently I use a solver called simpleDyMFoam which is essentially a mix of transientSimpleFoam and icoDyMFoam.... question is.... does anyone have any bad experiences with SIMPLE based transient solvers in connected with GGI?

7. Is it advisable to use GGI with adaptive time step control enabled? Or does that lead to unnecessary stability issues?


It would be really nice if someone could provide a few pointers regarding these issues.

Have a great (and hopefully not overly sultry and warm) Evening :-)!

Philippose

[mbeaudoin]

Hello,

From philippose earlier post:

>Over the last few days, I have been looking into GGI again.... I think I have mentioned this earlier.... I am trying to get GGI working for a linear motion case, with partially overlapping patches.
>
>Well.... the results have not been very positive so far, and I am sure I am missing something regarding the basic usage of the GGI concept.

If you are referring to your earlier post in a different thread about using the GGI, the reason for your problems is quite simply because your case is not suitable for the current GGI implementation. I recommend you switch back to a sliding mesh approach.


>Just a few questions which I hope someone would be kind enough to answer :-)!
>
>1. Does GGI work for Tetrahedral meshes?

Yes. Cells type does not matter as long as you stay away from concave faces on the GGI patches.

>2. Other than the fact that the GGI patches are not allowed to physically touch or cross each other, are there any other specific requirements which need to be fulfilled in order to use GGI?

This is not a fact, this is nonsense. Where did you pick that one up?
The GGI interface is sufficiently robust to handle minor patches topology problems like this.

Please provide a test case showing that this is a real problem with the GGI. http://www.extend-project.de/project...m-test-harness.
Make sure your test case can be published.

The only requirement with the actual GGI design is to stay away from GGI patches with concave faces. And this limitation will be resolved soon.

>3. When using GGI for transient simulations, do I need to use a specific scheme for the time variable (so far I have used Euler)?

No.

>4. Does it require any specific type of div, laplacian or grad schemes?

No.

>5. Do I need to be careful about the type of solvers I use for the p, U and turbulence variables? (I always use GAMG for pressure, and PBiCG with DILU for the U, k, and omega/epsilon variables)

No.
The GGI is just a coupled boundary interface. Hrv did the appropriate modifications so we can use the GGI with GAMG.
If you find a solver that is failing systematically with the GGI interface and 1.5-dev, please report the problem and contribute a validation test case that can be published.

>6. Currently I use a solver called simpleDyMFoam which is essentially a mix of transientSimpleFoam and icoDyMFoam.... question is.... does anyone have any bad experiences with SIMPLE based transient solvers in connected with GGI?

If so, please provide a validation test case that can be published.

>7. Is it advisable to use GGI with adaptive time step control enabled? Or does that lead to unnecessary stability issues?

I don't see why this would be a problem, other than your solver being unstable with adaptive time step control enabled/disabled.

Again, the GGI is just a simple patch coupling interface. It will simply interpolate fields between two non conformal patches. That's all it does.

Martin

Originally Posted by philippose

Hello and a Good Evening to everyone,

Looks like summer hit late but hard here :-)!! Happy that its atleast drizzling lightly now! Craaazy!

Over the last few days, I have been looking into GGI again.... I think I have mentioned this earlier.... I am trying to get GGI working for a linear motion case, with partially overlapping patches.

Well.... the results have not been very positive so far, and I am sure I am missing something regarding the basic usage of the GGI concept.

Just a few questions which I hope someone would be kind enough to answer :-)!

1. Does GGI work for Tetrahedral meshes?

2. Other than the fact that the GGI patches are not allowed to physically touch or cross each other, are there any other specific requirements which need to be fulfilled in order to use GGI?

3. When using GGI for transient simulations, do I need to use a specific scheme for the time variable (so far I have used Euler)?

4. Does it require any specific type of div, laplacian or grad schemes? Or are the following ok?

.... grad: Gauss linear
.... div: Gauss upwind
.... laplacian: Gauss linear corrected
.... and linear interpolation

5. Do I need to be careful about the type of solvers I use for the p, U and turbulence variables? (I always use GAMG for pressure, and PBiCG with DILU for the U, k, and omega/epsilon variables)

6. Currently I use a solver called simpleDyMFoam which is essentially a mix of transientSimpleFoam and icoDyMFoam.... question is.... does anyone have any bad experiences with SIMPLE based transient solvers in connected with GGI?

7. Is it advisable to use GGI with adaptive time step control enabled? Or does that lead to unnecessary stability issues?


It would be really nice if someone could provide a few pointers regarding these issues.

Have a great (and hopefully not overly sultry and warm) Evening :-)!

Philippose

[philippose]

Hello Martin,

A Good Afternoon to you!

Thank you very much for taking the time off, to provide me with the much needed answers to the questions I had posed. Yes, I had posted a similar thread some time ago, maybe it was a mistake to open a new thread with roughly the same topics.

You have mentioned that the case I am trying to simulate is not really suitable for the current implementation of GGI. Is this because I am trying to simulate a non-rotating system, or does it have something to do with the non-overlapping nature of the patches?

On page 13 of the presentation: http://www.openfoamworkshop.org/08/p...doin_Jasak.pdf

it has been mentioned that the GGI implementation is capable of re-assigning non-overlapped faces to a user-defined boundary type such as the wall type.

I found the following documentation for setting up GGI on the OpenFOAMWiki:

ggi_inside_part
{
  type          ggi;                  // This is the definition of the ggi patch type itself
  shadowPatch   ggi_outside_part;     // Here you specify the boundary name of the opposite GGI patch.
  bridgeOverlap false;                // The bridgeOverlap parameter is enabled if part of the patch 
                                      // faces are left partially or completely uncovered.
  zone          ggi_inside_part_zone; // Information that will be used to create a faceZone that is 
                                      // used to parallelize the ggi 
}

The bridgeOverlap option seems to be the parameter which enables / disables this capability for GGI to be able to handle incompletely covered patch pairs.

Am I interpreting something wrong ?


Sorry about my wrong usage of words regarding the crossing or touching of patches. I had read in one of the posts a long time ago (unfortunately I cannot find this post anymore.... ) that GGI was sensitive to such situations, and that they need to be avoided. Maybe it was a very early feedback given by a user before the GGI implementation had matured to the current level.


It would be great if you could give me a bit more information as to why you think my case is unsuitable for simulation with GGI.

It has not been so, that the simulations I have tried with GGI so far does not run at all..... they usually run to a certain extent, but at some point, they diverge extremely fast (usually within one or two time-steps), and quits.

Once again, thank you for the response....

Have a great day ahead!

Philippose

[mbeaudoin]

Hello,

>You have mentioned that the case I am trying to simulate is not really suitable for the current implementation of GGI.
>Is this because I am trying to simulate a non-rotating system, or does it have something to do with the non-overlapping nature of the patches?

Because of the non-overlapping nature of your patches.

>
>On page 13 of the presentation: >http://www.openfoamworkshop.org/08/presentations/Turbomachinery/Beaudoin_Jasak.pdf
>
>it has been mentioned that the GGI implementation is capable of re-assigning non-overlapped faces to a user-defined boundary type such as the wall type.

You are quite right, but this presentation was made 2 years ago, from my initial implementation of the GGI, and before contributing the GGI code to the dev version.

The feature of "re-assigning non-overlapped faces to a user-defined boundary type" was removed from the released version. It was very experimental back then and judged not suitable for public release at the time.

This is why I mentionned the "current" implementation of the GGI. Sorry, I should have been clearer.


> The bridgeOverlap option seems to be the parameter which enables / disables this capability for GGI to be able to handle incompletely covered patch pairs.
>
>Am I interpreting something wrong ?

The bridgeOverlap option was the compromise that was implemented in order to handle non-overlapped patch faces. Basically, when this option is set, the non-overlapped patch faces will behave as "slip wall" faces.

For moving meshes with "rotational" sliding GGI interfaces, the number of non-overlapped faces is usually fairly small, and this number is relatively constant as the mesh is moving along.

Using a moving mesh with "translational" sliding GGI interfaces will explicitly create more and more of those little "slip wall" faces, up to completely non-overlapped patches. I have no clue how well this will behave.

> It would be great if you could give me a bit more information as to why you think my case is unsuitable for simulation with GGI.

Well, the first thing that came to mind when I saw the description of your problem was the impressive work being done by the Politecnico di Milano group with sliding meshes when simulating moving pistons and valves.

That's why I thought that a "classic" sliding mesh approach might be better for you, given the fact that you are possible "stretching" the non-overlapped feature of the current GGI implementation.

Still, I invite you to contribute a test case where this translational "sliding GGI" can be analyzed further.

Regards,

Martin

Originally Posted by philippose

Hello Martin,

A Good Afternoon to you!

Thank you very much for taking the time off, to provide me with the much needed answers to the questions I had posed. Yes, I had posted a similar thread some time ago, maybe it was a mistake to open a new thread with roughly the same topics.

You have mentioned that the case I am trying to simulate is not really suitable for the current implementation of GGI. Is this because I am trying to simulate a non-rotating system, or does it have something to do with the non-overlapping nature of the patches?

On page 13 of the presentation: http://www.openfoamworkshop.org/08/p...doin_Jasak.pdf

it has been mentioned that the GGI implementation is capable of re-assigning non-overlapped faces to a user-defined boundary type such as the wall type.

I found the following documentation for setting up GGI on the OpenFOAMWiki:

ggi_inside_part
{
  type          ggi;                  // This is the definition of the ggi patch type itself
  shadowPatch   ggi_outside_part;     // Here you specify the boundary name of the opposite GGI patch.
  bridgeOverlap false;                // The bridgeOverlap parameter is enabled if part of the patch 
                                      // faces are left partially or completely uncovered.
  zone          ggi_inside_part_zone; // Information that will be used to create a faceZone that is 
                                      // used to parallelize the ggi 
}

The bridgeOverlap option seems to be the parameter which enables / disables this capability for GGI to be able to handle incompletely covered patch pairs.

Am I interpreting something wrong ?


Sorry about my wrong usage of words regarding the crossing or touching of patches. I had read in one of the posts a long time ago (unfortunately I cannot find this post anymore.... ) that GGI was sensitive to such situations, and that they need to be avoided. Maybe it was a very early feedback given by a user before the GGI implementation had matured to the current level.


It would be great if you could give me a bit more information as to why you think my case is unsuitable for simulation with GGI.

It has not been so, that the simulations I have tried with GGI so far does not run at all..... they usually run to a certain extent, but at some point, they diverge extremely fast (usually within one or two time-steps), and quits.

Once again, thank you for the response....

Have a great day ahead!

Philippose

[philippose]

Hello again Martin,

Once again, thank you very much for your reply.... that made things a lot clearer :-)!

I was under the impression that the partial overlap situation was a standard part of the GGI implementation.

However, it would be great to submit a test-case to the OpenFOAM-dev development system.

The linear version of the GGI library (which I call linearValveGgiFvMesh) is ready and can be compiled into an independent library which can be included into a simulation using the libs ("...") option in controlDict.... hence, the test library makes no changes to the OpenFOAM-dev source code itself.

A simple test-case which starts with the entire GGI pair in a non-overlapped condition which then slowly starts overlapping is also ready.

The TGZ of the library is only 4 KB, whereas the TGZ of the test-case is 4.9 MB.

I briefly looked up the new OpenFOAM-ext test-harness, but I was not sure how exactly to submit the library into this framework.

What would be the best way of submitting the library and the test-case?

Have a great evening ahead!

Regards,
Philippose

[mbeaudoin]

Hello Philippose,

>I briefly looked up the new OpenFOAM-ext test-harness, but I was not sure how exactly to submit the library into this framework.
>
>What would be the best way of submitting the library and the test-case?

You could try the upload facility available on the new Extend Portal: http://www.extend-project.de/project...m-test-harness

See the "Test Case Upload" section.

Based on the information that you will provide, I will put your test case under an appropriate section of the svn repository on openfoam-extend, probably somewhere under the Breeder_1.5 section at first. So obviously, make sure it is ok for you to share this test case with the community.

A new test harness will be put in place for those new contributed test cases, so everybody will be able to easily test-drive your test case on their own machine.

Make sure also to write your name in a Readme file and inside the source code files packaged with the test case, so you will get the full credit this contribution.

Regards,

Martin

Originally Posted by philippose

Hello again Martin,

Once again, thank you very much for your reply.... that made things a lot clearer :-)!

I was under the impression that the partial overlap situation was a standard part of the GGI implementation.

However, it would be great to submit a test-case to the OpenFOAM-dev development system.

The linear version of the GGI library (which I call linearValveGgiFvMesh) is ready and can be compiled into an independent library which can be included into a simulation using the libs ("...") option in controlDict.... hence, the test library makes no changes to the OpenFOAM-dev source code itself.

A simple test-case which starts with the entire GGI pair in a non-overlapped condition which then slowly starts overlapping is also ready.

The TGZ of the library is only 4 KB, whereas the TGZ of the test-case is 4.9 MB.

I briefly looked up the new OpenFOAM-ext test-harness, but I was not sure how exactly to submit the library into this framework.

What would be the best way of submitting the library and the test-case?

Have a great evening ahead!

Regards,
Philippose

[philippose]

Hello Martin,

A Good Evening to you!

Sorry for the delay in responding to your post.....

As I mentioned, last week I prepared a test-case (which can be published if required), and packaged it into a TGZ file, and in addition, also packaged the "linearValveGgiFvMesh" library into a separate TGZ file.

Is it sufficient to simply submit these two files as separate Test-harness submissions, or should I submit it as one package, with a wrapper bash script which compiles the linearValveGgiFvMesh library, cleans up cellZones, faceZones and pointZones created from an earlier run, and then automatically starts the simulation case?

In case the wrapper is required, is it ok to allow creation of the library as usual in the "$FOAM_USER_LIBBIN" folder, or should it be compiled into a DLL within the local case folder?

And also, is there a standard template for README file? And do I need to document the code and test-case in any

I wish you a great evening ahead!

Philippose

[philippose]

Hello again Martin,

I created a single TGZ file containing the linearValveGgiFvMesh library, the simpleDyMFoam solver, and a test-case. The package also contains an "Allrun" script which automates the compilation of the library and the solver, and starts the simulation case.

Earlier today, I tried to submit this TGZ file to the Test-Harness at the OpenFOAM-extend website, but it kept throwing up an error stating that I am only allowed to upload a TGZ/TAR file.....

Any idea what I might be doing wrong, or is it a bug in the OpenFOAM-extend website?

Have a nice day ahead!

Philippose

[mbeaudoin]

Hello Philippose,

Thank you for the packaging you did and the Allrun file. This will help a lot.

About your problem with the uploading, be patient a little bit more, I will contact Holger and see if he can help here.

Best regards,

Martin

Originally Posted by philippose

Hello again Martin,

I created a single TGZ file containing the linearValveGgiFvMesh library, the simpleDyMFoam solver, and a test-case. The package also contains an "Allrun" script which automates the compilation of the library and the solver, and starts the simulation case.

Earlier today, I tried to submit this TGZ file to the Test-Harness at the OpenFOAM-extend website, but it kept throwing up an error stating that I am only allowed to upload a TGZ/TAR file.....

Any idea what I might be doing wrong, or is it a bug in the OpenFOAM-extend website?

Have a nice day ahead!

Philippose

[holger_marschall]

Hi Martin and Philippose,

sorry for my belated feedback... The upload form should work now, I had a typo within the php script part checking for the right file type. However, it is fixed now!

Let me know if there are any further problems to fix.

best regards,

[philippose]

Hello Holger and Martin,

A Good evening to you!

Just wanted to inform you, that I was able to successfully upload a TGZ package of the linear GGI test-case into the OpenFOAM-extend Test Harness.

Thanks once again to Holger for helping me out with the submission, and Thanks a lot Martin for offering to take a look at the case.

Have a nice day ahead!

Philippose

[smajer]

Dear all,
I need some clarification of a bridgeOverlap option in ggi.
I have a two pipes that are connected. Diameter of the first pipe is 10 times larger then the other.
Smaller pipe is perpendicularly connected to the large one (see Picture1). I use ggi to connect these two pipes.
ggi patch on large pipe is a square aligned with outer diameter of the large pipe (see Pic2) and on the small pipe it is a circle (it is also aligned with outer diameter of the large pipe).
The result of such configuration is that several (actually 4) faces on square patch are uncovered. If I understand meaning of bridgeOverlap option, this shouldn't be the problem if the bridgeOverlap option is set to "true", but unfortunately my calculation breaks in first step just before it starts to solve pressure equation:
Starting time loop
Time = 1
smoothSolver: Solving for Ux, Initial residual = 1, Final residual = 8.668779896e-06, No Iterations 4
smoothSolver: Solving for Uy, Initial residual = 1, Final residual = 5.241675901e-06, No Iterations 4
smoothSolver: Solving for Uz, Initial residual = 1, Final residual = 9.088300377e-06, No Iterations 4
Floating point exception
I have tested case setup with square-shaped small pipe (in that case both ggi patches are same in size and shape, but different number of faces – just to exclude other boundary conditions as a source of error) and everything worked just fine.
My question is:
Is it possible to have setup shown in pictures? Is bridgeOverlap option capable to handle non-overlapped patch faces? If yes, does anyone now why everything brakes with Floating point exception?

Thanks,
Sinisa

p.s.
I use OpenFOAM 1.6-ext

[hjasak]

What you are doing is wrong: bridge overlap is a measure to deal with geometrical inaccuracies rather than large uncovered surfaces like yours. Right now you have no proper boundary condition on the uncovered part of the GGI.

You should couple the two sides using a sliding interface instead, which will allow you to properly specify the boundary contition.

Hrv

[smajer]

That means I misunderstood bridgeOverlap option.

Thank you any way,

Sinisa

[Islam ElQatary]

Originally Posted by smajer

Dear all,
I need some clarification of a bridgeOverlap option in ggi.
I have a two pipes that are connected. Diameter of the first pipe is 10 times larger then the other.
Smaller pipe is perpendicularly connected to the large one (see Picture1). I use ggi to connect these two pipes.
ggi patch on large pipe is a square aligned with outer diameter of the large pipe (see Pic2) and on the small pipe it is a circle (it is also aligned with outer diameter of the large pipe).
The result of such configuration is that several (actually 4) faces on square patch are uncovered. If I understand meaning of bridgeOverlap option, this shouldn't be the problem if the bridgeOverlap option is set to "true", but unfortunately my calculation breaks in first step just before it starts to solve pressure equation:
Starting time loop
Time = 1
smoothSolver: Solving for Ux, Initial residual = 1, Final residual = 8.668779896e-06, No Iterations 4
smoothSolver: Solving for Uy, Initial residual = 1, Final residual = 5.241675901e-06, No Iterations 4
smoothSolver: Solving for Uz, Initial residual = 1, Final residual = 9.088300377e-06, No Iterations 4
Floating point exception
I have tested case setup with square-shaped small pipe (in that case both ggi patches are same in size and shape, but different number of faces – just to exclude other boundary conditions as a source of error) and everything worked just fine.
My question is:
Is it possible to have setup shown in pictures? Is bridgeOverlap option capable to handle non-overlapped patch faces? If yes, does anyone now why everything brakes with Floating point exception?

Thanks,
Sinisa

p.s.
I use OpenFOAM 1.6-ext

hi
i try to simulate wind turbine with 2 mesh regions i used GGi to interface between them and i get the same problem of urs how did u fix it?
Best