View Issue Details

IDProjectCategoryView StatusLast Update
0001472OpenFOAMBugpublic2014-12-31 19:12
Reporterarnaud6 Assigned Tohenry  
PriorityhighSeveritycrashReproducibilityalways
Status resolvedResolutionfixed 
PlatformcentOS 6.3OSkernel Linux 2.6.2-279.el6.x86_6OS VersionGNOME 2.28.2
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 http://www.openfoam.org/mantisbt/view.php?id=1465,
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
"
--> FOAM FATAL IO ERROR:
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
http://www.cfd-online.com/Forums/openfoam-solving/72476-fatal-io-error-about-sout.html
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.

Activities

wyldckat

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: http://www.openfoam.org/mantisbt/view.php?id=903

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,
Bruno

arnaud6

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
http://www.openfoam.org/mantisbt/view.php?id=1033 ?

henry

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

https://github.com/OpenFOAM/OpenFOAM-dev

should be tomorrow sometime.

wyldckat

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!

arnaud6

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

--> FOAM FATAL ERROR:
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 ??:?
#8
 at ??:?
#9 __libc_start_main at ??:?
#10
 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 !

henry

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.

arnaud6

2014-12-31 16:06

reporter   ~0003425

Okay,

Thanks Henry for the explanation

henry

2014-12-31 19:11

manager   ~0003427

Resolved by commit 2a614865fff303855db7403e145452f909e23ffa

in https://github.com/OpenFOAM/OpenFOAM-dev

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