View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001472||OpenFOAM||[All Projects] Bug||public||2014-12-30 16:04||2014-12-31 19:12|
|Platform||centOS 6.3||OS||kernel Linux 2.6.2-279.el6.x86_6||OS Version||GNOME 2.28.2|
|Fixed in Version|
|Summary||0001472: IOStream "Sout" crash using fluent3DMeshToFoam|
|Description||I 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.
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 Reproduce||Unable to provide it|
|Tags||No tags attached.|
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.
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
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
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.
@Arnaud6: Try changing to this:
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.
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.
#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 ??:?
#9 __libc_start_main 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 !
||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.|
Thanks Henry for the explanation
Resolved by commit 2a614865fff303855db7403e145452f909e23ffa
|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|