CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Pre-Processing

Problem with decomposePar tool

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

Reply
 
LinkBack Thread Tools Display Modes
Old   October 23, 2009, 09:29
Default Problem with decomposePar tool
  #1
Senior Member
 
Vincent RIVOLA
Join Date: Mar 2009
Location: France
Posts: 277
Rep Power: 9
vinz is on a distinguished road
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
vinz is offline   Reply With Quote

Old   November 13, 2009, 06:33
Default
  #2
Senior Member
 
Anonymous
Join Date: Mar 2009
Posts: 110
Rep Power: 8
madad2005 is on a distinguished road
This may be of absolutely no use to you, but did you run renumberMesh before decomposing?
madad2005 is offline   Reply With Quote

Old   December 7, 2009, 10:15
Default
  #3
Member
 
Join Date: Nov 2009
Location: Munich
Posts: 43
Rep Power: 7
sErik is on a distinguished road
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.
sErik is offline   Reply With Quote

Old   December 8, 2009, 03:38
Default
  #4
Senior Member
 
Mark Olesen
Join Date: Mar 2009
Location: http://olesenm.github.io/
Posts: 777
Rep Power: 18
olesen will become famous soon enough
Quote:
Originally Posted by sErik View Post
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.
olesen is offline   Reply With Quote

Old   December 8, 2009, 05:25
Default
  #5
Member
 
Join Date: Nov 2009
Location: Munich
Posts: 43
Rep Power: 7
sErik is on a distinguished road
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.
sErik is offline   Reply With Quote

Old   December 8, 2009, 05:40
Default
  #6
Senior Member
 
Mark Olesen
Join Date: Mar 2009
Location: http://olesenm.github.io/
Posts: 777
Rep Power: 18
olesen will become famous soon enough
Quote:
Originally Posted by sErik View Post
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
olesen is offline   Reply With Quote

Old   December 8, 2009, 06:20
Default
  #7
Member
 
Join Date: Nov 2009
Location: Munich
Posts: 43
Rep Power: 7
sErik is on a distinguished road
Hi Mark,
thank you very much, that really helped!!
I think, that I've got the point.
sErik is offline   Reply With Quote

Old   April 1, 2010, 04:03
Unhappy GlobalPoint?
  #8
Senior Member
 
maddalena's Avatar
 
maddalena
Join Date: Mar 2009
Posts: 436
Rep Power: 12
maddalena is on a distinguished road
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!
What is going wrong? Any idea?


mad

Last edited by maddalena; April 1, 2010 at 08:02.
maddalena is offline   Reply With Quote

Old   April 13, 2010, 14:20
Default Global Points for a Single Processor Job?
  #9
New Member
 
Rob Campbell
Join Date: Oct 2009
Posts: 12
Rep Power: 7
rlc138 is on a distinguished road
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
rlc138 is offline   Reply With Quote

Old   April 14, 2010, 02:48
Default
  #10
Senior Member
 
maddalena's Avatar
 
maddalena
Join Date: Mar 2009
Posts: 436
Rep Power: 12
maddalena is on a distinguished road
Quote:
Originally Posted by rlc138 View Post
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
maddalena is offline   Reply With Quote

Old   May 2, 2010, 20:09
Default
  #11
Senior Member
 
Sandy Lee
Join Date: Mar 2009
Posts: 207
Rep Power: 9
sandy is on a distinguished road
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?
sandy is offline   Reply With Quote

Old   May 3, 2010, 16:19
Default
  #12
Senior Member
 
maddalena's Avatar
 
maddalena
Join Date: Mar 2009
Posts: 436
Rep Power: 12
maddalena is on a distinguished road
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
maddalena is offline   Reply With Quote

Old   May 3, 2010, 20:13
Default
  #13
Senior Member
 
Sandy Lee
Join Date: Mar 2009
Posts: 207
Rep Power: 9
sandy is on a distinguished road
Quote:
Originally Posted by askjak View Post
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 is offline   Reply With Quote

Old   May 3, 2010, 20:29
Default
  #14
Senior Member
 
Sandy Lee
Join Date: Mar 2009
Posts: 207
Rep Power: 9
sandy is on a distinguished road
Quote:
Originally Posted by maddalena View Post
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
I don't know how to implement it, please explain clearly ...

Last edited by sandy; May 3, 2010 at 21:31.
sandy is offline   Reply With Quote

Old   May 4, 2010, 04:10
Default
  #15
Senior Member
 
maddalena's Avatar
 
maddalena
Join Date: Mar 2009
Posts: 436
Rep Power: 12
maddalena is on a distinguished road
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.
maddalena is offline   Reply With Quote

Old   May 4, 2010, 06:47
Default
  #16
Senior Member
 
Sandy Lee
Join Date: Mar 2009
Posts: 207
Rep Power: 9
sandy is on a distinguished road
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.

Last edited by sandy; May 4, 2010 at 07:09.
sandy is offline   Reply With Quote

Old   May 4, 2010, 07:43
Default
  #17
Senior Member
 
maddalena's Avatar
 
maddalena
Join Date: Mar 2009
Posts: 436
Rep Power: 12
maddalena is on a distinguished road
Quote:
Originally Posted by sandy View Post
... 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!
maddalena is offline   Reply With Quote

Old   May 4, 2010, 08:36
Default
  #18
Senior Member
 
Sandy Lee
Join Date: Mar 2009
Posts: 207
Rep Power: 9
sandy is on a distinguished road
YES, dream the pie in sky ... Thanks, anyway!!
sandy is offline   Reply With Quote

Old   January 26, 2011, 03:17
Default
  #19
Member
 
Alex
Join Date: Apr 2010
Posts: 32
Rep Power: 7
aloeven is on a distinguished road
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.
aloeven 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
Incoherent problem table in hollow-fiber spinning Gianni FLUENT 0 April 5, 2008 10:33
Adiabatic and Rotating wall (Convection problem) ParodDav CFX 5 April 29, 2007 19:13
Problem in Tutorial problem of fluent Phanindra FLUENT 5 April 17, 2007 09:57
problem with using colocated code Jack Main CFD Forum 0 December 15, 2002 01:15
GAMBIT meshing problem Gauthier Lambert Main CFD Forum 1 August 3, 2000 09:22


All times are GMT -4. The time now is 12:33.