CFD Online Discussion Forums - Problem with decomposePar tool

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

- OpenFOAM Pre-Processing (https://www.cfd-online.com/Forums/openfoam-pre-processing/)

- - Problem with decomposePar tool (https://www.cfd-online.com/Forums/openfoam-pre-processing/69457-problem-decomposepar-tool.html)

vinz	October 23, 2009 09:29

Problem with decomposePar tool

Dear Openfoamers,

I have a problem while trying to decompose one of my cases in order to run it in parallel. In this case, I have a cyclic patch which seems to be the problem even if I already used such patches in other cases without any problem.

Here is the output of decomposePar:
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 1.6 |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : 1.6-53b7f692aa41
Exec : decomposePar -case coarse/
Date : Oct 23 2009
Time : 14:58:57
Host : shagwell.rtech.fr
PID : 29311
Case : ./coarse
nProcs : 1
SigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).

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

Time = 0
Create mesh

Calculating distribution of cells
Selecting decompositionMethod hierarchical

Finished decomposition in 0.1 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 = 6826
Number of faces shared with processor 2 = 810
Number of faces shared with processor 1 = 812
Number of processor patches = 2
Number of processor faces = 1622
Number of boundary faces = 1596

Processor 1
Number of cells = 6826
Number of faces shared with processor 0 = 812
Number of faces shared with processor 3 = 817
Number of faces shared with processor 2 = 114
Number of processor patches = 3
Number of processor faces = 1743
Number of boundary faces = 1909

Processor 2
Number of cells = 6826
Number of faces shared with processor 0 = 810
Number of faces shared with processor 3 = 1097
Number of faces shared with processor 1 = 114
Number of processor patches = 3
Number of processor faces = 2021
Number of boundary faces = 1215

Processor 3
Number of cells = 6826
Number of faces shared with processor 2 = 1097
Number of faces shared with processor 1 = 817
Number of processor patches = 2
Number of processor faces = 1914
Number of boundary faces = 902

Number of processor faces = 3650
Max number of processor patches = 3
Max number of faces between processors = 2021

Point 180of point-pair 36 is a global point but the other point 36 is not

From function cyclicPointPatch::calcGeometry() const
in file meshes/pointMesh/pointPatches/constraint/cyclic/cyclicPointPatch.C at line 139.

FOAM exiting

I would like to know what is a global point with respect to a non global one?
Where could be the problem? Is there a solution with OpenFOAM tools or is changing my mesh the only solution?

Thanks for any help, I am getting crazy with this!

Regards,

Vincent

madad2005

November 13, 2009 05:33

This may be of absolutely no use to you, but did you run renumberMesh before decomposing?

sErik

December 7, 2009 09:15

Hi FOAMers,

I also have some trouble with decomposePar. I'm trying to decompose a big tube mesh to run simpleFOAM on it. When exectuing decomposePar I get this message:

Quote:

Create time

Time = 0
Create mesh

Calculating distribution of cells
Selecting decompositionMethod simple

Finished decomposition in 15.13 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 = 1520145
Number of faces shared with processor 1 = 28969
Number of processor patches = 1
Number of processor faces = 28969
Number of boundary faces = 85201

Processor 1
Number of cells = 1520145
Number of faces shared with processor 0 = 28969
Number of faces shared with processor 2 = 48912
Number of processor patches = 2
Number of processor faces = 77881
Number of boundary faces = 89475

Processor 2
Number of cells = 1520145
Number of faces shared with processor 1 = 48912
Number of faces shared with processor 3 = 29552
Number of processor patches = 2
Number of processor faces = 78464
Number of boundary faces = 83707

Processor 3
Number of cells = 1520144
Number of faces shared with processor 2 = 29552
Number of processor patches = 1
Number of processor faces = 29552
Number of boundary faces = 87875

Number of processor faces = 107433
Max number of processor patches = 2
Max number of faces between processors = 78464

Cannot find 'value' entry on patch Leitung_11 of field R in file "/home/fa1/OpenFOAM/eschirach/run/simpleFoam/BMW_kuehkreislauf_zulauf/0/R"
which is required to set the values of the generic patch field.
(Actual type kqRWallFunction)

Please add the 'value' entry to the write function of the user-defined boundary-condition
or link the boundary-condition into libfoamUtil.so

file: /home/fa1/OpenFOAM/eschirach/run/simpleFoam/BMW_kuehkreislauf_zulauf/0/R::Leitung_11 from line 36 to line 36.

From function genericFvPatchField<Type>::genericFvPatchField(con st fvPatch&, const Field<Type>&, const dictionary&)
in file fields/fvPatchFields/basic/generic/genericFvPatchField.C at line 72.

FOAM exiting

I adapted the initial conditions from the tutorial with the same entries for pacht, wall, values, types, ...

I don't know, why a "value" entry is expected, I don't want the wall to be a fixed value.

Any help is appreciated.

olesen

December 8, 2009 02:38

Quote:

Originally Posted by sErik (Post 238971)

I don't know, why a "value" entry is expected, I don't want the wall to be a fixed value.

Most of the boundary conditions need a "value" entry, even if you are not using it to specify a "fixedValue". With the exception of patch types like 'symmetry', you'll generally need a value at the boundary.

For your boundary condition type, this value can be pretty much anything in the 0/ boundary condition files - ie, zero is often a good enough value to blindly hack in.
At later timesteps, the 'value' entry will contain the values calculated on the boundary patch.

Even if your boundary condition is smart enough to determine the correct wall values itself, you will need the 'value' field later on - eg, during post-processing or visualization. These components likely don't know anything about how your boundary condition works and may not even have access to any OpenFOAM libraries.

sErik

December 8, 2009 04:25

Hi Mark,
thank you for your help.
I applied for every "wall" boundary in the 0/R file "type fixedValue; value uniform (0 0 0 0 0 0);" and now I could run decomposePar on the case.

But I still don't realy understand it. Before, I have declared the "wall" boundarys with "kqRWallFunction". I actually thought, that this would be the correct way to declare the initial conditions for R.

olesen

December 8, 2009 04:40

Quote:

Originally Posted by sErik (Post 239094)

Hi Mark,
thank you for your help.
I applied for every "wall" boundary in the 0/R file "type fixedValue; value uniform (0 0 0 0 0 0);" and now I could run decomposePar on the case.

Partially right. You need the "value" entry (for reasons already explained, and to initialized the underlying classes), but certainly don't want "type fixedValue" - this really isn't what you mean.

If you look at the tutorials/multiphase/interFoam/ras/damBreak/0/R you'll see that you want something like this:

Code:

internalField   uniform ( 0 0 0 0 0 0 );



boundaryField

{

    myWall1

    {

        type            kqRWallFunction;

        value           uniform ( 0 0 0 0 0 0 );

    }

    myWall2

    {

        type            kqRWallFunction;

        value           uniform ( 0 0 0 0 0 0 );

    }

...

}

Since this gets a bit tedious to write, you can use the '$var' dictionary expansions, and might also benefit from using regular expressions for the patch names.
If you do both, the 0/R file would be a bit more compact:

Code:

internalField   uniform ( 0 0 0 0 0 0 );



boundaryField

{

    "myWall[0-9]+"

    {

        type            kqRWallFunction;

        value           $internalField;

    }

...

}

Hopefully that gets you going in the right direction.
/mark

sErik

December 8, 2009 05:20

Hi Mark,
thank you very much, that really helped!!
I think, that I've got the point.

maddalena

April 1, 2010 04:03

GlobalPoint?

Hello everybody,
I have the same problem of Vincent after running decomposePar:

Quote:

Point 180of point-pair 36 is a global point but the other point 36 is not

From function cyclicPointPatch::calcGeometry() const
in file meshes/pointMesh/pointPatches/constraint/cyclic/cyclicPointPatch.C at line 139.

FOAM exiting

Running renumberingMesh did not help me:

Code:

face 294 and 7426 areas do not match by 0.0154922% -- possible face ordering problem#0  Foam::error::printStack(Foam::Ostream&) in "/root/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libOpenFOAM.so"

#1  Foam::error::abort() in "/root/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libOpenFOAM.so"

#2  Foam::cyclicFvPatch::makeWeights(Foam::Field<double>&) const in "/root/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libfiniteVolume.so"

#3  Foam::surfaceInterpolation::makeWeights() const in "/root/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libfiniteVolume.so"

#4  Foam::surfaceInterpolation::weights() const in "/root/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libfiniteVolume.so"

#5  Foam::fvPatch::weights() const in "/root/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libfiniteVolume.so"

#6  Foam::coupledFvPatchField<double>::evaluate(Foam::Pstream::commsTypes) in "/root/OpenFOAM/OpenFOAM-1.6/applications/bin/linux64GccDPOpt/decomposePar"

#7  Foam::cyclicFvPatchField<double>::cyclicFvPatchField(Foam::fvPatch const&, Foam::DimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) in "/root/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libfiniteVolume.so"

#8  Foam::fvPatchField<double>::adddictionaryConstructorToTable<Foam::cyclicFvPatchField<double> >::New(Foam::fvPatch const&, Foam::DimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) in "/root/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libfiniteVolume.so"

#9  Foam::fvPatchField<double>::New(Foam::fvPatch const&, Foam::DimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) in "/root/OpenFOAM/OpenFOAM-1.6/applications/bin/linux64GccDPOpt/decomposePar"

#10  Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::GeometricBoundaryField::GeometricBoundaryField(Foam::fvBoundaryMesh const&, Foam::DimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) in "/root/OpenFOAM/OpenFOAM-1.6/applications/bin/linux64GccDPOpt/decomposePar"

#11  Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::readField(Foam::Istream&) in "/root/OpenFOAM/OpenFOAM-1.6/applications/bin/linux64GccDPOpt/decomposePar"

#12  Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::GeometricField(Foam::IOobject const&, Foam::fvMesh const&) in "/root/OpenFOAM/OpenFOAM-1.6/applications/bin/linux64GccDPOpt/decomposePar"

#13  void Foam::readFields<domainDecomposition, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> >(domainDecomposition const&, Foam::IOobjectList const&, Foam::PtrList<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> >&) in "/root/OpenFOAM/OpenFOAM-1.6/applications/bin/linux64GccDPOpt/decomposePar"

#14  main in "/root/OpenFOAM/OpenFOAM-1.6/applications/bin/linux64GccDPOpt/decomposePar"

#15  __libc_start_main in "/lib/libc.so.6"

#16  Foam::regIOobject::writeObject(Foam::IOstream::streamFormat, Foam::IOstream::versionNumber, Foam::IOstream::compressionType) const in "/root/OpenFOAM/OpenFOAM-1.6/applications/bin/linux64GccDPOpt/decomposePar"

I know the problem is with createPatch, but the strange thing is that the same case runs perfectly on a single processor! :confused:
What is going wrong? Any idea?

mad

rlc138

April 13, 2010 14:20

Global Points for a Single Processor Job?

Can anyone answer the original question posted by Vincent:

>Point 180of point-pair 36 is a global point but the other point 36 is not
>
>From function cyclicPointPatch::calcGeometry() const
>in file >meshes/pointMesh/pointPatches/constraint/cyclic/cyclicPointPatch.C at >line 139.
>
>FOAM exiting
>
>
>I would like to know what is a global point with respect to a non global >one?
>Where could be the problem? Is there a solution with OpenFOAM tools or >is changing my mesh the only solution?

I am having a similar issue but for a serial job. My simpleFoam case runs to completion, but when I try to run foamToVTK to view the results in paraView, I get the error:
Point 62of point-pair 46 is a global point but the other point 63 is not
From function cyclicPointPatch::calcGeometry() const
in file meshes/pointMesh/pointPatches/constraint/cyclic/cyclicPointPatch.C at line 139.
FOAM exiting

What is a global point? I thought global points had to do with parallel processing. My job is serial.

Rob

maddalena

April 14, 2010 02:48

Quote:

Originally Posted by rlc138 (Post 254460)

I am having a similar issue but for a serial job. My simpleFoam case runs to completion, but when I try to run foamToVTK to view the results in paraView, I get the error:
Point 62of point-pair 46 is a global point but the other point 63 is not
From function cyclicPointPatch::calcGeometry() const
in file meshes/pointMesh/pointPatches/constraint/cyclic/cyclicPointPatch.C at line 139.
FOAM exiting

Hello Rob,
I had the same problem as you describe, see my previous post.
I guess the problem is due to how the points are numbered. First try the renumberMesh utility and than run paraFoam, it worked for me some time ago.
If you get an error, try the following work-around: copy the time step you want to check and the constant folder in a new case folder, redefine the cyclic patches as symmetryPlane, and than run paraFoam. Of course, the problem is not solved, but at least you can see your results!
Hope it helps,
cheers,
maddalena

sandy

May 2, 2010 20:09

Everything is ok, if those patches are not "cyclic" but "symmetryPlane". However, when I change them into "cyclic", everything is not ok. It is the same as above error informations. How can I do it?

maddalena

May 3, 2010 16:19

Hello Sandy,
the workaround I proposed above is useful only to see your results after a successfull converged single processor run. At that point, you do not need the boundary type definition, and symmetryPlane is used only as a postprocessing information.
Hope to be clear.
Bye

maddalena

sandy

May 3, 2010 20:13

Quote:

Originally Posted by askjak (Post 241413)

Great. I will have a look at it.

I guess this cyclic patch issue could be mitigated in the decomposing step by adding a "preservePatches" in decomposeParDict

Quote:
//- Keep owner and neighbour on same processor for faces in patches:
// (makes sense only for cyclic patches)
preservePatches (port01);

Ask

Hi, I could not understand your meanings very well, however, I have solved my problem by using "preservePatches" in decomposeParDict. But I don't know why my simulation case oscillates so much? I guess it is very difficult to get convergence to the cyclic BC ....

sandy

May 3, 2010 20:29

Quote:

Originally Posted by maddalena (Post 257387)

I don't know how to implement it, please explain clearly ...

maddalena

May 4, 2010 04:10

Well... copy paste constant, system and latestTime folder in a new folder, than replace the word cyclic with symmetryPlane for every occurrence inside the boundary file and in p, U, epsilon, k, ... files.

sandy

May 4, 2010 06:47

Yes, maddalena, maybe you are right, maybe not. I ever simulated natural convection problems. Their results are very very easy to be effected by initial fields. Different initial fields sometimes will get different final-results. It looks reasonal and not logical, and I felt so strange too, but it is the fact. .... So, now I always hesitate to begin from the first step, if I change the BC seriously .....

Sure, your method should decrease the initial osicillation. I will try. Thanks.

maddalena

May 4, 2010 07:43

Quote:

Originally Posted by sandy (Post 257477)

... your method should decrease the initial osicillation. I will try...

My method is not intended to decrease the initial oscillation, neither to run a simulation! My method is intended only to postprocess results!

sandy

May 4, 2010 08:36

:D:D YES, dream the pie in sky ... Thanks, anyway!!

aloeven

January 26, 2011 02:17

Ok, it's an old thread, but I ran into the same problem. I can share my solution, perhaps it helps anybody who faces the problem again. It looks like in my case that the 2 periodic patches (that make up the cyclic patch) do not exactly match. In my case, the maximum mismatch is in the order of 10^-7. The strange thing is that with this small mismatch, checkMesh does not report an error and the simulation can be run in serial. Problems only arise when you try to visualize the results or decompose the case for a parallel simulation.

I solved it by manually dividing the cyclic patch in the constant/polyMesh/boundary file into two equally sized patches called Periodic1 and Periodic2.
Then I merged them again to one cyclic patch using createPatch.

The createPatch utility makes sure that the new cyclic patch is matching both periodic patches and the numbering is correct. Also the reported post-processing problem disappeared.

All times are GMT -4. The time now is 18:21.