[bastil]

Dear all,

I am struggling to run meshes imported from FLUENT including interfaces. AFAIK there are two options:

1. stitchMesh -> use 1.5-dev
2. ggi -> use 1.5-dev

First option works on some vanilla cases but fails on my real life geometries with various errors and large memory consumption. Could not get it running on all types of my interfaces. So I tried ggi and I am struggling:

Starting time loop

[node013:00375] *** Process received signal ***
[node013:00375] Signal: Floating point exception (8)
[node013:00375] Signal code: (-6)
[node013:00375] Failing at address: 0xb5a00000177
[node013:00375] [ 0] /lib64/libc.so.6 [0x2b57acb3ec10]
[node013:00375] [ 1] /lib64/libc.so.6(gsignal+0x35) [0x2b57acb3eb95]
[node013:00375] [ 2] /lib64/libc.so.6 [0x2b57acb3ec10]
[node013:00375] [ 3] /opt/OpenFOAM/OpenFOAM-1.5-dev/lib/linux64GccDPOpt/libOpenFOAM.so(_ZN4Foam6divid eERNS_5FieldIdEERKNS_5UListIdEES6_+0xa1) [0x2b57ac2f0c
71]

This is a simpleFOAM job in parallel. I guess I have to make sure interface is on one CPU? May this be the problem? How can I ensure this?

Are there furter options to handle FLUENT interfaces?

Regards

[bastil]

Things to add after some more tries:

- I also get a Floating point exception when running in seriell
- I do not know what "bridgeOverlap" is good for but I see the same behaviour if I turn it on or not.

Maybe some ggi-expert can provide me with some hints.

Regards

[bastil]

Ok, I oriented on the mixerGgi-tutorial and gave the ggi initial values. This does not seem to be essential. If I skip that it is running in serial but it still fails in parallel. I guess this to be a decomposition problem? How can this be solved?

Regards

[josp]

> I guess I have to make sure interface is on one CPU
Try:

preservePatches( patch1 patch2 ..)
preserveFaceZones( facezone1 faceZone2 ..)

in decomposeParDict

/Johan

[bastil]

Thanks Johan,

I can not get it running. How does decomposePar exactly have to look like? Is there an example hanging around somewhere? I always get:

ill defined primitiveEntry starting at keyword 'preservePatches(patch1' on line 19 and ending at line 62

Regards

[josp]

BastiL, I don't know if there are examples. There should be a ; at the end of the line aswell:
preservePatches(patch1 ..);

Could you post your dictionary?

[bastil]

Yes, I currently have:

/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \ / O peration | Version: 1.5 |
| \ / A nd | Web: http://www.OpenFOAM.org |
| \/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object decomposeParDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

numberOfSubdomains 32;

method hierarchical;
//method metis;

preservePatches( patch1 patch2 );

simpleCoeffs
{
n (6 1 1);
delta 0.001;
}

hierarchicalCoeffs
{
n (32 1 1);
delta 0.001;
order xyz;
}

metisCoeffs
{
//processorWeights
//(
// 1
// 1
// 1
// 1
//);
}

manualCoeffs
{
dataFile "";
}

distributed no;

roots
(

);

// ************************************************** *********************** //


And I get:
Create time

Time = 0
Create mesh

Calculating distribution of cells
Selecting decompositionMethod hierarchical


keyword hierarchicalCoeffs is undefined in dictionary "/path/to/case/system/decomposeParDict"

file: /path/to/case/system/decomposeParDict from line 17 to line 27.

From function dictionary::subDict(const word& keyword) const
in file db/dictionary/dictionary.C at line 271.

FOAM exiting

Must it be placed somewhere else?

[bastil]

Ok, miving it to the end (after roots ();) i get:

ill defined primitiveEntry starting at keyword 'preservePatches(patch1' on line 58 and ending at line 62

[josp]

I did not have access to my OpenFOAM installation earlier today.

So it should be

preservePatches (patch1 patch2); and not:
preservePatches(patch1 patch2);

Posted the decomposePar and output of a testcase below:

Good luck!

/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \ / O peration | Version: dev |
| \ / A nd | Web: http://www.OpenFOAM.org |
| \/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object decomposeParDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
numberOfSubdomains 32;

method hierarchical;
//method metis;

preservePatches (fan inlet);
preserveFaceZones (fanvol);

simpleCoeffs
{
n (6 1 1);
delta 0.001;
}

hierarchicalCoeffs
{
n (32 1 1);
delta 0.001;
order xyz;
}

metisCoeffs
{
//processorWeights
//(
// 1
// 1
// 1
// 1
//);
}

manualCoeffs
{
dataFile "";
}

distributed no;

roots
(

);

// ************************************************** *********************** //
~


On my system this gives
/*---------------------------------------------------------------------------*\
| ========= | |
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \ / O peration | Version: 1.5-extend |
| \ / A nd | Web: http://www.OpenFOAM.org |
| \/ M anipulation | |
\*---------------------------------------------------------------------------*/
Exec : decomposePar
Date : Mar 10 2009
Time : 12:56:13
Host : linux3
PID : 9741
Case : Ggi
nProcs : 1

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

Time = 0.00688181
Create mesh

Calculating distribution of cells
Keeping owner and neighbour of faces in patches
2
(
fan
inlet
)
on same processor
Keeping owner and neighbour of faces in zones
1
(
fanvol
)
on same processor
Selected 1183862 faces whose owner and neighbour cell should be kept on the same processor
Selecting decompositionMethod hierarchical

Finished decomposition in 0.44 s

Calculating original mesh data

Distributing cells to processors

Distributing faces to processors

Calculating processor boundary addressing

Distributing points to processors

Constructing processor meshes

Processor 0
Number of cells = 5654
Number of faces shared with processor 1 = 1229
Number of processor patches = 1
Number of processor faces = 1229
Number of boundary faces = 1743

Processor 1
Number of cells = 5654
Number of faces shared with processor 0 = 1229
Number of faces shared with processor 2 = 1689
Number of processor patches = 2
Number of processor faces = 2918
Number of boundary faces = 1050

...

[bastil]

Thanks looks good. Seems to work now for my purposes. Only thing I am struggling with is a GGicheck-Function that makes my calculation crashing after iteration 1, Withaiut that it seems to run fine.

Regards.

[bastil]

Ok I have run some tests, most run fine some are struggling. I guess this has to do with tolerances I get warnings (will post one later) How can tolerance be controlled? And I am still wondering about the bridgeOverlap parameter - what is it good for?

[bastil]

Ok on a non running case i get something like this:

Evaluation of GGI weighting factors:
--> FOAM Warning :
From function Foam::SutherlandHodgman::lineSegmentIntersection()
in file algorithms/polygon/clipping/SutherlandHodgman.C at line 109
ua does not match with ub: delta: 1.83103e-15 : epsilon: 1e-15

and:

Evaluation of GGI weighting factors:

From function void GGIInterpolation<masterpatch,>::rescaleWeightingFa ctors() const
in file /opt/OpenFOAM/OpenFOAM-1.5-dev/src/OpenFOAM/lnInclude/GGIInterpolationWeights.C at line 531
Uncovered faces found: on master:0 on slave: 165
Largest slave weighting factor correction : 0.998995 average: 0.0234367
Largest master weighting factor correction: 0.0314782 average: 0.00255351

I expect at least one of these to be the problem why this case is not running. How can I find out which of my ggis cause the problem? Secnd warning sounds like there is no suport for partial ggi so far? Thanks for clarification.

Regards

[sponiar]

Hello all,
Bastil, I am just preparing very simple testing case with ggi. This test may help me to understand how to set up case with interfaces / ggi.

This testing case looks like cavity with upper mowing wall. The cavity domain is split into the 3 blocks (see Figure 1, 2).

Fig 1.: 3 blocks, split with ggi


__________


Fig 2.: 3 blocks with mesh looks like


__________


After sucessfull runnig case, I would like use ggi with more complex geometry, where I have to use retriangulation interface which is neighbour to the side of the prismatic layer (see Figure 3)

Fig 3.: complex geometry with quad and tri interface (source TGrid mesh)


__________


Attach simple case with gambit mesh.




May I ask you for helping me with set-up case.
David

[sponiar]

I hope in sucessful picture attach.

Fig 1.: 3 blocks, split with ggi

__________


Fig 2.: 3 blocks with mesh looks like

__________


Fig 3.: complex geometry with quad and tri interface (source TGrid mesh)

__________

Attach simple case with gambit mesh:

[sponiar]

Hello again,
Mattijs wrote me, that discusion board is some time full and the web browser does not responce to the attaching files.

So I attach all picture and testing case here:
http://drop.io/dsponiar

I hope this would be functional - it is for me for the first time, what I attach file any at the "on-line space".

Ragards,
David
_____

[hjasak]

All of these GGIs will work without any trouble. For a really cool (and really new) one, have a look at: OpenFOAM: VOF + 6-DOF + GGI


Hrv

[sponiar]

Hello Hrvoje,
thanks for sharing nice animation. I think for me, it is so far to simulate this complex phenomenom.

Yesterday, I was building the newest OF release and testing GGI.
When I start simulation with cavity (mesh prepare in Gambit) split into the 3 blocks, I found this log:

Exec : simpleFoam -case 18-GGI_interface_OF-1.5-dev
Date : Mar 12 2009
Time : 12:45:01
Host : sponiar
PID : 29352
Case : ./18-GGI_interface_OF-1.5-dev
nProcs : 1

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

Create mesh for time = 0

Reading field p

Reading field U

Reading/calculating face flux field phi

Evaluation of GGI weighting factors:
Largest slave weighting factor correction : 1.19209e-07 average: 8.34465e-08
Largest master weighting factor correction: 1.19209e-07 average: 4.76837e-08

Evaluation of GGI weighting factors:
Largest slave weighting factor correction : 1.19209e-07 average: 1.19209e-08
Largest master weighting factor correction: 1.19209e-07 average: 1.78814e-08

Evaluation of GGI weighting factors:
Largest slave weighting factor correction : 1.19209e-07 average: 2.98023e-08
Largest master weighting factor correction: 1.78814e-07 average: 5.07743e-08

Selecting incompressible transport model Newtonian
Selecting RAS turbulence model laminar

Starting time loop

Creating ggi check
Time = 1

PBiCG: Solving for Ux, Initial residual = 1, Final residual = 1.52828e-06, No Iterations 8
PBiCG: Solving for Uy, Initial residual = 1, Final residual = 7.84278e-06, No Iterations 7


Continuity error cannot be removed by adjusting the outflow.
Please check the velocity boundary conditions and/or run potentialFoam to initialise the outflow.
Specified mass inflow : 5.25403e-07
Specified mass outflow : 0
Difference : 5.25403e-07
Adjustable mass outflow : 5.25403e-07


From function adjustPhi
(
surfaceScalarField& phi,
const volVectorField& U,
const volScalarField& p
)
in file cfdTools/general/adjustPhi/adjustPhi.C at line 128.

FOAM exiting


I tried to set up ggi with some initialization value for velocity and pressure, but the same error occured.

Any hint?
Regards,
David
______

[bastil]

Hallo Hrv,

thanks for these hints. What about my two warnings? I found out that removing the second warning " Uncovered faces found" makes my simulation to run. this seems to be caused by "partial" interfaces, right? Are there plans to implement partial interfaces?
What about first warning?

Thanks BastiL

[hjasak]

If you have uncovered faces, you need to use bridging, otherwise their values are undefined. Regarding the other warning, it is to do with the accuracy of your geometry - 1e-15 does not sound too bad. Martin and I will probably re-tune the tolerances once we get enough experience with the real cases.

Hrv

[bastil]

Thanks Hrv for this explanation,

so I only use brigding if I get this warning? Or always? I don't really understand what bridging is intended for?
The GGIs with "uncovered faces" are definitely partial once. Will this work with bridging turned on? Thanks once more.

Regards BastiL