CFD Online Discussion Forums - Any update on mixerGgiFvMesh

Page 2 of 4

Show 40 post(s) from this thread on one page

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- OpenFOAM Running, Solving & CFD (https://www.cfd-online.com/Forums/openfoam-solving/)

- - Any update on mixerGgiFvMesh (https://www.cfd-online.com/Forums/openfoam-solving/57772-any-update-mixerggifvmesh.html)

waterboy

November 4, 2008 16:56

Dear Prof. Jasak, Thanks alot

Dear Prof. Jasak,
Thanks alot for Your answer!
I assume You are refering to the GGI method, right? Should sliding interface work too? I have a two week old svn checkout and am struggling to make the world turn:-)
GGI seems great and I tend to prefer it but still don't have any substantial experience, still learning about the world of OpenFOAM...
And in both cases I haven't yet understood if I should use a wall or movingwall patch on the rotating item. Any hint appreciated..
Pal

waterboy

January 22, 2009 08:59

Hi again, After some successe

Hi again,
After some successes I am stuck again.
Using OpenFOAM 1.5-dev I get the following warning when using GGI in one of my cases:
Starting time loop

Volume: new = 3.86875 old = 3.86875 change = 0 ratio = 0
Courant Number mean: 0.00828238 max: 0.285853
deltaT = 0.0119048
Time = 8.5019

--> FOAM Warning :
From function GGIInterpolation<masterpatch,>::calcAddressing()
in file /data/tmp/dasch/OpenFOAM/OpenFOAM-1.5-dev/src/OpenFOAM/lnInclude/GGIInterpolatio nWeights.C at line 346
polygonIntersection is returning a zero surface area between
Master face: 1649 and Neighbour face: 928 intersection area = 0
Please check the two quick-check algorithms for GGIInterpolation. Something is missing.
--> FOAM Warning :
From function GGIInterpolation<masterpatch,>::calcAddressing()
in file /data/tmp/dasch/OpenFOAM/OpenFOAM-1.5-dev/src/OpenFOAM/lnInclude/GGIInterpolatio nWeights.C at line 346
polygonIntersection is returning a zero surface area between
Master face: 1924 and Neighbour face: 1795 intersection area = 0
Please check the two quick-check algorithms for GGIInterpolation. Something is missing.
--> FOAM Warning :
From function GGIInterpolation<masterpatch,>::calcAddressing()
in file /data/tmp/dasch/OpenFOAM/OpenFOAM-1.5-dev/src/OpenFOAM/lnInclude/GGIInterpolatio nWeights.C at line 346
polygonIntersection is returning a zero surface area between
Master face: 1940 and Neighbour face: 1765 intersection area = 0
Please check the two quick-check algorithms for GGIInterpolation. Something is missing.
--> FOAM Warning :
From function GGIInterpolation<masterpatch,>::calcAddressing()
in file /data/tmp/dasch/OpenFOAM/OpenFOAM-1.5-dev/src/OpenFOAM/lnInclude/GGIInterpolatio nWeights.C at line 346
polygonIntersection is returning a zero surface area between
Master face: 1947 and Neighbour face: 1815 intersection area = 0
Please check the two quick-check algorithms for GGIInterpolation. Something is missing.
Rescaling of weighting factor:
Largest slave weighting factor correction : 0.0750979
Largest master weighting factor correction: 0.151511
PBiCG: Solving for Ux, Initial residual = 0.00135415, Final residual = 4.47234e-06, No Iterations 2
PBiCG: Solving for Uy, Initial residual = 0.0110796, Final residual = 2.34074e-06, No Iterations 3
PBiCG: Solving for Uz, Initial residual = 0.0110797, Final residual = 2.33857e-06, No Iterations 3
PCG: Solving for p, Initial residual = 0.606757, Final residual = 0.0281306, No Iterations 33
time step continuity errors : sum local = 2.18226e-06, global = -7.99789e-08, cumulative = -7.99789e-08
PCG: Solving for p, Initial residual = 0.102947, Final residual = 0.0049724, No Iterations 48
time step continuity errors : sum local = 5.21564e-07, global = 8.47932e-08, cumulative = 4.8143e-09
PCG: Solving for p, Initial residual = 0.0188893, Final residual = 0.000921721, No Iterations 87
time step continuity errors : sum local = 9.13106e-08, global = -6.33622e-10, cumulative = 4.18068e-09
PCG: Solving for p, Initial residual = 0.00395311, Final residual = 9.95545e-07, No Iterations 141
time step continuity errors : sum local = 1.02719e-10, global = -6.20499e-12, cumulative = 4.17447e-09
ExecutionTime = 9.27 s ClockTime = 10 s

Sometimes my calculation stops with a floating point exception (but no more information) but when started again from last timestep is likely to keep working for some time. Checkmesh gives no error. Any hint wether these two are pure coincidence or is my mesh to bad. Otherwise the results seem OK. I can share the case if anyone cares to see it.
Thanks in advance,
Pal

waterboy

January 22, 2009 09:02

Hi again, After some successe

waterboy

January 22, 2009 09:04

Hi again, After some successe

waterboy

January 22, 2009 09:10

Hi again, After some successe

hjasak

January 22, 2009 11:20

I have no idea - it works real

I have no idea - it works really well over here. Try running a debug version and trace back the core to find out what happened.

Hrv

mbeaudoin

January 22, 2009 13:11

Please send your complete test

Please send your complete test case, including the content of your main OF_1.5-dev controlDict in order to see your tolerance factor values.

Martin

waterboy

January 22, 2009 16:08

Hi Martin, Thanks for Your he

Hi Martin,
Thanks for Your help. I will send You everything next tuesday, please provide me with some information on where to send it... You can email me at
pal . schmitt at tu - harburg . de
without whitespaces:-)
See You,
Have a great weekend:-),
Pal

mbeaudoin

January 22, 2009 21:02

Click on my name, the little b

Click on my name, the little blue string just above this sentence.

Martin

david

January 23, 2009 06:40

Hi all I have a question co

Hi all

I have a question concerning the correction vectors for GGI patches in OF-1.5-dev. In the current version a zero vector is returned for the correction vector. A different solution (similar to coupled patches) is also implemented but commented out. I understand that his correction is necessary for cases like the ERCOFTAC diffuser Case0 with a GGI at cross section B.

My question is the following. The GGI patches have to distinguish between master and slave. Wouldn't it be consistent to do this also for the calculation of the correction vectors?

if (master())
{
const scalarField& patchDeltaCoeffs = deltaCoeffs();

vectorField patchDeltas = delta();
vectorField n = nf();

cv = n - patchDeltas*patchDeltaCoeffs;
}
else
{
const scalarField& patchDeltaCoeffs = shadow().deltaCoeffs();

vectorField patchDeltas = shadow().delta();
vectorField n = shadow().nf();

cv = interpolate(-n + patchDeltas*patchDeltaCoeffs);
}

Or wouldn't that be correct?

Regards
david

hjasak

January 23, 2009 10:16

Interesting, but very very dan

Interesting, but very very dangerous.

1) in GGI i synthensise virtual cell centres right in front of master cell centres using interpolation, With those cell centres, non-orthogonal correction is zero: that is how I made them. Therefore, the correct correction should be zero, right?

2) the second viewpoint is that we can have facets from intersections that pick up its own non-orthogonal correction, which should be fully taken into account. Unfortunately, this means that I do not have enough non-orthogonal correction vectors (I need one for each weight). Thus: I need to to weighted interpolation.

However, getting even a small error in non-orthogonal correction, I will get a mass ocnservation error, which is very very dangerous.

So, on balance and with reference to point 1, I switched the projection off. Feel free to switch the other one on and test it to death for mass conservation.

Hope this helps,

Hrv

david

January 25, 2009 19:03

Hi Hrv I see the problem. I

Hi Hrv

I see the problem. I will test it and kepp a special eye on the mass conservation. I assume that it's not reasonable to define a knock-out criterion for it. The best way to judge the quality of the results will probably be the comparison of the different procedures.

Thanks a lot

David

waterboy

January 27, 2009 04:59

Hi Martin, I couldn't get pas

Hi Martin,
I couldn't get past gmail security so I need to upload the file here...

Thanks a lot for Your help,
Pal

christinasmuda

January 29, 2009 12:04

Hi, did you find out anyth

Hi,

did you find out anything about the warnings from function GGIInterpolation coming up when using the mixerGgiFvMesh? I'm having the same warnings when running my case.

Thanks,
Christina

mbeaudoin

January 29, 2009 23:10

Hello Christina, Without an

Hello Christina,

Without any information about your case or mesh, I cannot help you much.

I am currently working with Pal's case and this turns out to be quite an interesting exercise.

In his case, the Warnings are generated by the presence of concave facets in the GGI patches.

His mesh was generated using snappyHexMesh, which seems to allow the generation of concave facets.

The presence of concave facets in the GGI patches is a problem because the computation of the GGI weighting factors is based on cutting, and the Sutherland-Hodgman algorithm actually doing the intersection requires convex facets only.

The Warning simply means that some intersecting facets have been properly identified, but the intersection area between the facets turns out to be zero, which is non-sense.

Two solutions for this problem:

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 don't know if this is advisable, and I don't know how this mesh would turn out. I have not played much with snappyHexMesh so far.

2: For the current GGI implementation, replace the Sutherland-Hodgman algorithm by some other cutting algorithm that is robust in the presence of concave facets. I already know which algorithm I want to use for this, it is just a matter of coding it.

But I need to explore this problem a little bit more before actually considering replacing the Sutherland-Hodgman algorithm for the GGI.

I will keep you posted.

Martin

waterboy

February 3, 2009 10:53

Hi, I changed my mesh so it w

Hi,
I changed my mesh so it won't have concave faces on the patch, didn't help.
Any idea?

louisgag

February 9, 2009 16:59

Hi Pal, same problem here.

Hi Pal,

same problem here. I get floating point exceptions on the occasion with GGI and haven't figured out yet what causes them. It also seems that starting from a previously saved timestep will not necessarily reproduce the floating point error, at least not at the same calculation time.

cheers,

-Louis

mbeaudoin

February 9, 2009 18:19

@Pal: as I told you before, yo

@Pal: as I told you before, you still have concave faces in your mesh generated with snappyHexMesh, even though checkMesh is not reporting them. Use the latest version of checkMesh from 1.5-dev, and adjust the tolerance factors.

@Louis: not enough information to help you much.

Martin

christinasmuda

February 11, 2009 07:21

Hello Martin, thank you for

Hello Martin,

thank you for your explanation. Since I'm using snappyHexMesh for 3d mesh generation, too, probably concave faces cause the same warning as in Pal's case. If you have any news on this, it would be great if you could let me know.

In the meanwhile I started to use the icoDyMFoam solver with mixerGgiFvMesh with a simpler geometry (2d) in order to get a feeling for the solver and to develop my own solver including energy equation with viscous heating, etc. But unfortunately I already failed running the standard icoDyMFoam solver with mixerGgiFvMesh for my case.

I already ran the same geometry using sliding interfaces in OpenFoam (mixerFvMesh) and after increasing the number of PISO correctors it converged very well to the expected solution.

When I switched to mixerGgiFvMesh the solution wouldn't converge anymore. I always get a floating point error - no matter which solver settings I choose.

Since you are one of the experts in GGIs, I would like to ask you, whether you could maybe have a look at my case. I already described the problem in a different thread ( http://www.cfd-online.com/OpenFOAM_Discus/messages/1/10945.html?1233939941). My case is also posted there.

It would be great if you could give me a hint on what I could change in order to make the case run better. I'm almost in to giving up on OpenFoam and returning back to Fluent, even though I prefer OpenFoam.

Thank you very much,
Christina

mbeaudoin

February 11, 2009 11:02

Hello Christina, Sure, I wi

Hello Christina,

Sure, I will take a look. Be patient though, I am kind of stuck on other activities for the coming week or so.

I have downloaded your rotor2Dggi.rar archive. Is this the latest version available?

If not, I would appreciate if you could send me your latest case version as well. Just click on my name to grab my Email address.

Martin

All times are GMT -4. The time now is 03:53.

Page 2 of 4

Show 40 post(s) from this thread on one page