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

GGI Tolerance

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

Reply
 
LinkBack Thread Tools Display Modes
Old   May 10, 2011, 02:20
Default GGI Tolerance
  #1
New Member
 
Join Date: Mar 2011
Posts: 9
Rep Power: 6
taner is on a distinguished road
Dear all,

I'm using GGI capabilities of openfoam-1.6-ext. And comparing simulation results to the Fluent results. Unfortunately there is a considerable difference between both results, especially flow through GGI. Part of the boundary file regarding GGI looks like:

outer_lower
{
type ggi;
nFaces 25662;
startFace 8184218;
shadowPatch RH_lower;
zone outer_lower_zone;
bridgeOverlap true;
}
outer_upper
{
type ggi;
nFaces 27300;
startFace 8209880;
shadowPatch RH_upper;
zone outer_upper_zone;
bridgeOverlap true;
}
RH_lower
{
type ggi;
nFaces 538;
startFace 8237180;
shadowPatch outer_lower;
zone RH_lower_zone;
bridgeOverlap true;
}
RH_upper
{
type ggi;
nFaces 538;
startFace 8237718;
shadowPatch outer_upper;
zone RH_upper_zone;
bridgeOverlap true;
}


Two GGI are non-matching, one face is much smaller than the other in both. I guess, for this reason I get the following message at the beginning of the simulation:

Initializing the GGI interpolator between master/shadow patches: outer_lower/RH_lower

From function void GGIInterpolation<MasterPatch, SlavePatch>::rescaleWeightingFactors() const
in file /build/buildd/openfoam-1.6-ext-1.6.0/OpenFOAM-1.6-ext/src/OpenFOAM/lnInclude/GGIInterpolationWeights.C at line 535
Uncovered faces found. On master: 25324 on slave: 0
Initializing the GGI interpolator between master/shadow patches: outer_upper/RH_upper

From function void GGIInterpolation<MasterPatch, SlavePatch>::rescaleWeightingFactors() const
in file /build/buildd/openfoam-1.6-ext-1.6.0/OpenFOAM-1.6-ext/src/OpenFOAM/lnInclude/GGIInterpolationWeights.C at line 535
Uncovered faces found. On master: 26766 on slave: 0


Additionally, I should mention that the dimensions are too small, in the order of micrometers.

My question is:
- Is there a tolerance parameter for mesh cutting operations or for polygon clipping which might be responsible for the difference in flow through GGI?

Thanks in advance.

Regards
Taner
taner is offline   Reply With Quote

Old   May 11, 2011, 16:02
Default
  #2
Senior Member
 
Martin Beaudoin
Join Date: Mar 2009
Posts: 330
Rep Power: 13
mbeaudoin will become famous soon enough
Hello,

There is indeed a couple of tolerance factors in place for the GGI cutting algorithm in order to reject GGI patch faces intersection when the intersection area is too small.

Basically, the cutting algorithm will reject any intersection smaller that a given tolerance factor times the surface area of the smallest of the two polygons being tested for intersection.

By default, the tolerance factor being used by the cutting algorithm is 1.0e-8.
This is the tolerance factor called GGIAreaErrorTol in your main or global controlDict file.

This means that for your mesh, the cutting algorithm will reject any intersection area of the order of 1.0e-6 x 1.0e-6 x 1.0e-8 = 1.0e-20 m^2. That's pretty small.

Your ratio of master faces to slave faces is roughly 50 to 1, which is not that big.

The fact that 98% (25324 out of 25662) of your faces are discarded as non-overlapping is an indication that something else is at work here. And you need to fix this because with 98% of non-overlapping faces, this is no longer a GGI interface your looking at.

You might have a radical misalignment of the master/slave patches. Are you using periodic or cyclic patches?

Or you might have an important number of convave faces in your patches. The current GGI face cutting algorithm does not support concave faces.

Also make sure your mesh converter for OpenFOAM gave you all the necessary precision for the mesh point coordinates.

Martin


Quote:
Originally Posted by taner View Post
Dear all,

I'm using GGI capabilities of openfoam-1.6-ext. And comparing simulation results to the Fluent results. Unfortunately there is a considerable difference between both results, especially flow through GGI. Part of the boundary file regarding GGI looks like:

outer_lower
{
type ggi;
nFaces 25662;
startFace 8184218;
shadowPatch RH_lower;
zone outer_lower_zone;
bridgeOverlap true;
}
outer_upper
{
type ggi;
nFaces 27300;
startFace 8209880;
shadowPatch RH_upper;
zone outer_upper_zone;
bridgeOverlap true;
}
RH_lower
{
type ggi;
nFaces 538;
startFace 8237180;
shadowPatch outer_lower;
zone RH_lower_zone;
bridgeOverlap true;
}
RH_upper
{
type ggi;
nFaces 538;
startFace 8237718;
shadowPatch outer_upper;
zone RH_upper_zone;
bridgeOverlap true;
}


Two GGI are non-matching, one face is much smaller than the other in both. I guess, for this reason I get the following message at the beginning of the simulation:

Initializing the GGI interpolator between master/shadow patches: outer_lower/RH_lower

From function void GGIInterpolation<MasterPatch, SlavePatch>::rescaleWeightingFactors() const
in file /build/buildd/openfoam-1.6-ext-1.6.0/OpenFOAM-1.6-ext/src/OpenFOAM/lnInclude/GGIInterpolationWeights.C at line 535
Uncovered faces found. On master: 25324 on slave: 0
Initializing the GGI interpolator between master/shadow patches: outer_upper/RH_upper

From function void GGIInterpolation<MasterPatch, SlavePatch>::rescaleWeightingFactors() const
in file /build/buildd/openfoam-1.6-ext-1.6.0/OpenFOAM-1.6-ext/src/OpenFOAM/lnInclude/GGIInterpolationWeights.C at line 535
Uncovered faces found. On master: 26766 on slave: 0


Additionally, I should mention that the dimensions are too small, in the order of micrometers.

My question is:
- Is there a tolerance parameter for mesh cutting operations or for polygon clipping which might be responsible for the difference in flow through GGI?

Thanks in advance.

Regards
Taner
mbeaudoin is offline   Reply With Quote

Old   May 12, 2011, 05:35
Default
  #3
New Member
 
Join Date: Mar 2011
Posts: 9
Rep Power: 6
taner is on a distinguished road
Hi Martin,

the case that I would like to solve is actually a non-conformal mesh interface problem. I have tried to solve it with "stitchMesh" tool, but it does not generate a reasonable interface mesh. I just prepared a simplified sketch to describe the problem better. There are two cylindrical regions connected with a single pipe as in the following:



Mesh of the cylindrical regions are generated with an other tool than the connecting pipe. Area of the control volume faces is similar at the interface (not the case in the sketch).

Thanks in advance.

Taner
taner is offline   Reply With Quote

Old   May 13, 2011, 08:59
Default
  #4
Senior Member
 
Martin Beaudoin
Join Date: Mar 2009
Posts: 330
Rep Power: 13
mbeaudoin will become famous soon enough
Hello Taner,

Looks like you've posted an image in real micrometer dimensions because I can't see a thing. Would you mind zooming in your picture for me and post a new one?

Martin


Quote:
Originally Posted by taner View Post
Hi Martin,

the case that I would like to solve is actually a non-conformal mesh interface problem. I have tried to solve it with "stitchMesh" tool, but it does not generate a reasonable interface mesh. I just prepared a simplified sketch to describe the problem better. There are two cylindrical regions connected with a single pipe as in the following:



Mesh of the cylindrical regions are generated with an other tool than the connecting pipe. Area of the control volume faces is similar at the interface (not the case in the sketch).

Thanks in advance.

Taner
mbeaudoin is offline   Reply With Quote

Old   May 16, 2011, 03:46
Default
  #5
New Member
 
Join Date: Mar 2011
Posts: 9
Rep Power: 6
taner is on a distinguished road
Hi Martin,

I don't know why you cannot see the sketch properly. I'm posting it again in a different size. Hope this works.

Taner


taner is offline   Reply With Quote

Old   May 16, 2011, 13:27
Default
  #6
Senior Member
 
Martin Beaudoin
Join Date: Mar 2009
Posts: 330
Rep Power: 13
mbeaudoin will become famous soon enough
Nope. No image is showing up with your message.

From my Email archive, I can see that you are trying to share a file called taner-albums-ggi-picture237-ggi-problem-1.jpg

This is the URL for this file: Image: http://www.cfd-online.com/Forums/mem...-problem-1.jpg

When downloading this file, all we get is a 1 pixel x 1 pixel GIF file called taner-albums-ggi-picture237-ggi-problem-1.jpg.

This is probably just a file format problem...

Martin

Quote:
Originally Posted by taner View Post
Hi Martin,

I don't know why you cannot see the sketch properly. I'm posting it again in a different size. Hope this works.

Taner


mbeaudoin is offline   Reply With Quote

Old   May 19, 2011, 08:19
Default
  #7
New Member
 
Join Date: Mar 2011
Posts: 9
Rep Power: 6
taner is on a distinguished road
Hi Martin,

part of the model and mesh (only upper ggi) is shown in the following images. Mesh is shown only for one ggi, other one is principally the same having slightly larger dimensions.

1) part of the model including upper and lower ggi:


2) mesh of the outer_upper patch:


3) mesh of the RH_upper patch (only the circular area):


4) combined grid of outer_upper and RH_upper:


Hope this time the images can be viewed without any problems.

Regards
Taner
taner is offline   Reply With Quote

Old   May 19, 2011, 10:06
Default
  #8
Senior Member
 
Martin Beaudoin
Join Date: Mar 2009
Posts: 330
Rep Power: 13
mbeaudoin will become famous soon enough
Hello,

The actual implementation of the GGI cannot handle this kind of patch topology.

You will need to "dissect" your outer_upper patch into GGI areas (where the RH_upper patch overlays the outer_upper patch ) in order to match the RH_upper patch as closely as possible, and set a different kind boundary condition for the rest of the non-overlapped section of the outer_upper patch.

The mix and match of very dissimilar patch geometries like the ones you are trying to use is currently not supported by the GGI.

This is why you are getting such a large number of non-overlapped faces.

Martin
mbeaudoin is offline   Reply With Quote

Old   May 19, 2011, 10:23
Default
  #9
Senior Member
 
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 386
Rep Power: 15
deepsterblue will become famous soon enough
Martin,

I have a suggestion for the GGI intersection algorithm, which may not require tolerance factors altogether.

Please take a look at the convexSetAlgorithms in:
http://openfoam-extend.git.sourcefor...amicTopoFvMesh

More specifically, the faceSetAlgorithm bit might be interesting to you (it's still restricted to convex polygons, though). I think this would work better for you in terms of efficiency and numerical robustness. Would you like to give it a try?
__________________
Sandeep Menon
University of Massachusetts Amherst
https://github.com/smenon
deepsterblue is offline   Reply With Quote

Old   May 19, 2011, 18:20
Default
  #10
Senior Member
 
Martin Beaudoin
Join Date: Mar 2009
Posts: 330
Rep Power: 13
mbeaudoin will become famous soon enough
Hello Sandeep,

Thanks for pointing me to this algorithm.

As you know, there is a lot of nice cutting algorithms available out there, or at least well documented.

The cutting algorithm chosen for the computation of the GGI weighting factors is the very fast, efficient and well-known Sutherland-Hodgman algorithm (S-H).

As of now, I don't think the efficiency and numerical robustness of the S-H cutting algorithm chosen for the GGI is a major issue for this interface.

As for the tolerance factor, this is something I added myself to the algorithm in order to bring more numerical robustness when dealing with intersection surface area of the order of small epsilons, or for edge-to-edge intersection of almost parallel lines.

One can always set this tolerance factor to 0.0, and see how it goes, but from my experience, when confronted with numerical round-off and numerical robustness for algorithms applied to complex "industrial grade" meshes, I tend to prefer an algorithm with added robustness.

There is a couple of little robustness features like this that were added to the GGI interface in order to make it robust and fully conservative.

One could try to compare both cutting algorithms for speed and robustness, of course, but I myself will prefer to spend time on a cutting algorithm that support both convex and concave faces instead, and on some other issues related to the performance of the GGI interface when running in parallel.

Setting up a test framework and test application/data for cutting algorithms could be an interesting activity though.
That way, one could compare the performance and robustness of various cutting algorithms available for OF based on cold hard facts like performance profiling results.
Let's talk about this a little bit later if you are interested.

Best regards,

Martin
mbeaudoin is offline   Reply With Quote

Old   July 5, 2011, 09:31
Default
  #11
Senior Member
 
Join Date: Apr 2010
Posts: 151
Rep Power: 7
flowris is on a distinguished road
Hello,

I am also having troubles with ggi. I also have a case which gives the warning
Code:
Uncovered faces found.
I understand that some faces on the sliding interfaces cannot "see" any matching face, but why is this so?

Attached is the case. Do you mind taking a look at it, please? To run it, please do
Code:
./rc 
moveDynamicMesh
and then you will find the warning.
Attached Files
File Type: zip case.zip (12.2 KB, 10 views)
flowris is offline   Reply With Quote

Old   July 11, 2011, 08:48
Default
  #12
Senior Member
 
Join Date: Apr 2010
Posts: 151
Rep Power: 7
flowris is on a distinguished road
Quote:
Also make sure your mesh converter for OpenFOAM gave you all the necessary precision for the mesh point coordinates.
Can anybody tell me how to increase the tolerance for the gmshToFoam converter? My .msh file has 16 digits of precision for the point coordinates, but they get truncated to only 6 in the converted file constant/polyMesh/points.
flowris is offline   Reply With Quote

Old   July 11, 2011, 09:38
Default
  #13
Senior Member
 
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 386
Rep Power: 15
deepsterblue will become famous soon enough
The precision is probably set by the writePrecision entry in controlDict. Try set (or add) that entry to 16 and test again...
__________________
Sandeep Menon
University of Massachusetts Amherst
https://github.com/smenon
deepsterblue is offline   Reply With Quote

Old   July 12, 2011, 03:20
Default
  #14
Senior Member
 
Join Date: Apr 2010
Posts: 151
Rep Power: 7
flowris is on a distinguished road
Too bad: I tried this already, with no success.
flowris is offline   Reply With Quote

Old   July 12, 2011, 14:11
Default
  #15
Senior Member
 
Martin Beaudoin
Join Date: Mar 2009
Posts: 330
Rep Power: 13
mbeaudoin will become famous soon enough
I just did a quick check by converting a .msh file with gmshToFoam.

Just for fun, I asked for 40 digits numbers by setting the writePrecision entry in the case controlDict to 40.

And I basically got 40 digits numbers in the file constant/polyMesh/points.

gmshToFoam is one of the few converters where the output precision is not hardcoded directly into the converter source code.

The following converters seem to force the number of digits for their outputs to 10, no matter the value you set for the entry writePrecision in the case controlDict:
  • ansysToFoam
  • cfx4ToFoam
  • fluent3DMeshToFoam
  • fluentMeshToFoam
  • gambitToFoam
  • plot3dToFoam
  • sammToFoam
  • star4ToFoam
  • starToFoam

This is from OF-1.6-ext.
I have not tested all of them, but they all override the default output precision to 10 digits using the following call in their source code:

IOstream::defaultPrecision(10);

Martin

Quote:
Originally Posted by flowris View Post
Too bad: I tried this already, with no success.
mbeaudoin is offline   Reply With Quote

Old   July 13, 2011, 01:34
Default
  #16
Senior Member
 
Join Date: Apr 2010
Posts: 151
Rep Power: 7
flowris is on a distinguished road
Aha, I thought we were talking about the global controlDict. Thank you very much!
flowris is offline   Reply With Quote

Old   February 6, 2012, 12:22
Default ggi interface for simple case
  #17
Member
 
jk
Join Date: Jun 2009
Posts: 64
Rep Power: 8
jyothishkumar is on a distinguished road
Dear Martin,

I am working on the compressor of turbocharger. I have to use openfoam to simulate the unsteadyness of the flow in the compressor. I have installed openfoam-1.6-ext and trying some simple stuff like using ggi to connect two nonconformal mesh region. Actually i am trying to simulate a flow thru two ducts (of same size, but different mesh count) join together. Joining region of two ducts is not conformal. I want to implement GGI interface at the two faces of the duct where it joins. I have done as follows

1. Using FluentMeshtofoam i have converted the fluent mesh to openfoam mesh for the two ducts.

2. Using Mergemeshes command in openfoam i have merged the two meshes.
(I have given INT1 and INT2 as the name of the interfaces)

3. In the Boundary file (in constant/polymesh folder) I have added the interface region as follows

INT1
{
type ggi;
nFaces 361;
startFace 40793;
shadowPatch INT2;
}

similarly for INT2.

4. In the p file (in 0/ folder) I have modified as follows

INT1
{
type ggi;
}

similary in other field like U.

5. When I run the solver (simpleFoam) i am getting the following error
Reading field p

--> FOAM FATAL ERROR:
Attempt to cast type patch to type lduInterface

From function refCast<To>(From&)
in file /scratch/jyothish/OpenFOAM/OpenFOAM-1.6-ext/src/OpenFOAM/lnInclude/typeInfo.H at line 115.

FOAM aborting

Please help me to get the solution.

thanks
jyothishkumar is offline   Reply With Quote

Old   February 7, 2012, 11:14
Default GGI error floating point exception
  #18
Member
 
jk
Join Date: Jun 2009
Posts: 64
Rep Power: 8
jyothishkumar is on a distinguished road
Can anyone help me in the following error. Following error happened when I try to run a case (a simple case - duct flow. Actually there are two ducts joined in the middle thru ggi interface). Procedure that i followed is as follows

i. Convert the mesh to openfoam (for both the ducts)
ii. mergeMesh the two ducts
setSet -batch
setsToZones - noFlipMap
do the changes in the boundary file

GGI_INT1
{
type ggi;
nFaces 838;
startFace 1107676;
shadowPatch GGI_INT2;
bridgeOverlap false;
zone GGI_INT1_ZONE;
}

GGI_INT2
{
type ggi;
nFaces 838;
startFace 1117760;
shadowPatch GGI_INT1;
bridgeOverlap false;
zone GGI_INT2_ZONE;
}

corresponding changes in the P and U file

iii. solver using icofoam.

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0

Initializing the GGI interpolator between master/shadow patches: GGI_INT1/GGI_INT2
Reading transportProperties

Reading field p

Reading field U

Reading/calculating face flux field phi

Floating point exception

------------------------------------------------------------------------

Please help me in this regards

thanks

jyothish
jyothishkumar is offline   Reply With Quote

Old   February 12, 2013, 16:58
Default
  #19
Senior Member
 
immortality's Avatar
 
Ehsan
Join Date: Oct 2012
Location: Iran
Posts: 2,205
Rep Power: 17
immortality is on a distinguished road
hi jk
did you solve the problem?can you send me your case?
thanks.
immortality 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 06:59.