[mullet904]

Trying to solve a case with simpleFoam in parallel.

I create the mesh using SHM in parallel, edit polymesh/boundary removing the patches from blockMesh, then solve with simpleFoam without issue.

However, if I decomposePar after mesh generation so I may run simpleFoam in parallel, decomposePar exits with error.....

Create mesh

Calculating distribution of cells
Selecting decompositionMethod simple

Finished decomposition in 0.35 s

Calculating original mesh data

Distributing cells to processors

Distributing faces to processors

Distributing points to processors

Constructing processor meshes


--> FOAM FATAL ERROR:
Cell 0contains face labels out of range: 6(0 1 2 -1 -1 -1) Max face index = 384999

From function Foam:olyMesh:olyMesh(const Foam::IOobject&, const Foam::Xfer<Foam::Field<Foam::Vector<double> > >&, const Foam::Xfer<Foam::List<Foam::face> >&, const Foam::Xfer<Foam::List<Foam::cell> >&, bool)
in file meshes/polyMesh/polyMesh.C at line 629.

FOAM aborting


================================================== ====

if I checkMesh at this point, I get error


Checking topology...
****Problem with boundary patch 0 named inlet of type wall. The patch should start on face no 1489753 and the patch specifies 1504753.
Possibly consecutive patches have this same problem. Suppressing future warnings.
***Boundary definition is in error.
Cell to face addressing OK.
Point usage OK.
Upper triangular ordering OK.
Face vertices OK.
Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces...
Patch Faces Points Surface topology
inlet 3195 4013 ok (non-closed singly connected)
outlet 3981 4655 ok (non-closed singly connected)
pipe 53736 68594 ok (non-closed singly connected)

Checking geometry...
Overall domain bounding box (-0.1 -0.1 -0.1) (0.1 0.1 0.1)
Mesh has 3 geometric (non-empty/wedge) directions (1 1 1)
Mesh has 3 solution (non-empty) directions (1 1 1)
Boundary openness (-2.7816346e-16 -5.7216192e-17 2.1630651e-15) OK.
Max cell openness = 3.9992999e-16 OK.
Max aspect ratio = 10.604633 OK.
Minimum face area = 2.7188777e-09. Maximum face area = 1.6741e-05. Face area magnitudes OK.
Min volume = 4.2935824e-13. Max volume = 6.5925713e-08. Total volume = 0.0079973385. Cell volumes OK.
Mesh non-orthogonality Max: 64.867432 average: 12.822348
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 3.0829412 OK.
Coupled point location match (average 0) OK.

Mesh OK.

End

===============================

If think it has something to do with how I am editing out the blockMesh patches in /polymesh/boundary file but I just am not able to figure it out.


Any help would be appreciated.

[Antimony]

Hi,

I create the mesh using SHM in parallel, edit polymesh/boundary removing the patches from blockMesh, then solve with simpleFoam without issue.

However, if I decomposePar after mesh generation so I may run simpleFoam in parallel, decomposePar exits with error.....

I don't quite understand. You have already decomposed the case and then run snappyHexMesh. Any particular reason to decompose the case again??

Cheers,
Antimony

[mullet904]

My understanding is that if I decomposePar to run snappyHexMesh in parallel, I must reconstructParMesh to make a proper mesh representing my model geometry when SHM completes. At that point, the polymesh/boundary file is rewritten reflecting the patches SMH creates. I decomposePar again to prepare the case for the simpleFoam run in parallel.

If I do not reconstructParMesh and proceed with simpleFoam, my patches from SHM are not recognised because the polymesh/boundary only knows about the results of blockMesh.

I'll try running SHM in serial, see if I can make headway since the solution takes much longer and would benefit from parallelization more than SHM though I'm not optimistic it will succeed....

Thanks.

[Antimony]

Hi,

There are a couple of approaches to your problem, at least from my experience:

1. Run snappyHexMesh in serial and then run decomposePar. This is typically the workflow I use, but it might not be a good idea if your mesh is going to be large and will take a lot of time to generate.

2. Run decomposePar and then use snappyHexMesh in parallel. At the end of your snappyHexMesh, the polyMesh/boundary file on each of the processors should be updated with the patches introduced by snappyHexMesh. For the BC in say the 0 folder, if I use this route, I will simply put in all patches for all the variables. For the processor patches, I simply put (if my memory serves me right):

"proc*.*"
{
type processor;
}

As I typically run renumberMesh after snappy (strongly recommended by the way), it will expand the proc entries as needed for each of the processor directories.

I do not touch the polyMesh/boundary files unless I want to examine something or manually remove patches with zero number of faces. I don't change the numbering of the faces or the startFace or any of those details. Also, I usually run snappy with the -overwrite flag so that I don't have any confusion of which time folder I need to use as my starting point.

Hope this helps at least a little bit.

Cheers,
Antimony

[mullet904]

Option 1 SMH exits after running serially without error.


a. decomposePar with removal of BlockMesh patched from polymesh/boundary...decomposePar exits with original error.


b. decomposePar without removing BlockMesh patches from polymesh/boundary...decomposePar exits with error .


Create time



Decomposing mesh region0

Create mesh

Calculating distribution of cells
Selecting decompositionMethod simple

Finished decomposition in 0.23 s

Calculating original mesh data

Distributing cells to processors

Distributing faces to processors

Distributing points to processors

Constructing processor meshes
Reading hexRef8 data : cellLevel
Reading hexRef8 data : pointLevel
Reading hexRef8 data : level0Edge
Reading hexRef8 data : refinementHistory

Processor 0
Number of cells = 72533
Number of faces shared with processor 1 = 4388
Number of processor patches = 1
Number of processor faces = 4388
Number of boundary faces = 13222

Processor 1
Number of cells = 72533
Number of faces shared with processor 0 = 4388
Number of faces shared with processor 2 = 3618
Number of processor patches = 2
Number of processor faces = 8006
Number of boundary faces = 25490

Processor 2
Number of cells = 72533
Number of faces shared with processor 1 = 3618
Number of faces shared with processor 3 = 5040
Number of processor patches = 2
Number of processor faces = 8658
Number of boundary faces = 26493

Processor 3
Number of cells = 72532
Number of faces shared with processor 2 = 5040
Number of processor patches = 1
Number of processor faces = 5040
Number of boundary faces = 13091

Number of processor faces = 13046
Max number of cells = 72533 (0.00034467189% above average 72532.75)
Max number of processor patches = 2 (33.333333% above average 1.5)
Max number of faces between processors = 8658 (32.730339% above average 6523)

Time = 0


--> FOAM FATAL IO ERROR:
Cannot find patchField entry for maxY

file: /home/jim/A_OpenFoam/pipe/0/epsilon.boundaryField from line 26 to line 36.

From function void Foam::GeometricField<Type, PatchField, GeoMesh>::Boundary::readField(const Foam:imensionedField<TypeR, GeoMesh>&, const Foam::dictionary&) [with Type = double; PatchField = Foam::fvPatchField; GeoMesh = Foam::volMesh]
in file /home/openfoam/OpenFOAM/OpenFOAM-4.0/src/OpenFOAM/lnInclude/GeometricBoundaryField.C at line 191.

FOAM exiting


==============> maxY is a patch from blockMesh, I originally edited polymesh\boundary to remove the blockMesh patches to avoid this error.....however, I introduced the above error.....


Thanks

[Antimony]

Hi,

I don't quite understand still why you manually edit the entries in polyMesh/boundary for the entries obtained from blockMesh.

Can you upload your blockMeshDict, snappyHexMeshDict and the STL files you are using to create the mesh for this case?

Cheers,
Antimony

[mullet904]

Attached are the files I can send with .txt extention....the pipe stl is 7.8MB thus to large to send.......