[vaina74]

Hi all, I obtain an unknow error message when trying to launch decomposePar

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

    From function polyMesh::polyMesh
(
    const IOobject&,
    const Xfer<pointField>&,
    const Xfer<faceList>&,
    const Xfer<cellList>&
)

    in file meshes/polyMesh/polyMesh.C at line 654.

FOAM aborting

Do you know what does it mean? Before that, my steps are (already used for similar cases on these days):
- blockMesh
- surfaceFeatureExtract
- decomposePar
- foamJob -parallel -screen snappyHexMesh -overwrite
- reconstructParMesh -constant
- rename folder 0.org to 0 and remove all the references to patches created by blockMesh in constant/polymesh/boundary file (and edit the total number of patches in top of it)
- decomposePar (after removing previous processor folders)
Could you help me, please?

[vaina74]

I really can't understand what's happening. I made a lot of simulation on these days, with different turbulent models and geometries, and I had no problems. I think that something is wrong with editing the constant/polymesh/boundary file, but I always removed the lines

    defaultFaces
    {
        type            empty;
        inGroups        1(empty);
        nFaces          120000;
        startFace       28858851;
    }

before running the solver and everything was OK
If I don't edit the file boundary and try to decompose the case setup, decomposePar gives no error. If I remove the lines above and edit the boundaries total number, decomposePar doesn't work.

[Tobi]

Why you remove these lines?
You need it because there are some faces with the name "defaultFaces".
Maybe in your other files "nFaces" was zero. Then it is possible to remove such lines but not if there are faces defined by this patchname.

[vaina74]

Hi Tobi,

I remove defaultFaces becouse I don't need them. It's just a residual from blockMesh - I use snappyHexMesh for an internal flow simulation. I follow a procedure similar to this one.

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2.3.0                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    object      blockMeshDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

convertToMeters 1;

vertices
(
    (20 -11 0)
    (50 -11 0)
    (50 14 0)
    (20 14 0)
    (20 -11 30)
    (50 -11 30)
    (50 14 30)
    (20 14 30)
);

blocks
(
    hex (0 1 2 3 4 5 6 7) (150 125 150) simpleGrading (1 1 1) // (150 125 150) or (120 100 120)
);

edges
(
);

patches
(
);

mergePatchPairs
(
);

// ************************************************************************* //

Maybe it's not the more elegant procedure for my case, but it always worked so far. On last days I followed the same steps for more cases with slightly different domains or turbulent models and I had no problem.

ps Tobi, nice to meet you again. And your website and tutorials are quite useful

[Tobi]

Hi,

I dont know what you are doing but if you have a boundary with nFaces != zero then you have to use it, otherwise you do something wrong (:

I can not imagine a case where this is possible to do.
Can you share your case because what you are doing is in my opinion not correct (totally wrong)

[vaina74]

Hi Tobi,

I hope my procedure is not totally wrong, what's happened with the previous simulations?
Anyway, I link the case setup. It concerns a flow analysis for a large indoor space (a ship engine room). The simulation steps are

#!/bin/sh
blockMesh
surfaceFeatureExtract
decomposePar
foamJob -parallel -screen snappyHexMesh -overwrite
reconstructParMesh -constant

Then I delete all processor folders, rename folder 0.org to 0 and edit the constant/polymesh/boundary file, removing all references to patches created by blockMesh (and editing the patches total number at the top of the file). Again

#!/bin/sh
decomposePar
mpirun -n 4 renumberMesh -overwrite -parallel
pyFoamPlotRunner.py mpirun -np 8 simpleFoam -parallel
reconstructParMesh -latestTime

Thanks for your attention, regards.

[Tobi]

Hey,

nice geometry, my laptop is bad so I will check it tomorrow but I think I know what is wrong here!

[Tobi]

Hi,

first HINT (only a hint)

well I checked your STL files and there is problem that you do not have a closed surface. Its a very common error that nobody take into account. The surface triangulation is very important for snappyHexMesh. In your case the problem is the triangulation of different parts like inlet and domain. The interface edges should have the same triangulation. I think you just export it out of Catia, SolidWorks or. some similar program. Its working if "you only have flat" surfaces and special luck like you have (:
The corners of the inlet are finer than the corners of your domain and therefor the edges are overlaying and you get no holes (luckily).

If the surface is NOT closed (therefor you have some holes in it) and the mesh is very fine, sHM realize that there is a hole and can not figure out what are inside and outside the STL due to the fact that its not closed. To check it you can put all STL files into one:

cat * > regionSTL.stl
surfaceCheck regionSTL.stl

In your case the following output is given:

Surface is not closed since not all edges connected to two faces:
    connected to one face : 1181
    connected to >2 faces : 16
Conflicting face labels:1229

This can be checked easily after meshing if you check the mesh with paraview. You will see that no cells are removed (which are not inside your STL). That could be a reason why you still have defaultFaces available and after removing that entry you destroy the mesh.


More hints:



I am meshing with sHM more then 5 years now but I never saw sth. like that:

Dangling coarse cells refinement iteration 53
--------------------------------------------

Determined cells to refine in = 0.18 s
Selected for refinement : 2 cells (out of 4125447)
Balanced mesh in = 12.76 s
After balancing coarse cell refinement iteration 53 : cells:4125447  faces:13857607  points:5643756
Cells per refinement level:
    0    386028
    1    976243
    2    1559143
    3    1204033
Edge intersection testing:
    Number of edges             : 13857637
    Number of edges to retest   : 290
    Number of intersected edges : 1177490
Refined mesh in = 6.22 s
After refinement coarse cell refinement iteration 53 : cells:4125461  faces:13857637  points:5643760
Cells per refinement level:
    0    386028
    1    976241
    2    1559159
    3    1204033

Dangling coarse cells refinement iteration 54
--------------------------------------------

.
.
.
Dangling coarse cells refinement iteration 99
--------------------------------------------

Determined cells to refine in = 0.18 s

sHM has problems with 2 cells, in my opinion you should always using nCellsBetweenLevels > 2. Furthermore it could be possible to avoid this error in your case using minRefinementCell > 0 like 10 or sth. like that.


At least you made a mistake in your bash script but I think its clear.
You decompose for 4 cores and want to run with 8 cores (;


To your mesh


After 3200s the meshing step was completed and everything was okay. After all after checking the mesh with paraview, only your STL is shown. Hence this, the entry in the boundary file "defaultFaces" has zero faces:

    defaultFaces
    {
        type            empty;
        inGroups        1(empty);
        nFaces          0;
        startFace       8536170;
    }

So I do not know what was wrong in your run.
The only change is that I did not overwrite the mesh

decomposePar
mpirun -np 4 snappyHexMesh -parallel
reconstructParMesh -latestTime -mergeTol 1e-6

So good luck!




PS: very nice geometry!

[vaina74]

Hi Tobi,

first of all thanks for your kind attention. I have some remarks about your interesting post.

STL geometry quality

The model is created with Rhinoceros. I've been using (and learning) since a few weeks - I always used Salome and/or NETGEN in the past - but I'm aware of problems about not-closed domains. This geometry is quite complex (and it's just a preliminary and simplified one), that's why I checked the 'watertightness' both Rhinoceros and CATIA - and I think that nothing is more precise than CATIA. So I was really sure, when I exported the model in STL geometry. Now the question is: what can I do to assure the best quality for STL models, even if Rhinocerso or CATIA check tools don't help? I don't know if something is possible with STL export settings, have yoy experience with these 3D modelling softwares? Export settings are often not explicit.
Anyway, thanks a lot for the tip

cat * > regionSTL.stl
surfaceCheck regionSTL.stl

This can be checked easily after meshing if you check the mesh with paraview. You will see that no cells are removed (which are not inside your STL). That could be a reason why you still have defaultFaces available and after removing that entry you destroy the mesh.

I see what you mean and I've already seen that in ParaView, but I'm not so expert about snappyHexMesh and so I thought that defaultFaces manually removing was an usual step. I mean, that's the same method in the (already) linked tutorial - and the guy doesn't seem a newbie.

snappyHexMesh settings

minRefinementCell: I read that 10 or other values are suggested to avoid too many refinement iterations, but I didn't worry about that because the whole meshing process lasts less than 15'.
nCellsBetweenLevels: are you sure that 2 buffer layers are required? I set one single layer because I don't want a too coarse background mesh (by blockMesh) for internal zones and nCellsBetweenLevels=2 results in a large amount of cells - I think that 4-5M cells are enough, even for a grid independence study. Any suggestion for that?

Other questions

So I do not know what was wrong in your run.

Sorry, in the previous post I didn't mention that I uploaded a case with a no-problem setup because I want you to look at one of my previous simulations - you were so surprised from the boundary file editing. Problems started with a new version of the model - I added other outlet opening - and I had to get deeper with the geometry watertightness, after your remarks. I suspect that the not-working case doesn't have an output like nFaces=0 (I have to check this). Anyway, are there alternative procedures or alternative blockMesh settings (to avoid strange manual editing of boundary file)?

reconstructParMesh -latestTime -mergeTol 1e-6

I'm curious about your merging tolerance option. I had some problem about that with first tests with snappyHexMesh, so I edited something (I don't remember) in the controlDict or decomposeParDict or snappyHexMeshDict file.

You decompose for 4 cores and want to run with 8 cores (;

You're right, but I didn't make this error. You haven't the last versione of my case setup. During my tests I found out that the default INTEL hyperthreading settings are not the best for OpenFOAM decomposing tools

Thanks again for your precious help!

[Tobi]

Originally Posted by vaina74

Hi Tobi,

first of all thanks for your kind attention. I have some remarks about your interesting post.

STL geometry quality

This geometry is quite complex (and it's just a preliminary and simplified one), that's why I checked the 'watertightness' both Rhinoceros and CATIA - and I think that nothing is more precise than CATIA. So I was really sure, when I exported the model in STL geometry. Now the question is: what can I do to assure the best quality for STL models, even if Rhinocerso or CATIA check tools don't help?

All STL files from CAD softwares are very bad (in my opinion). Therefor I always mesh the surface to be sure to have a very good quality surface mesh and especially that the points on interface surfaces and edges match each other. For that you can check out the following tutorial that I upload here: http://www.holzmann-cfd.de/index.php...ltiregionlayer

• Start the run file

• Cancel the run file after the stl files are generated

• Check out the triangulation of both STL files in constant/triSurface/

• You will see the differences

minRefinementCell: I read that 10 or other values are suggested to avoid too many refinement iterations, but I didn't worry about that because the sofhole meshing process lasts less than 15'.

Than I am wondering why in my run it took 60 minutes ?

nCellsBetweenLevels: are you sure that 2 buffer layers are required? I set one single layer because I don't want a too coarse background mesh (by blockMesh) for internal zones and nCellsBetweenLevels=2 results in a large amount of cells - I think that 4-5M cells are enough, even for a grid independence study. Any suggestion for that?

You do not have to use 2 but in my opinion it would be better for your calculation. But you have to find a good way for your problems. Always a big problem is time and costs vs accuracy.

Sorry, in the previous post I didn't mention that I uploaded a case with a no-problem setup because I want you to look at one of my previous simulations - you were so surprised from the boundary file editing.

I was surprised because you deleted the entry without checking the entry (I think so)

• As you wrote in your first post, the defaultFaces are not zero. The only thing that could be possible is, that these copy-paste block is after blockMesh

• How could I know that this is a working case ?

Problems started with a new version of the model - I added other outlet opening - and I had to get deeper with the geometry watertightness, after your remarks. I suspect that the not-working case doesn't have an output like nFaces=0 (I have to check this). Anyway, are there alternative procedures or alternative blockMesh settings (to avoid strange manual editing of boundary file)?

Do it and you will find that the entry is not zero.

I'm curious about your merging tolerance option. I had some problem about that with first tests with snappyHexMesh, so I edited something (I don't remember) in the controlDict or decomposeParDict or snappyHexMeshDict file.

As I remind myself correctly, if you don't use the option

-mergeTol 1e-6

The application will use a default value and that value has to be the same as in the snappyHexMeshDict (last line):

// Merge tolerance. Is fraction of overall bounding box of initial mesh.
// Note: the write tolerance needs to be higher than this.
mergeTolerance 1E-6;

Otherwise you will get an error. To avoid this you can explicitly tell the application to use 1e-6 with the argument. I think the tolerance is checked in the controlDict (writePrecision) - not sure.

Thanks again for your precious help!

You are welcome.

[vaina74]

Hi Tobi,

I'm out of office till tuesday, but I will download your snappyHexMesh tutorial and make all checks about STL triangulation as soon as possible. I don't have my case at hand now, but I'm almost sure that problems arise from a bad geometry (with added new outlet openings). I think that checkMesh doesn't help. The key test is defaultFace nFaces, I guess
I have no workstation, but maybe my computer is faster than yours. Anyway, I'll keep in mind your tips about minRefinementCell and especially nCellsBetweenLevels.

I was surprised because you deleted the entry without checking the entry (I think so)

Yes, I deleted the entry without checking because no problems were expected and I was right for all previous simulations
Apart from this, is the procedure correct? A generic blockMesh with only defaultFaces, snappyHexMeshing and the entry with no nFaces to be deleted? Maybe more efficient procedures exist.
About mergeTolerance, I couldn't understand the error, but I fixed with a different tolerance setting in some dictionary (I don't remember which one). Now I see, I'll use reconstructParMesh -latestTime -mergeTol 1e-6.

Some more little questions, I'm sure you can answer

    features
    (
        {
            file "domain.eMesh";
            level 3;
        }
    );

Is the refinement level consistent? Mayby 0 is correct (or enough).

What does it mean planarAngle 30? I found this setting in the original dictionary I edited.

I set explicitFeatureSnap true and implicitFeatureSnap false because I used the explicit feature edge handling method. Is possible to activate both and improving the snapping? Does a method exclude the other one?

What does it mean

writeFlags
(
    layerFields     // write volScalarField for layer coverage

Thanks for your big help (and patience).

[stephie]

Hello Bruno,

the installation of OpenFOAM on Ubuntu 14.4 did a friend of me. Therefore he used a video from YouTube.
I'm deeply grateful for your help. I tried the code, you have posted and it worked

Unfortunately I've got a new mistake:

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

    From function polyMesh::polyMesh
(
    const IOobject&,
    const Xfer<pointField>&,
    const Xfer<faceList>&,
    const Xfer<cellList>&
)

    in file meshes/polyMesh/polyMesh.C at line 654.

FOAM aborting

#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::error::abort() at ??:?
#2   Foam::polyMesh::polyMesh(Foam::IOobject const&,  Foam::Xfer<Foam::Field<Foam::Vector<double> > >  const&, Foam::Xfer<Foam::List<Foam::face> > const&,  Foam::Xfer<Foam::List<Foam::cell> > const&, bool) at  ??:?
#3  
 at ??:?
#4  
 at ??:?
#5  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#6  
 at ??:?
Abgebrochen (Speicherabzug geschrieben)

I'm not sure, if it depends on runnig the case in parallel. I git these message when I type in <decomposePar>. When I did it the last time it run.. but now it doesn't work anymore.
Maybe you might help me again? It would be wonderful.

Thank you for your help,
best regards,

Stephie

[wyldckat]

Hi Stephie,

My guess is that the mesh is damaged somehow. Run the following command:

checkMesh -allGeometry -allTopology

It will provide you with a detailed list of results on whether the mesh is OK or not.

If the mesh is OK, then I need to know a lot more details about the case you're trying to decompose, because that's a very generic error message. The details in specific are:

• How did you generate the mesh?
• Is the mesh OK?
• How did you prepare the boundary conditions?
• Does the case run in serial mode (i.e. not in parallel)?
• What solver are/will you be using?

Best regards,
Bruno

PS: I've copied your post from here: http://www.cfd-online.com/Forums/ope...tml#post536964 (post #10) - to this new thread, because this new question is no longer an installation issue.

_______
Edit: moved post above and the ones below to this current thread, since they are all in the same topic

[Hashemkabir]

Hello
i give a same error. my geometry is a simple cylinder, and i create it in a gambit. i specified a periodic BC for my mesh in gambit and then i convert it with fleunt3DMeshToFoam in a mdFoam solver of OpenFoam 2 1 1. then i change the boundary condition to "cyclic" and operate "foamUpgradecyclic". however, after this procedure, when i run "thendecomposePar", i give a below error:

stanford@stanford-Ideapad-Z460:~/Desktop/y$ decomposePar
/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2.1.1                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
Build  : 2.1.1-221db2718bbb
Exec   : decomposePar
Date   : Aug 11 2015
Time   : 20:24:23
Host   : "stanford-Ideapad-Z460"
PID    : 4602
Case   : /home/stanford/Desktop/y
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Disallowing user-supplied system call operations

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

Create mesh

Calculating distribution of cells
Selecting decompositionMethod scotch

Finished decomposition in 0.02999999999999999889 s

Calculating original mesh data

Distributing cells to processors

Distributing faces to processors

Distributing points to processors

Constructing processor meshes

Processor 0
    Number of cells = 650
    Number of faces shared with processor 1 = 123
    Number of faces shared with processor 3 = 60
    Number of processor patches = 2
    Number of processor faces = 183
    Number of boundary faces = 247


--> FOAM FATAL ERROR: 
Cell 637contains face labels out of range: 6(1721 1722 -1 788 1161 1418) Max face index = 2200

    From function polyMesh::polyMesh
(
    const IOobject&,
    const Xfer<pointField>&,
    const Xfer<faceList>&,
    const Xfer<cellList>&
)

    in file meshes/polyMesh/polyMesh.C at line 652.

FOAM aborting

#0  Foam::error::printStack(Foam::Ostream&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1  Foam::error::abort() in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2  Foam::polyMesh::polyMesh(Foam::IOobject const&, Foam::Xfer<Foam::Field<Foam::Vector<double> > > const&, Foam::Xfer<Foam::List<Foam::face> > const&, Foam::Xfer<Foam::List<Foam::cell> > const&, bool) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#3  
 in "/opt/openfoam211/platforms/linux64GccDPOpt/bin/decomposePar"
#4  
 in "/opt/openfoam211/platforms/linux64GccDPOpt/bin/decomposePar"
#5  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#6  
 in "/opt/openfoam211/platforms/linux64GccDPOpt/bin/decomposePar"
Aborted (core dumped)

i do a bellow work for solve my erro, but i give same error
1) i change the writePrecision to 20
2) i use a cyclicAMI
3) i checkmy mesh and i give bellow error too

/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2.1.1                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
Build  : 2.1.1-221db2718bbb
Exec   : checkMesh -allGeometry -allTopology
Date   : Aug 11 2015
Time   : 20:28:13
Host   : "stanford-Ideapad-Z460"
PID    : 4640
Case   : /home/stanford/Desktop/y
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Disallowing user-supplied system call operations

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

Create polyMesh for time = 0

Time = 0

Mesh stats
    points:           3312
    faces:            8744
    internal faces:   7678
    cells:            2737
    boundary patches: 5
    point zones:      0
    face zones:       1
    cell zones:       1

Overall number of cells of each type:
    hexahedra:     2737
    prisms:        0
    wedges:        0
    pyramids:      0
    tet wedges:    0
    tetrahedra:    0
    polyhedra:     0

Checking topology...
 ****Problem with boundary patch 4 named wall of type wall. The patch should start on face no 7914 and the patch specifies 7916.
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.
    Topological cell zip-up check OK.
    Face-face connectivity OK.
    Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces ...
    Patch               Faces    Points   Surface topology                   Bounding box
    inlet_shadow_half0  59       92       ok (non-closed singly connected)   (-2.5000000000000000523e-09 -2.5000000000000000523e-09 0) (2.5000000000000000523e-09 2.5000000000000000523e-09 0)
    inlet_shadow_half1  59       76       ok (non-closed singly connected)   (-1.4993899989999999846e-09 -1.7738679869999999008e-09 0) (2.1029784929999998324e-09 1.5910149619999999247e-09 0)
    inlet_half0         59       95       ok (non-closed singly connected)   (-2.5000000000000000523e-09 -2.5000000000000000523e-09 0) (2.5000000000000000523e-09 2.5000000000000000523e-09 1.0000000000000000209e-08)
    inlet_half1         59       76       ok (non-closed singly connected)   (-1.4993899989999999846e-09 -1.980907757999999998e-09 1.0000000000000000209e-08) (2.1029784929999998324e-09 1.5910149619999999247e-09 1.0000000000000000209e-08)
    wall                828      864      ok (non-closed singly connected)   (-2.5000000000000000523e-09 -2.5000000000000000523e-09 0) (2.5000000000000000523e-09 2.5000000000000000523e-09 1.0000000000000000209e-08)

Checking geometry...
    Overall domain bounding box (-2.5000000000000000523e-09 -2.5000000000000000523e-09 0) (2.5000000000000000523e-09 2.5000000000000000523e-09 1.0000000000000000209e-08)
    Mesh (non-empty, non-wedge) directions (1 1 1)
    Mesh (non-empty) directions (1 1 1)
    Boundary openness (-2.6567998704002758746e-17 1.093434397528899584e-17 -1.5554229082299158587e-17) OK.
    Max cell openness = 3.045985297783277465e-16 OK.
    Max aspect ratio = 2.3968495768130080315 OK.
    Minumum face area = 7.4714845148913033615e-20. Maximum face area = 2.4279173380366694604e-19.  Face area magnitudes OK.
    Min volume = 3.1827001516200503896e-29. Max volume = 1.0580237499368877868e-28.  Total volume = 1.9535397429082647449e-25.  Cell volumes OK.
    Mesh non-orthogonality Max: 13.560431309723149695 average: 4.1513739650341596743
    Non-orthogonality check OK.
    Face pyramids OK.
    Max skewness = 3.0733065837817203914 OK.
    Coupled point location match (average 0) OK.
#0  Foam::error::printStack(Foam::Ostream&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1  Foam::sigSegv::sigHandler(int) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2   in "/lib/x86_64-linux-gnu/libc.so.6"
#3  Foam::polyMeshTetDecomposition::checkFaceTets(Foam::polyMesh const&, double, bool, Foam::HashSet<int, Foam::Hash<int> >*) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#4  
 in "/opt/openfoam211/platforms/linux64GccDPOpt/bin/checkMesh"
#5  
 in "/opt/openfoam211/platforms/linux64GccDPOpt/bin/checkMesh"
#6  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#7  
 in "/opt/openfoam211/platforms/linux64GccDPOpt/bin/checkMesh"
Segmentation fault (core dumped)

best regards

[wyldckat]

Greetings Hashemkabir,

If you could provide/share a simple mesh that reproduces this error message, I (or anyone else) could test with other versions/variant of OpenFOAM, for diagnosing if this problem has already been fixed in the more recent versions.

Because the first error message hints that the problem has something to do with an ill-formed face for cell number 637. This was either because the mesh was not converted with success, or because the two patches that were assigned with the type "cyclic" are incompatible.

The second error message is hinting at the same problem, but it isn't able to provide more specific details, but most likely has to do with the invalid face number "-1" that the first error message is referring to.

Without having a test case or mesh, I'm not able to diagnose any further. My guess is that you're using either a polyhedral mesh or a tetrahedral mesh, therefore my suggestion would be for you to generate an hexahedral mesh in Gambit and then convert it to OpenFOAM. Such a mesh should provide better results.

Beyond this, these errors reminds me of this thread: http://www.cfd-online.com/Forums/ope...port-icem.html

Best regards,
Bruno

[esujby]

i have the same issue, when i run snappyhexmesh and try to decompose the mesh when i run DecomposePar, i get the following:

 parallels@ubuntu:~/OpenFOAM-2.4.0/receiver$ decomposePar
/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2.4.0                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
Build  : 2.4.0-f0842aea0e77
Exec   : decomposePar
Date   : Oct 24 2015
Time   : 13:29:26
Host   : "ubuntu"
PID    : 19295
Case   : /home/parallels/OpenFOAM-2.4.0/receiver
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Allowing user-supplied system call operations

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



Decomposing mesh region0

Create mesh

Calculating distribution of cells
Selecting decompositionMethod hierarchical

Finished decomposition in 34.4 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 = 3321997

    From function polyMesh::polyMesh
(
    const IOobject&,
    const Xfer<pointField>&,
    const Xfer<faceList>&,
    const Xfer<cellList>&
)

    in file meshes/polyMesh/polyMesh.C at line 654.

FOAM aborting

#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::error::abort() at ??:?
#2  Foam::polyMesh::polyMesh(Foam::IOobject const&, Foam::Xfer<Foam::Field<Foam::Vector<double> > > const&, Foam::Xfer<Foam::List<Foam::face> > const&, Foam::Xfer<Foam::List<Foam::cell> > const&, bool) at ??:?
#3  ? at ??:?
#4  ? at ??:?
#5  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#6  ? at ??:?
Aborted (core dumped)
parallels@ubuntu:~/OpenFOAM-2.4.0/receiver$

please help shed more light.
thanks

[wyldckat]

Greetings to all!

I recently got a similar error message. The problem was that snappyHexMesh is designed to work only with hexahedral cells. If you have tetrahedral cells in your mesh, then snappyHexMesh will complain about that it can't find the other vertices for the hexahedral cell.

But now I've noticed that the error messages on this thread are being given by decomposePar. If this happens after using recontructParMesh, then this means that the mesh reconstruction was done incorrectly.
There are a few more options for using reconstructParMesh. You can see them by running:

reconstructParMesh -help

Two important options:

  -fullMatch        do (slower) geometric matching on all boundary faces

  -mergeTol <scalar>
                    specify the merge distance relative to the bounding box size
                    (default 1e-7)

Try using the "-fullMatch" option.

Best regards,
Bruno

[esujby]

Hello Bruno, thanks for your reply,

i did just that, tried the -fullMatch option and only got:

Finalising parallel run
parallels@ubuntu:~/OpenFOAM-2.4.0/receiver$ reconstructParMesh -fullMatch
/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2.4.0                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
Build  : 2.4.0-f0842aea0e77
Exec   : reconstructParMesh -fullMatch
Date   : Oct 25 2015
Time   : 11:00:09
Host   : "ubuntu"
PID    : 3914
Case   : /home/parallels/OpenFOAM-2.4.0/receiver
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Allowing user-supplied system call operations

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

This is an experimental tool which tries to merge individual processor
meshes back into one master mesh. Use it if the original master mesh has
been deleted or if the processor meshes have been modified (topology change).
This tool will write the resulting mesh to a new time step and construct
xxxxProcAddressing files in the processor meshes so reconstructPar can be
used to regenerate the fields on the master mesh.

Not well tested & use at your own risk!

Merge tolerance : 1e-07
Write tolerance : 1e-07
Doing geometric matching on all boundary faces.

Found 16 processor directories

Reading database "receiver/processor0"
Reading database "receiver/processor1"
Reading database "receiver/processor2"
Reading database "receiver/processor3"
Reading database "receiver/processor4"
Reading database "receiver/processor5"
Reading database "receiver/processor6"
Reading database "receiver/processor7"
Reading database "receiver/processor8"
Reading database "receiver/processor9"
Reading database "receiver/processor10"
Reading database "receiver/processor11"
Reading database "receiver/processor12"
Reading database "receiver/processor13"
Reading database "receiver/processor14"
Reading database "receiver/processor15"
End.

nothing was added to the constant boundary file.

kind regards

[wyldckat]

Quick answer: I need more details. What are the exact steps you take for generating the mesh? And is the mesh generated in parallel?

[esujby]

Hello Bruno,

Thanks for your prompt reply, i am currently trying to mesh a solar volumetric receiver using snapyhexmesh (parallel processing) using a modified chtmultiregionfoam case, I designed the CAD on solid works, exported it ar an STL file, please have a look at the extract of my blockmeshdict, snappy hex mesh dict, decomposepardict and the resulting boundary file after running reconstructparmesh - constant.

Blockmeshdict

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2.4.0                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    object      blockMeshDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

convertToMeters 1;

vertices
(
      ( 0 0 0)
      ( 0.08 0 0)
      ( 0.08 0.07 0)
      ( 0 0.07 0)
      ( 0 0 0.08)
      ( 0.08 0 0.08)
      ( 0.08 0.07 0.08)
      ( 0 0.07 0.08)
);

blocks
(
    hex (0 1 2 3 4 5 6 7) (18 19 18) simpleGrading (1 1 1)
);

edges
(
);

boundary
(
    maxY
    {
        type wall;
        faces
        (
            (3 7 6 2)
        );
    }
    minX
    {
        type patch;
        faces
        (
            (0 4 7 3)
        );
    }
    maxX
    {
        type patch;
        faces
        (
            (2 6 5 1)
        );
    }
    minY
    {
        type wall;
        faces
        (
            (1 5 4 0)
        );
    }
    minZ
    {
        type wall;
        faces
        (
            (0 3 2 1)
        );
    }
    maxZ
    {
        type wall;
        faces
        (
            (4 5 6 7)
        );
    }
);

mergePatchPairs
(
);

// ************************************************************************* //