[kalle]

Hi,

would it be possible to use GGI together with topological changes that also affects the GGI interface. For instance, taking the mixerGGI tutorial and adding axial layers to the rotor. During run, the GGI interface would then increase the number of faces. Would the current GGI implementation support that?

Another question, what is the performance comparison between GGI and sliding interfaces?

Regards,
Kalle

[kalle]

Ok, some trial and error might have answered my questions. I modified the mixerGgi case to have a dynamically changing mesh in the center - removing layers. Before layers are removed it seems to work, but as they vanish, so does the communication between the meshes. 1.5-dev and 1.6-ext behaves the same.

Without looking how GGI is actually implemented, it seems that to allow for this, one should re-setup the GGI interfaces at time-steps when the mesh has changed...

Best regards,
Kalle

[kalle]

Ok, so my test case was lousy. GGI does indeed support topological changes at the interface patches.

However, working a bit further and taking the step to parallelize a case which uses sliding interfaces, layer addition/removal and a ggi I encountered another problem:

In serial I could initiate my topological changes (the sliding interfaces and layer addition/removal) in a first step, i.e. creating the face/cellZones and setting up the meshModifiers, and after that create my ggi faceZones and set up boundary-file and my time directory... However this becomes problematic in parallel. I can create the ggi faceZones before decomposing (like normal procedure) and transfer them to all processors. Then comes the problem of starting the runs. I cannot keep the ggi zones when I need to set up the meshmodifiers at runtime, but I cant set up the ggi zones at runtime together with other zones needed for the mesh modifiers either.

It is a bit hard to explain clearly... but bottomline is: it seems to be tricky to use ggi together with mesh modifiers in parallel due to the order zones are created. Did anyone explore this field?

Regards,
Kalle

[kalle]

If some people have interest:

Foam::mixerGgiFvMesh::addZonesAndModifiers()

Gives a hint how to overcome this issue.

A more general question though: Is it at all possible to combine layeradditionremoval with GGI in parallel? I have some processor doing layeradditionremoval on their domain, while 4 other are hosting a GGI. The GGI faces present on the first processors, are not summed up in polyTopoChangerChangeMesh.C, which gives an error:

Error in face insertion. Number of inserted faces: 52968. Expected 60256 faces.

with debug switches activated.

The difference above is exactly the # of ggi faces. All processors have complete ggi faces present in faceZones (globalFaceZones). On non-ggi processors, the ggi faces should be zone-only faces I guess. If so, the error above should not have been triggered.

Regards,
Kalle

[flowris]

I am having a similar problem: I have a moving mesh class to make a combination of a ggi and a moving mesh outer. The moving outer mesh only deforms and has no topological changes.

When running in serial, this work perfect, but in parallel, the mesh deforms differently, creating unwanted cell deformations.

In attachment you can find the moving mesh class, and a case to be run on 1 or 16 processors (or another number if you change the decomposePar).

To run, use the commandos in "rc".
This works in 1.6-ext.

[strakakl]

Hi Karl-Johan,

i'm working on a case where i have to combine ggi with topological changes. In my case the topology of the static part changes whereas the topo of the rotating part stays the same. I modified the mixerGgiFvMesh code to get this running. When running a test case after a few time steps the solver stops with

--> FOAM FATAL ERROR:
negative cell volume. Error in mesh motion before topological change.

From function bool layerAdditionRemoval::changeTopology() const
in file polyMeshModifiers/layerAdditionRemoval/layerAdditionRemoval.C at line 333.

FOAM aborting

i am not sure but maybe the reason is a bad setup of my test case.

What have you done to get ggi together with topo changers running? Is it possible that you post your test case, so i could compare it with mine?

Best regards,
Klaus

[kalle]

Hi!

My conclusion was as indicated above that GGI does not work very well with other mesh modifiers in parallel. Generally you decompose GGI cases using those globalFaceZones, which make the GGI faces present on all processors. Such 'ghost' faces present on a processor doing layerAdditionRemoval caused my issues. I have only managed to run the GGI in a mode called 'local parallel', where all my GGI's stay confined to individual processors. Hence, I do not need to use the globalFaceZones during decomposition. This approach works for my case (sorry, no allowance to share), but is not very general.

I would guess your error above comes from one or several cells becoming squeezed by the layerAR. Monitor your mesh step by step before the crash, and you will likely find the error (for instance, too large time step)

Kalle