[taner]

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]

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

Originally Posted by taner

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]

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]

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

Originally Posted by taner

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]

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]

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

Originally Posted by taner

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]

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

[mbeaudoin]

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

[deepsterblue]

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?

[mbeaudoin]

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

[flowris]

Hello,

I am also having troubles with ggi. I also have a case which gives the warning

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

./rc 
moveDynamicMesh

and then you will find the warning.

[flowris]

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.

[deepsterblue]

The precision is probably set by the writePrecision entry in controlDict. Try set (or add) that entry to 16 and test again...

[flowris]

Too bad: I tried this already, with no success.

[mbeaudoin]

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

Originally Posted by flowris

Too bad: I tried this already, with no success.

[flowris]

Aha, I thought we were talking about the global controlDict. Thank you very much!

[jyothishkumar]

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]

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

[immortality]

hi jk
did you solve the problem?can you send me your case?
thanks.