CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Native Meshers: snappyHexMesh and Others

Parallel sHM error

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

Reply
 
LinkBack Thread Tools Display Modes
Old   February 9, 2012, 05:43
Default Parallel sHM error
  #1
Member
 
Victor-S. Eberhart
Join Date: Oct 2011
Posts: 32
Rep Power: 5
vigges is on a distinguished road
Hi folks,

i'm trying to run snappyHexMesh (OF 2.1.x) in parallel mode using following commands:
Code:
blockmesh
decomposePar (using scotch in decomposeParDict)
mpirun -np 6 snappyHexMesh -parallel -overwrite (using ptscotch in decomposeParDict)
reconstructParMesh -constant -mergeTol 1E-6
Unfortunately, I get following error message, probably caused by snappyHexMesh:
Quote:
stss3@itlrstud041:~/OpenFOAM/stss3-2.1.x/run/mappedCase2D/mappedCase102> ./parallelSHM
[2]
[2]
[2] --> FOAM FATAL ERROR:
[2] face 7 area does not match neighbour by 0.276304% -- possible face ordering problem.
patch:procBoundary2to1 my area:9.14844e-07 neighbour area:9.17375e-07 matching tolerance:9.08608e-11
Mesh face:25882 vertices:4((0.372 0.0709347 0) (0.372 0.0691 0) (0.372 0.0691 0.0005) (0.372 0.0709246 0.0005))
If you are certain your matching is correct you can increase the 'matchTolerance' setting in the patch dictionary in the boundary file.
Rerun with processor debug flag set for more information.
[2]
[2] From function processorPolyPatch::calcGeometry()
[2] in file meshes/polyMesh/polyPatches/constraint/processor/processorPolyPatch.C at line 239.
[2]
FOAM parallel run exiting
[2]
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 2 in communicator MPI_COMM_WORLD
with errorcode 1.

NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------
[1]
[1]
[1] --> FOAM FATAL ERROR:
[1] face 7 area does not match neighbour by 0.276304% -- possible face ordering problem.
patch:procBoundary1to2 my area:9.17375e-07 neighbour area:9.14844e-07 matching tolerance:9.04077e-11
Mesh face:25839 vertices:4((0.372 0.0709347 0) (0.372 0.0709347 0.0005) (0.372 0.0691 0.0005) (0.372 0.0691 0))
If you are certain your matching is correct you can increase the 'matchTolerance' setting in the patch dictionary in the boundary file.
Rerun with processor debug flag set for more information.
[1]
[1] From function processorPolyPatch::calcGeometry()
[1] in file meshes/polyMesh/polyPatches/constraint/processor/processorPolyPatch.C at line 239.
[1]
FOAM parallel run exiting
[1]
--------------------------------------------------------------------------
mpirun has exited due to process rank 2 with PID 5675 on
node itlrstud041 exiting improperly. There are two reasons this could occur:

1. this process did not call "init" before exiting, but others in
the job did. This can cause a job to hang indefinitely while it waits
for all processes to call "init". By rule, if one process calls "init",
then ALL processes must call "init" prior to termination.

2. this process called "init", but exited without calling "finalize".
By rule, all processes that call "init" MUST call "finalize" prior to
exiting or it will be considered an "abnormal termination"

This may have caused other processes in the application to be
terminated by signals sent by mpirun (as reported here).
--------------------------------------------------------------------------
[itlrstud041:05672] 1 more process has sent help message help-mpi-api.txt / mpi-abort
[itlrstud041:05672] Set MCA parameter "orte_base_help_aggregate" to 0 to see all help / error messages
At the end of my sHM-Logfile there is following statement:
Quote:
Scaling iteration 0
Moving mesh using diplacement scaling : min:1 max:1
Correcting 2-D mesh motion--> FOAM Warning :
From function motionSmoother::movePoints(pointField& newPoints)
in file motionSmoother/motionSmoother.C at line 809
2D mesh-motion probably not correct in parallel
--> FOAM Warning :
From function twoDPointCorrector::twoDPointCorrector(const polyMesh& mesh, const vector& n)
in file twoDPointCorrector/twoDPointCorrector.C at line 164
The number of points in the mesh is not equal to twice the number of edges normal to the plane - this may be OK only for wedge geometries.
Please check the geometry or adjust the orthogonality tolerance.

Number of normal edges: 8676 number of points: 10872
...done
[1] processorPolyPatch::calcGeometry : Writing my 172 faces to OBJ file "/home/stss3/OpenFOAM/stss3-2.1.x/run/mappedCase2D/mappedCase102/processor1/procBoundary1to2_faces.obj"
[2] processorPolyPatch::calcGeometry : Writing my 172 faces to OBJ file "/home/stss3/OpenFOAM/stss3-2.1.x/run/mappedCase2D/mappedCase102/processor2/procBoundary2to1_faces.obj"
[2] processorPolyPatch::calcGeometry : Dumping cell centre lines between corresponding face centres to OBJ file"/home/stss3/OpenFOAM/stss3-2.1.x/run/mappedCase2D/mappedCase102/processor2/procBoundary2to1_faceCentresConnections.obj"
[1] processorPolyPatch::calcGeometry : Dumping cell centre lines between corresponding face centres to OBJ file"/home/stss3/OpenFOAM/stss3-2.1.x/run/mappedCase2D/mappedCase102/processor1/procBoundary1to2_faceCentresConnections.obj"
Do you have an idea how to fix this?
Thanks in advance!

Last edited by vigges; February 9, 2012 at 06:26. Reason: Provide version of used sofware
vigges is offline   Reply With Quote

Old   April 4, 2012, 09:18
Default
  #2
Senior Member
 
lore
Join Date: Mar 2010
Location: Italy
Posts: 463
Rep Power: 9
lovecraft22 is on a distinguished road
Send a message via Skype™ to lovecraft22
I'm having the same issue… did you manage to solve sort it out eventually?
lovecraft22 is offline   Reply With Quote

Old   April 4, 2012, 09:42
Default
  #3
Member
 
Victor-S. Eberhart
Join Date: Oct 2011
Posts: 32
Rep Power: 5
vigges is on a distinguished road
Sorry, I haven't got any solution.
I gave up after trying an entire weekend
vigges is offline   Reply With Quote

Old   April 18, 2012, 11:17
Default
  #4
Member
 
Join Date: Apr 2012
Location: France
Posts: 72
Rep Power: 5
Rider is on a distinguished road
Have you solve your problem ? What command line did you executed before reconstructPartMesh ?

Maybe I have a solution to solve your problem
Rider is offline   Reply With Quote

Old   April 24, 2012, 03:37
Default
  #5
New Member
 
Join Date: Apr 2012
Posts: 4
Rep Power: 5
MacGyver is on a distinguished road
Ive a similar problem when running my solver. I had a closer look in the C++documentation and somehow figured out the reason.

The problem is caused by the decomposition of the domain. There a default_matchTolerance for the faces which is automatically applied (the value is 1e-4).
You can see this setting in your processor*/constant/polyMesh/boundary file at the processor-patches.

"
[2] face 7 area does not match neighbour by 0.276304% -- possible face ordering problem.
patchrocBoundary2to1 my area:9.14844e-07 neighbour area:9.17375e-07 matching tolerance:9.08608e-11
"
The matching tolerance 9.08608e-11 is calculated as followed: matchTol*length^2
The length is the maximal distance from the face center to a vertice ( in this case: ~ 9.532e-4 Squared this corresponds to a kind of equivalent face area. This value is compared with the difference between "my area" and "neighbour area".

I could not figure out how to change this matchTolerance so I just changed the entry in the boundary-files after the decomposition with this command:
"
sed 's/0.0001/0.05/g' processor*/constant/polyMesh/boundary -i
"
-> the matchTolerance is 0.05 now

I think it is very difficult to match this very small default tolerance for a refined mesh. I also use SHM and therefore have the same problem. I dont know yet if the calculation is stable.

Do you know any better solution (e.g. where to set the matchTolerance - entry, e.g. in the decomposeParDict)??
MacGyver is offline   Reply With Quote

Old   April 24, 2012, 03:43
Default
  #6
Member
 
Join Date: Apr 2012
Location: France
Posts: 72
Rep Power: 5
Rider is on a distinguished road
Could you copy your files here ? (decomposePar, snappyHexMesh, controlDict)
Rider is offline   Reply With Quote

Old   April 30, 2012, 04:59
Default
  #7
New Member
 
Join Date: Apr 2012
Posts: 4
Rep Power: 5
MacGyver is on a distinguished road
I decomposed with "method hierarchical"
This error just occured when running my solver; I had no problems with snappyhexmesh.

Did you try my solution?
Do you use cyclic boundary conditions?
MacGyver is offline   Reply With Quote

Old   May 2, 2012, 06:44
Default
  #8
Member
 
Join Date: Apr 2012
Location: France
Posts: 72
Rep Power: 5
Rider is on a distinguished road
Quote:
Originally Posted by MacGyver View Post
I decomposed with "method hierarchical"
This error just occured when running my solver; I had no problems with snappyhexmesh.
I didn't said that you have problem with sHM.

Quote:
Originally Posted by MacGyver View Post
Did you try my solution?
Do you use cyclic boundary conditions?
No, but it's difficult to help you, if we don't see what parameters you used
Rider is offline   Reply With Quote

Old   March 18, 2013, 07:27
Default exit with error when parallelized
  #9
Member
 
Ilya
Join Date: Dec 2011
Location: Russia
Posts: 82
Blog Entries: 38
Rep Power: 5
skeptik is on a distinguished road
I just run sHM in serial and it finished correctly, without snapped and layered mesh.
it seems that the problem in sHM
__________________
practice makes perfect
skeptik 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
Compile problem ivanyao OpenFOAM Running, Solving & CFD 1 October 12, 2012 09:31
Saving ParaFoam views and case sail OpenFOAM Paraview & paraFoam 9 November 25, 2011 16:46
Accessing phi from a fvPatchField at same patch johndeas OpenFOAM 1 September 13, 2010 20:23
Installation OF1.5-dev ttdtud OpenFOAM Installation 46 May 5, 2009 02:32
error while compiling the USER Sub routine CFD user CFX 3 November 25, 2002 16:16


All times are GMT -4. The time now is 19:32.