View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001823 | OpenFOAM | Bug | public | 2015-08-12 12:46 | 2015-08-28 10:20 |
| Reporter | Assigned To | henry | |||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Platform | CentOS release 6.5 (Final) | OS | Linux | OS Version | 2.6 |
| Summary | 0001823: Simulation crashes at start while gathering viewFactors | ||||
| Description | I simulate a Testcase with radiation. The viewFactor model is choosen and i vary the number of Agglomerates. Until the number of 35000 Agglomerates everthing works fine. When i increase the number to 70000 i get the following error: addr2line failed [8] #1 Foam::sigSegv::sigHandler(int) addr2line failed [8] #2 ? addr2line failed [8] #3 Foam::UOPstream::write(char) addr2line failed [8] #4 Foam::UOPstream::write(int) addr2line failed [8] #5 Foam::operator<<(Foam::Ostream&, int) addr2line failed [8] #6 Foam::Ostream& Foam::operator<< <double>(Foam::Ostream&, Foam::UList<double> const&) [8] #7 Foam::Ostream& Foam::operator<< <Foam::List<double> >(Foam::Ostream&, Foam::UList<Foam::List<double> > const&) addr2line failed [8] #8 void Foam::Pstream::gatherList<Foam::List<Foam::List<double> > >(Foam::List<Foam::UPstream::commsStruct> const&, Foam::List<Foam::List<Foam::List<double> > >&, int, int) addr2line failed [8] #9 Foam::radiation::viewFactor::initialise() addr2line failed [8] #10 Foam::radiation::viewFactor::viewFactor(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) addr2line failed [8] #11 Foam::radiation::radiationModel::addTConstructorToTable<Foam::radiation::viewFactor>::New(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) addr2line failed [8] #12 Foam::radiation::radiationModel::New(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) addr2line failed [8] #13 ? [8] #14 __libc_start_main addr2line failed [8] #15 ? I searched in the code and it crashes in the viewFactor.C file in line 165 in the function " Pstream::gatherList(F); " Perhaps, the error occures because the F files are to big for the gathering. Mesh is splitted in 16 processors all F files together are about 10GB. I use the chtMultiRegionSimpleFoam. 1. In my opinion the error is not describing the problem for the crash. 2. Where does the error really come from? Looking at my memory usage, it looks not like a problem of the hardware. best regards Robin | ||||
| Steps To Reproduce | - generate blockMesh with enough boundary faces - faceAgglomerate to over 70000 Agglomerates - viewFactorsGen to generate the F files - start calculation with viewFactor model for Radiation | ||||
| Tags | No tags attached. | ||||
|
|
Which version of OpenFOAM are you running? |
|
|
I use the version 2.4.x |
|
|
I searched a bit around and i think the problem could be, that my labels are only int and not long. I tried an other Case with more boundary faces and 60000 agglomerates. Now viewFactorsGen is crashing with out of memory error, which is interesting, because in the other case 70000 agglomerates where no problem and watching my memory, there are 80% free. The crash here is while : " forAll(compactMap, procI) { const Map<label>& localToCompactMap = compactMap[procI]; forAllConstIter(Map<label>, localToCompactMap, iter) { compactToGlobal[iter()] = globalNumbering.toGlobal ( procI, iter.key() ); } } " in the viewFactorsGen.C It looks like the HashTable have not enough entries. But i have an 64bit system, so i wonder why... I read about a foam_label64 entry, is that necessary? Where can i check if i have 64bit labels? best regards |
|
|
@RobinZ: label64 is only available in the repository OpenFOAM-dev. You will have to set the new environment variable: WM_LABEL_SIZE=64 |
|
|
Thank you very much! But are you sure with the variables? I looked up labe.C and label.H from OF dev and OF 2.4.x in github. There is a if look up for FOAM_LABEL64 in OF 2.4.x and in the dev is chek if WM_LABEL_SIZE=64. |
|
|
Changing the labelSize ended in compiler errors for some applications. I will try to check if this option will help me. Thinking on other errors while working with the viewFactor model i believe the problem are the hashTables, which are defined by labels and with int32 the hashTables are not big enough for the number of rays between the agglomerates. Is it possible to make bigger hashTables without changing the labelSize? |
|
|
@RobinZ: I haven't taken a look at the source code to double-check, but I'm expecting that creating a hacked version just for handling hashTables with 64-bit integers will also require you to change the "forAll" loops that are hard-coded to rely on 32-bit integers for parsing these hashTables. As for 2.4.x: it's not properly prepared for handling 64-bit integers, as the implementation was only finished in OpenFOAM-dev. See https://github.com/OpenFOAM/OpenFOAM-dev/commit/2a614865fff303855db7403e145452f909e23ffa for more details on most of the changes that were needed for finishing the support for 64-bit labels (integers). There you'll also find in the comment the reason why "WM_LABEL_SIZE" is the environment variable that is configurable for this. |
|
|
I have done some simulations with the OpenFOAM dev version in 64bit for integers. I was able to compute my case without the error. But i think it is not efficient to run OpenFOAM with 64bit integers, when i only need the hashTables and labelLists for my radiation files in 64bit. The RAM usage is higher and it is more difficult to compile OF and all the things around it. Can you please change the list and hashTable length from label to long, for the list and hashtables used for radiation files like F. I know temporary the hashTable keys are only initialized by labels, but for radiation are long variables more useful. best regards Robin |
|
|
Your suggested change would require the container classes to be templated on the index type so that the view-factor code can specifically use int64_t for cases which would require it. Additionally this has not been needed by other users so additional control would need to be added to the build process to select what parts of the code should be built with int64_t addressing and which with int32_t and the addition of code to interface between these parts. All this would be a VERY large undertaking and only needed by a small number of users. If you are in a position to sponsor this development we can discuss the requirements in more detail and estimate the cost otherwise you can continue with the WM_LABEL_SIZE=64 build. |
|
|
Ok, i expected this kind of answer. The initial error of my simulation is solved. So you can close this bugreport. Thanks for your time and assessment |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-08-12 12:46 |
|
New Issue | |
| 2015-08-12 13:24 | henry | Note Added: 0005224 | |
| 2015-08-12 13:28 |
|
Note Added: 0005225 | |
| 2015-08-13 14:32 |
|
Note Added: 0005227 | |
| 2015-08-13 14:55 | wyldckat | Product Version | => 2.4.x |
| 2015-08-13 14:58 | wyldckat | Note Added: 0005229 | |
| 2015-08-14 08:34 |
|
Note Added: 0005240 | |
| 2015-08-14 09:24 |
|
Note Added: 0005241 | |
| 2015-08-16 23:33 | wyldckat | Note Added: 0005244 | |
| 2015-08-25 14:55 |
|
Note Added: 0005294 | |
| 2015-08-25 15:14 | henry | Note Added: 0005295 | |
| 2015-08-28 09:47 |
|
Note Added: 0005308 | |
| 2015-08-28 10:19 | henry | Status | new => closed |
| 2015-08-28 10:20 | henry | Assigned To | => henry |
| 2015-08-28 10:20 | henry | Resolution | open => no change required |
