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

decomposePar problem: Cell 0contains face labels out of range

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

Like Tree2Likes

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   December 2, 2014, 12:08
Default decomposePar problem: Cell 0contains face labels out of range
  #1
Senior Member
 
Join Date: Feb 2010
Posts: 213
Rep Power: 12
vaina74 is on a distinguished road
Hi all, I obtain an unknow error message when trying to launch decomposePar
Code:
--> 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 is offline   Reply With Quote

Old   December 3, 2014, 05:32
Default
  #2
Senior Member
 
Join Date: Feb 2010
Posts: 213
Rep Power: 12
vaina74 is on a distinguished road
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
Code:
    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.
vaina74 is offline   Reply With Quote

Old   December 3, 2014, 11:43
Default
  #3
Super Moderator
 
Tobi's Avatar
 
Tobias Holzmann
Join Date: Oct 2010
Location: Augsburg
Posts: 2,270
Blog Entries: 6
Rep Power: 39
Tobi has a spectacular aura aboutTobi has a spectacular aura about
Send a message via ICQ to Tobi Send a message via Skype™ to 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.
__________________
Keep foaming,
Tobias Holzmann
Tobi is online now   Reply With Quote

Old   December 3, 2014, 14:22
Default
  #4
Senior Member
 
Join Date: Feb 2010
Posts: 213
Rep Power: 12
vaina74 is on a distinguished road
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.
Code:
/*--------------------------------*- 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
vaina74 is offline   Reply With Quote

Old   December 3, 2014, 15:11
Default
  #5
Super Moderator
 
Tobi's Avatar
 
Tobias Holzmann
Join Date: Oct 2010
Location: Augsburg
Posts: 2,270
Blog Entries: 6
Rep Power: 39
Tobi has a spectacular aura aboutTobi has a spectacular aura about
Send a message via ICQ to Tobi Send a message via Skype™ to 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)
__________________
Keep foaming,
Tobias Holzmann
Tobi is online now   Reply With Quote

Old   December 3, 2014, 15:54
Default
  #6
Senior Member
 
Join Date: Feb 2010
Posts: 213
Rep Power: 12
vaina74 is on a distinguished road
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
Code:
#!/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
Code:
#!/bin/sh
decomposePar
mpirun -n 4 renumberMesh -overwrite -parallel
pyFoamPlotRunner.py mpirun -np 8 simpleFoam -parallel
reconstructParMesh -latestTime
Thanks for your attention, regards.
vaina74 is offline   Reply With Quote

Old   December 3, 2014, 18:33
Default
  #7
Super Moderator
 
Tobi's Avatar
 
Tobias Holzmann
Join Date: Oct 2010
Location: Augsburg
Posts: 2,270
Blog Entries: 6
Rep Power: 39
Tobi has a spectacular aura aboutTobi has a spectacular aura about
Send a message via ICQ to Tobi Send a message via Skype™ to Tobi
Hey,

nice geometry, my laptop is bad so I will check it tomorrow but I think I know what is wrong here!
__________________
Keep foaming,
Tobias Holzmann
Tobi is online now   Reply With Quote

Old   December 4, 2014, 04:49
Default
  #8
Super Moderator
 
Tobi's Avatar
 
Tobias Holzmann
Join Date: Oct 2010
Location: Augsburg
Posts: 2,270
Blog Entries: 6
Rep Power: 39
Tobi has a spectacular aura aboutTobi has a spectacular aura about
Send a message via ICQ to Tobi Send a message via Skype™ to 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:
Code:
cat * > regionSTL.stl
surfaceCheck regionSTL.stl
In your case the following output is given:
Code:
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:
Code:
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:
Code:
    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

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


So good luck!




PS: very nice geometry!
Attached Images
File Type: jpg engine.jpg (32.6 KB, 104 views)
__________________
Keep foaming,
Tobias Holzmann
Tobi is online now   Reply With Quote

Old   December 5, 2014, 13:02
Default
  #9
Senior Member
 
Join Date: Feb 2010
Posts: 213
Rep Power: 12
vaina74 is on a distinguished road
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
Code:
cat * > regionSTL.stl
surfaceCheck regionSTL.stl
Quote:
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

Quote:
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)?

Quote:
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.

Quote:
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!
vaina74 is offline   Reply With Quote

Old   December 5, 2014, 13:25
Default
  #10
Super Moderator
 
Tobi's Avatar
 
Tobias Holzmann
Join Date: Oct 2010
Location: Augsburg
Posts: 2,270
Blog Entries: 6
Rep Power: 39
Tobi has a spectacular aura aboutTobi has a spectacular aura about
Send a message via ICQ to Tobi Send a message via Skype™ to Tobi
Quote:
Originally Posted by vaina74 View Post
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
Quote:
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 ?


Quote:
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.


Quote:
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 ?

Quote:
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.

Quote:
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
Code:
-mergeTol 1e-6
The application will use a default value and that value has to be the same as in the snappyHexMeshDict (last line):
Code:
// 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.


Quote:
Thanks again for your precious help!
You are welcome.
__________________
Keep foaming,
Tobias Holzmann
Tobi is online now   Reply With Quote

Old   December 6, 2014, 17:52
Default
  #11
Senior Member
 
Join Date: Feb 2010
Posts: 213
Rep Power: 12
vaina74 is on a distinguished road
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.
Quote:
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
Code:
    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
Code:
writeFlags
(
    layerFields     // write volScalarField for layer coverage
Thanks for your big help (and patience).
vaina74 is offline   Reply With Quote

Old   March 18, 2015, 10:43
Default
  #12
Member
 
Stephanie
Join Date: Feb 2015
Location: Magdeburg, Germany
Posts: 71
Rep Power: 6
stephie is on a distinguished road
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:

Code:
 --> 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

Last edited by wyldckat; March 21, 2015 at 09:59. Reason: Added [CODE][/CODE]
stephie is offline   Reply With Quote

Old   March 21, 2015, 10:04
Default
  #13
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,943
Blog Entries: 42
Rep Power: 121
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
Hi Stephie,

My guess is that the mesh is damaged somehow. Run the following command:
Code:
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

Last edited by wyldckat; October 24, 2015 at 11:55. Reason: see "Edit:"
wyldckat is offline   Reply With Quote

Old   August 11, 2015, 13:02
Default Error in cyclic boundar condition
  #14
New Member
 
Hashem Nowruzi
Join Date: Jul 2015
Posts: 3
Rep Power: 6
Hashemkabir is on a distinguished road
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:

Code:
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
Code:
/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  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

Last edited by wyldckat; August 12, 2015 at 17:31. Reason: Added [CODE][/CODE] markers
Hashemkabir is offline   Reply With Quote

Old   August 12, 2015, 17:47
Default
  #15
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,943
Blog Entries: 42
Rep Power: 121
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
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
__________________
wyldckat is offline   Reply With Quote

Old   October 24, 2015, 09:35
Default
  #16
Senior Member
 
nasir musa yakubu
Join Date: Mar 2014
Location: Birmingham
Posts: 109
Rep Power: 7
esujby is on a distinguished road
i have the same issue, when i run snappyhexmesh and try to decompose the mesh when i run DecomposePar, i get the following:

Code:
 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

Last edited by wyldckat; October 24, 2015 at 11:57. Reason: Added [CODE][/CODE] markers
esujby is offline   Reply With Quote

Old   October 24, 2015, 12:08
Default
  #17
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,943
Blog Entries: 42
Rep Power: 121
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
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:
Code:
reconstructParMesh -help
Two important options:
Code:
  -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
__________________
wyldckat is offline   Reply With Quote

Old   October 25, 2015, 07:13
Default
  #18
Senior Member
 
nasir musa yakubu
Join Date: Mar 2014
Location: Birmingham
Posts: 109
Rep Power: 7
esujby is on a distinguished road
Hello Bruno, thanks for your reply,

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

Code:
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

Last edited by wyldckat; October 25, 2015 at 09:10. Reason: Added [CODE][/CODE] markers
esujby is offline   Reply With Quote

Old   October 25, 2015, 09:13
Default
  #19
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,943
Blog Entries: 42
Rep Power: 121
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
Quick answer: I need more details. What are the exact steps you take for generating the mesh? And is the mesh generated in parallel?
wyldckat is offline   Reply With Quote

Old   October 25, 2015, 13:03
Default
  #20
Senior Member
 
nasir musa yakubu
Join Date: Mar 2014
Location: Birmingham
Posts: 109
Rep Power: 7
esujby is on a distinguished road
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

Code:
/*--------------------------------*- 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
(
);

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

Last edited by wyldckat; October 25, 2015 at 13:11. Reason: Added [CODE][/CODE] markers
esujby is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
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 Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
[ICEM] Error in mesh writing helios ANSYS Meshing & Geometry 19 January 8, 2019 11:56
FvMatrix coefficients shrina OpenFOAM Running, Solving & CFD 10 October 3, 2013 15:38
Error message: 8 face(s) not in face lists of adjacent cells jyoung79 FLUENT 0 November 10, 2012 17:09
[blockMesh] error message with modeling a cube with a hold at the center hsingtzu OpenFOAM Meshing & Mesh Conversion 2 March 14, 2012 10:56
how to access each cell of a face? (user fortran) Katariina CFX 3 January 28, 2008 10:16


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