View Issue Details

IDProjectCategoryView StatusLast Update
0001472OpenFOAM[All Projects] Bugpublic2014-12-31 19:12
Reporterarnaud6Assigned Tohenry 
Status resolvedResolutionfixed 
PlatformcentOS 6.3OSkernel Linux 2.6.2-279.el6.x86_6OS VersionGNOME 2.28.2
Product Version 
Fixed in Version 
Summary0001472: IOStream "Sout" crash using fluent3DMeshToFoam
DescriptionI am reporting a crash I have just had using the utility fluent3DMeshToFoam.
As I have previously reported in,
memory issue combined with high algorithm complexity must be involved in this case too.

I am using a 512Gb workstation (which should be more than 2 times the maximum amount of memory used by this utility to convert this mesh)

To give a quick summary I am using fluent3DMeshToFoam to convert fluent .msh file into an openfoam format.

My different cases are:
*50M cells -> works without problem
*85M cells -> works without problem
*160M cells -> works if I use -ignoreFaceGroups not to consider the massive 400M faces faceZone at the writing stage
*360M cells (new case) -> crash at the beginning of the utility (while reading the first cellZone composed of 300M cells). Crash after 4h of running time.

Error message is
error in IOstream "Sout" for operation Ostream& operator<<(Ostream&, const char*)

file: Sout at line 29.

    From function IOstream::check(const char*) const
    in file db/IOstreams/IOstreams/IOstream.C at line 99.

FOAM exiting

I can't find this file to look at the source code.

I have found a thread dealing with it on CFD Online
but no satisfying answer was given.

There may be something limiting the use of fluent3DMeshToFoam to convert important unstructured meshes.

Unfortunately I am unable to provide a test case. The crash only happens with an important mesh.
Steps To ReproduceUnable to provide it
TagsNo tags attached.



2014-12-30 18:10

updater   ~0003418

Hi Arnaud6,

Mmm... I'm starting to suspect you might be hitting a technical limit in the current integers used in OpenFOAM by default, as detailed in the first comment here:

Regarding "Sout", I suspect that it's the name for a "string stream", which might be used as an intermediate before writing out values to file. Which reminds me: what options are you using in "system/controlDict"? Namely regarding precision, format and compression options.

Best regards,


2014-12-30 19:23

reporter   ~0003419

Hi Wyldckat

Well done for pointing my crash to this relevant topic about memory integer storage. They must be closely related!

For the controlDict file, here is what I use
    purgeWrite 0;
    writeFormat ascii;
    writePrecision 6;
    writeCompression uncompressed;
    timeFormat general;
    timePrecision 6;
Do you think I should try something else ?

Do you know about an update to store the integers to 64 bits instead of 32 ? Does the extended openfoam project offer the option ?

Any update about this issue ?


2014-12-30 20:07

manager   ~0003420

I am finalising the update of OpenFOAM-dev to fully support 64bit integers including support for scotch and ptscotch. The only remaining issues relate to CGAL which may have wait. Once testing is complete I will push into

should be tomorrow sometime.


2014-12-30 20:17

updater   ~0003421

@Arnaud6: Try changing to this:

    writeFormat binary;

It might help circumvent some issues, such as a crazy maximum file size problem; or problems converting text to binary then back to text... values such as NaN or Inf come to mind.

If "64-bit integers" isn't the solution, then we'll have to resort to using a modified source code version of this utility for you to run and to get some diagnosing data on your side.

@Henry: Nice!


2014-12-31 15:48

reporter   ~0003423

Hi Wyldckat and Henry,

Good to hear about the 64b integers!

I have tried to write in binary Wyldckat. Unfortunately I got a crash but a different one !
The utility ran for 5h30 and went right until the openfoam mesh writing stage. It managed to create the files "points" and "neighbour" but crashed when writing the file "faces".

Here is the error message

bad size -156695857

    From function List<T>::List(const label size)
    in file /cfd/apps/OpenFOAM/OpenFOAM-2.3.1/src/OpenFOAM/lnInclude/List.C at line 49.

FOAM aborting

#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::error::abort() at ??:?
#2 Foam::List<int>::List(int) at ??:?
#3 Foam::Ostream& Foam::operator<< <Foam::face, int>(Foam::Ostream&, Foam::CompactIOList<Foam::face, int> const&) at ??:?
#4 Foam::CompactIOList<Foam::face, int>::writeData(Foam::Ostream&) const at ??:?
#5 Foam::regIOobject::writeObject(Foam::IOstream::streamFormat, Foam::IOstream::versionNumber, Foam::IOstream::compressionType) const at ??:?
#6 Foam::CompactIOList<Foam::face, int>::writeObject(Foam::IOstream::streamFormat, Foam::IOstream::versionNumber, Foam::IOstream::compressionType) const at ??:?
#7 Foam::objectRegistry::writeObject(Foam::IOstream::streamFormat, Foam::IOstream::versionNumber, Foam::IOstream::compressionType) const at ??:?
 at ??:?
#9 __libc_start_main at ??:?
 at ??:?

I went to this List.C file and indeed, it is written that if the size is < 0, openfoam will print the error message. But I have no idea what this size is supposed to be (it is different from all the other quantities -faces, cells, ...etc) and more important, why it is negative in my case ...

Should I create a new bug report for this case ?

Thanks Wyldckat, I was almost on the point to fix my last problems with this binary solution !


2014-12-31 16:04

manager   ~0003424

The most likely reason for the label being negative is because of an overflow which will be resolved if you run with 64bit labels. I have everything in OpenFOAM-dev compiling and running with 64bit labels and running final tests. I will push these developments today.


2014-12-31 16:06

reporter   ~0003425


Thanks Henry for the explanation


2014-12-31 19:11

manager   ~0003427

Resolved by commit 2a614865fff303855db7403e145452f909e23ffa


Issue History

Date Modified Username Field Change
2014-12-30 16:04 arnaud6 New Issue
2014-12-30 18:10 wyldckat Note Added: 0003418
2014-12-30 19:23 arnaud6 Note Added: 0003419
2014-12-30 20:07 henry Note Added: 0003420
2014-12-30 20:17 wyldckat Note Added: 0003421
2014-12-31 15:48 arnaud6 Note Added: 0003423
2014-12-31 16:04 henry Note Added: 0003424
2014-12-31 16:06 arnaud6 Note Added: 0003425
2014-12-31 19:11 henry Note Added: 0003427
2014-12-31 19:11 henry Status new => resolved
2014-12-31 19:11 henry Resolution open => fixed
2014-12-31 19:11 henry Assigned To => henry