[sylvester]

Hi,

I'm trying to run the mixerGGI tutorial in parallel.
Any first iteration works flawlessly (as far as I can see), but the second one always crashes. Restarting from the first result will give one additional iteration. Restarting from this second result will again give one additional iteration, and so on.

Attached you will find the case. You can run it with:
decomposePar
mpirun -np 3 icoDyMFoam -parallel
mpirun -np 3 icoDyMFoam -parallel
mpirun -np 3 icoDyMFoam -parallel
etc.

Decomposition is done on manual, to keep all interface cells on one processor.
OF1.5-dev was updated from CVS this afternoon.

I've also attached the log file from the first run.

What is going wrong here?

Thanks for your help.

regards,
Sylvester

[sylvester]

Hi again,

I fixed it by changing sum in gSum and sumMag in gSumMag in ggiCheckFunctionObject.C.
The case is running smoothly now.

regards,
Sylvester

[sylvester]

Hi again,

Unfortunately I spoke too soon. Although (strangely enough) the presented test case runs fine, there is still a lot not working as it should be.

Martin, Hrvoje:
In http://powerlab.fsb.hr/ped/kturbo/Op...oje_Slides.pdf you mention that work was planned on parallelization of the code. Can you comment on the progress of this? Or is it still in the "planned" stage?

Thank you for your time.

regards,
Sylvester

[chapman]

Originally Posted by sylvester

Martin, Hrvoje:
In http://powerlab.fsb.hr/ped/kturbo/Op...oje_Slides.pdf you mention that work was planned on parallelization of the code. Can you comment on the progress of this? Or is it still in the "planned" stage?

Hello everyone,

what is the current status of the parallelisation named above?

I have been trying to use decomposePar with 'metis' but currently I have to use 'hierarchical' to distribute the patches correctly to the processors.
Are there any news? Thank you.

Regards, Andy

[roucho]

Regarding post #35 by M. Beaudoin:
I had the same warnings about zero intersection areas on my case. Solution 1 worked OK for me, that is:
"1: Somehow modify the snappyHexMesh settings for this mesh generation in order to get convex-only facets. Checkout the description of the parameter maxConcave in your snappyHexMeshDict file, this seems to be possible."
I've set maxConcave to 1 degree (the theoretical rigorous 0 makes snappyHexMesh crash, for me). The snappyHexMesh procedure took a noticeably longer time to complete, but the warnings disappeared afterwards, during the simulation.

[thab]

Hello, all,

I know this thread is a little bit old but it was the only one I found that discussed the GGI interpolation zero surface area problem.
I generated two meshes separately with snappyHexMesh and merged them together with mergeMeshes. The size of the cells are quite similar in the interface but I cannot guarantee that they fit perfectly together. Running checkMesh and icoDyMFoam I get those warning of zero surface area between master and neighbour faces including one that I have never seen before, that cites SutherlandHodgman, another topic discussed here. I never used stitchMeshes before, but this is not the case for it, or am I wrong?

I don't understand much about the implementation of the GGI interpolation method, but I do ok with C++ and some OF utilities and applications, so I may be able to understand some words on that if necessary. I was hoping some one could guide me through this problem as done before in this thread.

For the record, I'm using OpenFOAM 1.6-ext and my checkMesh does not state any concavity problems. I cannot say if the case will let out a Floating Point Exception since it's pretty big and it's going to take a while to run, but I can tell it already solved a few iterations. Please feel free to ask for more information and case files; for the time I'm just hoping some one will answer!

Many thanks in advance,

Thábata Maciel

[roucho]

Maybe you should update to a newer version of OpenFOAM. The canonical version (v2.1.1 @ www.openfoam.com) now features the AMI interface between two boundaries of a mesh, which may be helpful for your case, I think. Some bugs also have been corrected since version 1.6.

I don't remember the details of my application with the GGI interface, but may I suggest that you check any parameter that has something to do with the tolerance regarding coincidence of faces/edges/points... Sorry not to be more precise for the moment. If it is not helpful enough, I may dig into my "closedProjects2010" archive...

Good luck!

[thab]

Hello, Oliver,

Thank you for the fast reply! I took a look at a tutorial that uses this AMI interface. Please correct me if I'm wrong, but the main differences in setup is to create a topoSetDict to determine cell and faceSets that are going to be part of the moving domain, then choose cyclicAMI as patch type both in 0/ files and polyMesh/boundary file?

I'm definitely not familiar with this AMI, is it possible that you could tell me more about it and the differences between it and GGI? In that link I read "AMI is a technique that allows simulation across disconnected, but adjacent, mesh domains. The domains can be stationary or move relative to one another." and it seems quite similar to what GGI does, doesn't it?
I think I'll also have to understand more about the definitions in the dynamicMeshDict, but taking a quick look at it I can say I didn't understand the CofG parameter in roatationMotionCoeffs ambient.

Sorry about asking all this questions, but I got interested in this AMI and looks promising to my problem. Could I just ak for something else? When you said to check a parameter that has something to do with tolerance regarding coincident faces, did you mean the output of checkMesh or a value present in a dict, like the function ggiCheck on controlDict?

Again, thank you very much!

Thábata Maciel

[roucho]

Hi Thab,

When I said "check any parameter that has something to do with the tolerance regarding coincidence of faces/edges/points", I meant in a dictionary. Sorry not to have been specific enough. Now, I don't exactly remember which dictionary is concerned, since I don't have my archive at hand, right now. I might look into it this week-end, though.

For AMI, keep on investigating the tutorials. You are on the right track, I think! Especially check out the 3 tutorials listed at the bottom of this page:
http://www.openfoam.org/version2.1.0/ami.php

Have fun!

[thab]

Hello again!

I'd like to get back to the first topic of this old thread, the behavior of the ggi interface. I'm simulating a 3D mixer with GGI and I'm not very confident about the results.
Some plots lead me to think that may exist a discontinuity in my flow though the interface, but I can't be sure.
What really concerns me, and led me to post here about it, is the Plot Over Line filter in ParaView. Analysing the velocity magnitude and components over a line that goes through the center of the mixer outwards, the plot does not depict a continuous curve, but leaves a gap between a very small region that I believe is where the interface is. Please see the figure in the attachment.

Definetely the simulation is not considering the interface as a wall. I can not guarantee there's flux going through it, but it was a wall, its velocity would be constant in both sides of the discontinuity and also through time, which I can tell you changes considerably. Although, even with the interface not being a wall, does the flow completely ignores it? The second figure in the attachment is a plot of the U magnitude around the impeller (values of each cellsl, without ParaView's interpolation), and it doesn't seem continuous to me when it gets closer to the interface.

Is this merely a vizualization issue? Or am I doing something wrong when setting up the case? I am really hoping some one flies by and says "this is pure vizualization, the simulation is probably OK". Any additional info about the case, including the files I can send to any one who asks.

Thanks in advance!

discontinuity.jpg

umag.jpg