View Issue Details

IDProjectCategoryView StatusLast Update
0000903OpenFOAM[All Projects] Bugpublic2014-12-31 19:14
Reporteruser689Assigned Tohenry 
Status resolvedResolutionfixed 
PlatformLinuxOSOpenSuseOS Version11.1
Product Version 
Fixed in Version 
Summary0000903: blockMesh crashes ("bad set size") when trying too build large meshes with enough RAM
DescriptionFirst, this bug has been identified with a 2.0.x version of OpenFOAM, on a cluster with the following kernel :
Linux #1 SMP 2011-04-14 10:12:31 +0200 x86_64 x86_64 x86_64
I am working on a fat node of 3TB RAM, allocable through a PBS system.

The problem is that when I try to build with blockMesh a mesh of about 600 millions cells, I get an error message of this kind (extract of the blockMesh log):

Creating points with scale 1

bad set size -835122496

    From function List<T>::setSize(const label)
    in file /usr/local/OpenFoam/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/List.C at line 322.

FOAM aborting

The full log is given in attachment.

I use here a 1TB RAM request. When I try to make the same mesh but with 4 times less cells with a 250 Gb RAM request, it works without problems. That why I think that it is not a problem of RAM run short.
Steps To ReproduceAttached to this report a blockMeshDict file is given. Trying to build a mesh with blockMesh on the basis of this blockMeshDict with at least 575 GB RAM (the amount of RAM needed according to Wyldkcat, see, will lead to the reported bug (at least with OF.2.0.x).
Additional InformationSuch large meshes would be very helpful for modelling in geosciences, that's why the solving of this bug would be of scientifical interest.
TagsNo tags attached.



2013-06-27 18:10


blockMeshBug.tar (10,752 bytes)


2014-12-29 15:31

updater   ~0003399

This seems related to this bug report: - In other words, the limit is very likely that the integer (label) variables in OpenFOAM are by default 32-bit, because that saves a lot of RAM for the conventional 64-bit usage.

It's hard to have a system with this much RAM, so it'll probably take a while longer until this is "naturally" fixed.

Let me do some more number crunching on this:
- The attached mesh specifications has a cell count of "3396 3396 50", which equates to 576,640,800 cells.
- It should have around "3397 3397 51" vertexes, which is 588,520,059 points.
- Face count... uhm... too lazy to do proper mathematics on this, but somewhere between 4 and 6 times the number of cells. This would equate to a number between 2,306,563,200 and 3,459,844,800. In comparison to 2^31 = 2,147,483,648

Yep, I guess the mystery is solved... it's the face count that broke the mesh generation. Again, this should be fixed when is fixed.


2014-12-31 19:14

manager   ~0003428

Resolved by commit 2a614865fff303855db7403e145452f909e23ffa


Issue History

Date Modified Username Field Change
2013-06-27 18:10 user689 New Issue
2013-06-27 18:10 user689 File Added: blockMeshBug.tar
2014-12-29 15:31 wyldckat Note Added: 0003399
2014-12-31 19:14 henry Note Added: 0003428
2014-12-31 19:14 henry Status new => resolved
2014-12-31 19:14 henry Resolution open => fixed
2014-12-31 19:14 henry Assigned To => henry