CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Running, Solving & CFD

GGI together with topological changes...

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree1Likes
  • 1 Post By flowris

Reply
 
LinkBack Thread Tools Display Modes
Old   December 16, 2010, 07:02
Default GGI together with topological changes...
  #1
Senior Member
 
Karl-Johan Nogenmyr
Join Date: Mar 2009
Location: Linköping
Posts: 255
Rep Power: 12
kalle is on a distinguished road
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 is offline   Reply With Quote

Old   December 20, 2010, 03:46
Default
  #2
Senior Member
 
Karl-Johan Nogenmyr
Join Date: Mar 2009
Location: Linköping
Posts: 255
Rep Power: 12
kalle is on a distinguished road
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 is offline   Reply With Quote

Old   October 11, 2011, 08:40
Default
  #3
Senior Member
 
Karl-Johan Nogenmyr
Join Date: Mar 2009
Location: Linköping
Posts: 255
Rep Power: 12
kalle is on a distinguished road
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 is offline   Reply With Quote

Old   October 14, 2011, 07:32
Default
  #4
Senior Member
 
Karl-Johan Nogenmyr
Join Date: Mar 2009
Location: Linköping
Posts: 255
Rep Power: 12
kalle is on a distinguished road
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
kalle is offline   Reply With Quote

Old   November 17, 2011, 10:07
Default
  #5
Senior Member
 
Join Date: Apr 2010
Posts: 151
Rep Power: 7
flowris is on a distinguished road
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.
Attached Files
File Type: gz flitchingGgiFvMesh2.tar.gz (8.3 KB, 22 views)
File Type: gz surf0019.tar.gz (36.7 KB, 18 views)
elvis likes this.
flowris is offline   Reply With Quote

Old   May 7, 2012, 13:31
Default
  #6
New Member
 
Klaus
Join Date: Jul 2010
Location: Linz / Austria
Posts: 20
Rep Power: 7
strakakl is on a distinguished road
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
strakakl is offline   Reply With Quote

Old   May 7, 2012, 13:50
Default
  #7
Senior Member
 
Karl-Johan Nogenmyr
Join Date: Mar 2009
Location: Linköping
Posts: 255
Rep Power: 12
kalle is on a distinguished road
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
kalle is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Ggi FabOr OpenFOAM 17 May 9, 2013 10:19
Difference between ggi and overlapGgi? GGI Tips and Tricks? philippose OpenFOAM Running, Solving & CFD 7 January 16, 2013 10:40
Floating point exception error Alan OpenFOAM Running, Solving & CFD 10 April 6, 2012 14:02
GGI in OpenFOAM-1.5-dev philippose OpenFOAM Running, Solving & CFD 14 November 13, 2011 15:55
Problem using GGI besto OpenFOAM 13 October 30, 2010 07:34


All times are GMT -4. The time now is 01:29.