CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Native Meshers: snappyHexMesh and Others (http://www.cfd-online.com/Forums/openfoam-meshing-snappyhexmesh/)
-   -   Parallel sHM error (http://www.cfd-online.com/Forums/openfoam-meshing-snappyhexmesh/97115-parallel-shm-error.html)

vigges February 9, 2012 04:43
Parallel sHM error
 
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!

lovecraft22 April 4, 2012 09:18
I'm having the same issue… did you manage to solve sort it out eventually?

vigges April 4, 2012 09:42
Sorry, I haven't got any solution.
I gave up after trying an entire weekend :confused:

Rider April 18, 2012 11:17
Have you solve your problem ? What command line did you executed before reconstructPartMesh ?

Maybe I have a solution to solve your problem

MacGyver April 24, 2012 03:37
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.
patch:procBoundary2to1 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)??

Rider April 24, 2012 03:43
Could you copy your files here ? (decomposePar, snappyHexMesh, controlDict)

MacGyver April 30, 2012 04:59
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?

Rider May 2, 2012 06:44
Quote:
Originally Posted by MacGyver (Post 358436)
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 (Post 358436)
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

skeptik March 18, 2013 07:27
exit with error when parallelized
 
I just run sHM in serial and it finished correctly, without snapped and layered mesh.
it seems that the problem in sHM


All times are GMT -4. The time now is 07:53.