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

Any update on mixerGgiFvMesh

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

Reply
 
LinkBack Thread Tools Display Modes
Old   November 4, 2008, 17:56
Default Dear Prof. Jasak, Thanks alot
  #21
New Member
 
Pal Schmitt
Join Date: Mar 2009
Posts: 28
Rep Power: 8
waterboy is on a distinguished road
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 is offline   Reply With Quote

Old   January 22, 2009, 09:59
Default Hi again, After some successe
  #22
New Member
 
Pal Schmitt
Join Date: Mar 2009
Posts: 28
Rep Power: 8
waterboy is on a distinguished road
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 is offline   Reply With Quote

Old   January 22, 2009, 10:02
Default Hi again, After some successe
  #23
New Member
 
Pal Schmitt
Join Date: Mar 2009
Posts: 28
Rep Power: 8
waterboy is on a distinguished road
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 is offline   Reply With Quote

Old   January 22, 2009, 10:04
Default Hi again, After some successe
  #24
New Member
 
Pal Schmitt
Join Date: Mar 2009
Posts: 28
Rep Power: 8
waterboy is on a distinguished road
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 is offline   Reply With Quote

Old   January 22, 2009, 10:10
Default Hi again, After some successe
  #25
New Member
 
Pal Schmitt
Join Date: Mar 2009
Posts: 28
Rep Power: 8
waterboy is on a distinguished road
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 is offline   Reply With Quote

Old   January 22, 2009, 12:20
Default I have no idea - it works real
  #26
Senior Member
 
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,763
Rep Power: 21
hjasak will become famous soon enough
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
__________________
Hrvoje Jasak
Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk
hjasak is offline   Reply With Quote

Old   January 22, 2009, 14:11
Default Please send your complete test
  #27
Senior Member
 
Martin Beaudoin
Join Date: Mar 2009
Posts: 330
Rep Power: 13
mbeaudoin will become famous soon enough
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
mbeaudoin is offline   Reply With Quote

Old   January 22, 2009, 17:08
Default Hi Martin, Thanks for Your he
  #28
New Member
 
Pal Schmitt
Join Date: Mar 2009
Posts: 28
Rep Power: 8
waterboy is on a distinguished road
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
waterboy is offline   Reply With Quote

Old   January 22, 2009, 22:02
Default Click on my name, the little b
  #29
Senior Member
 
Martin Beaudoin
Join Date: Mar 2009
Posts: 330
Rep Power: 13
mbeaudoin will become famous soon enough
Click on my name, the little blue string just above this sentence.

Martin
mbeaudoin is offline   Reply With Quote

Old   January 23, 2009, 07:40
Default Hi all I have a question co
  #30
Member
 
David Hora
Join Date: Mar 2009
Location: Zürich, Switzerland
Posts: 63
Rep Power: 8
david is on a distinguished road
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
david is offline   Reply With Quote

Old   January 23, 2009, 11:16
Default Interesting, but very very dan
  #31
Senior Member
 
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,763
Rep Power: 21
hjasak will become famous soon enough
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
__________________
Hrvoje Jasak
Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk
hjasak is offline   Reply With Quote

Old   January 25, 2009, 20:03
Default Hi Hrv I see the problem. I
  #32
Member
 
David Hora
Join Date: Mar 2009
Location: Zürich, Switzerland
Posts: 63
Rep Power: 8
david is on a distinguished road
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
david is offline   Reply With Quote

Old   January 27, 2009, 05:59
Default Hi Martin, I couldn't get pas
  #33
New Member
 
Pal Schmitt
Join Date: Mar 2009
Posts: 28
Rep Power: 8
waterboy is on a distinguished road
Hi Martin,
I couldn't get past gmail security so I need to upload the file here...

Thanks a lot for Your help,
Pal
waterboy is offline   Reply With Quote

Old   January 29, 2009, 13:04
Default Hi, did you find out anyth
  #34
New Member
 
Christina Smuda
Join Date: Mar 2009
Location: Germany
Posts: 12
Rep Power: 8
christinasmuda is on a distinguished road
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
christinasmuda is offline   Reply With Quote

Old   January 30, 2009, 00:10
Default Hello Christina, Without an
  #35
Senior Member
 
Martin Beaudoin
Join Date: Mar 2009
Posts: 330
Rep Power: 13
mbeaudoin will become famous soon enough
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
mbeaudoin is offline   Reply With Quote

Old   February 3, 2009, 11:53
Default Hi, I changed my mesh so it w
  #36
New Member
 
Pal Schmitt
Join Date: Mar 2009
Posts: 28
Rep Power: 8
waterboy is on a distinguished road
Hi,
I changed my mesh so it won't have concave faces on the patch, didn't help.
Any idea?


waterboy is offline   Reply With Quote

Old   February 9, 2009, 17:59
Default Hi Pal, same problem here.
  #37
Senior Member
 
louisgag's Avatar
 
Louis Gagnon
Join Date: Mar 2009
Location: Québec, QC, Canada
Posts: 208
Rep Power: 9
louisgag is on a distinguished road
Send a message via ICQ to louisgag
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
louisgag is offline   Reply With Quote

Old   February 9, 2009, 19:19
Default @Pal: as I told you before, yo
  #38
Senior Member
 
Martin Beaudoin
Join Date: Mar 2009
Posts: 330
Rep Power: 13
mbeaudoin will become famous soon enough
@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
mbeaudoin is offline   Reply With Quote

Old   February 11, 2009, 08:21
Default Hello Martin, thank you for
  #39
New Member
 
Christina Smuda
Join Date: Mar 2009
Location: Germany
Posts: 12
Rep Power: 8
christinasmuda is on a distinguished road
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
christinasmuda is offline   Reply With Quote

Old   February 11, 2009, 12:02
Default Hello Christina, Sure, I wi
  #40
Senior Member
 
Martin Beaudoin
Join Date: Mar 2009
Posts: 330
Rep Power: 13
mbeaudoin will become famous soon enough
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
mbeaudoin 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
velocity update fluent_urs FLUENT 6 July 8, 2008 11:41
FLEXlm update or ?? Kasper Skriver CD-adapco 2 March 1, 2007 11:38
IcoTopoFoam update hjasak OpenFOAM Running, Solving & CFD 0 March 28, 2005 21:32
UDF update profile ramesh FLUENT 0 June 29, 2003 14:14
MOUSE - any update? Pei-Ying Hsieh Main CFD Forum 1 March 19, 2001 06:04


All times are GMT -4. The time now is 09:57.