[linnemann]

Hi guys

And a big kudos to the ext team and the new release.

I have a very simple overLapGgi case with three domains.

Everything is running great except for when trying to run the case in parallel.

I get a floatingPoint exception at the pressure loop (simpleFoam).

smoothSolver:  Solving for Ux, Initial residual = 1, Final residual = 0.0607995, No Iterations 3
smoothSolver:  Solving for Uy, Initial residual = 1, Final residual = 0.0619716, No Iterations 3
smoothSolver:  Solving for Uz, Initial residual = 1, Final residual = 0.0745213, No Iterations 3
[dktux01:06293] *** Process received signal ***
[dktux01:06293] Signal: Floating point exception (8)
[dktux01:06293] Signal code:  (-6)
[dktux01:06293] Failing at address: 0x41900001895
[dktux01:06295] *** Process received signal ***

Lots more below

Is there anyone with experience in running overlapGgi in parallel?

case for download LINK

As you can see in the picture seriel run works fine.

[linnemann]

Once again to answer my own questions.

overlapGgi did not work in parallel before this git commit.

http://openfoam-extend.git.sourcefor...ure/overlapGgi

Hope somebody else can use this info.

[linnemann]

Hi

Well I'm getting closer to something useful.

I've updated the case in the first thread to reflect the changes in the git commit and parallel works now (although not in the tutorial).

Now the latest issue that arises is when the middle part rotates outside the top part (no overlapping faces) the calculations blow up. I've tried many things, but to no avail.

[linnemann]

Ok strange is afoot :-)

Just made an even simpler case with just a pipe and the middle part rotating and all is good. These all have the same overlap angle so I will make one tomorrow with non matching angles and see how it goes.

For all interested here is the case

[linnemann]

A little update.

It did indeed seem like my assumptions holding true about different angles for the different segments of the mesh. I've created a similar circular cyclic mesh with the first segment having an angle of 45° the middle segment (rotating) and angle of 30° an the top segment an angle of 60°. As can be seen in the little animation below the simulation crashes as the middle part rotates outside the bottom one. Attached is the new case. I will abandon my work with overlapGgi until it is in a more mature state.

[deepblue17]

I assume you have periodic boundary conditions at the azimuthal patches. If you have different pitch angles this assumption is no longer valid! Think about this carefully if you don't trust me! You will need some kind of phaselag boundary conditions, both for the azimuthal patches and the rotor-stator interfaces! The simplest I can imagine are these from Erdos&Alzner. Feel free to implement them and give me a call if these are ready.

[linnemann]

Hi Oliver

Thanks for the clarification.

I do unfortunately not have the time/knowledge about OF to implement what you propose.

I was simply exploring the capabilities of the overlapGgi and stumpled into these limitations so just thought I would share as the documentation about the new features are sparse at the moment.

[deepblue17]

The overlapGgi interface is at the moment only working if the commsType for PStream is set either to nonBlocking or scheduled. But not if commsType is set to blocking.