View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004181 | OpenFOAM | Bug | public | 2024-11-20 15:13 | 2024-11-21 17:04 |
| Reporter | scramjetFoam | Assigned To | will | ||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | GNU/Linux | OS | Other | OS Version | (please specify) |
| Product Version | dev | ||||
| Fixed in Version | 12 | ||||
| Summary | 0004181: Calculating Lagrangian using cpuLoad, reconstrut errors will occur if writeFormat uses ascii, but binary does not | ||||
| Description | --> FOAM FATAL IO ERROR: wrong token type - expected Scalar, found on line 34 the punctuation token '-' file: /public/home/XXXXXX/processor1/1e-06/lagrangian/cloud/mass0 at line 34. From function Foam::Istream& Foam::operator>>(Foam::Istream&, Foam::doubleScalar&) in file lnInclude/Scalar.C at line 102. FOAM exiting | ||||
| Steps To Reproduce | Change writeFormat to binary in the aachenBomb tutorial to repeat the error. | ||||
| Tags | No tags attached. | ||||
|
|
To make the bug report, which seems to address a really existing issue, more complete, I investigated the case using your sometimes misleading instructions: 1.) One needs to set ascii format, not binary 2.) By, default, there is no write at 1e-06 (writeInterval 5e-05), but one can see the issue in processor1/5e-05/lagragian/cloud/mass0 (at least sometimes - see later comments) So to be able to reproduce, run: foamDictionary -entry writeFormat -set ascii system/controlDict foamDictionary -entry endTime -set 5e-05 system/controlDict # to just run until the first write Observations: -) Results change when re-running the case, e.g., I get once the error on processor3 --> FOAM FATAL IO ERROR: wrong token type - expected Scalar, found on line 108 the punctuation token '-' file: /opt/OpenFOAM/OpenFOAM-dev/tutorials/multicomponentFluid/aachenBomb/processor3/5e-05/lagrangian/cloud/mass0 at line 108. From function Foam::Istream& Foam::operator>>(Foam::Istream&, Foam::doubleScalar&) in file lnInclude/Scalar.C at line 102. FOAM exiting and next execution on processor9 on a different line --> FOAM FATAL IO ERROR: wrong token type - expected Scalar, found on line 51 the punctuation token '-' file: /opt/OpenFOAM/OpenFOAM-dev/tutorials/multicomponentFluid/aachenBomb/processor9/5e-05/lagrangian/cloud/mass0 at line 51. From function Foam::Istream& Foam::operator>>(Foam::Istream&, Foam::doubleScalar&) in file lnInclude/Scalar.C at line 102. FOAM exiting -) Related to that, processor1/5e-05/lagrangian does not always exist. But this could be standard behaviour due to lagragian stochastic injection and / or distribution? -) If I disable load-balancing, the problem seems to go away foamDictionary -entry distributor -remove constant/dynamicMeshDict -) The problem also exists with parMetis distributor -) Disabling multiConstraints does not help -) The values in mass0 file seem really off, they are sometimes 1e-316, sometimes 2000, and sometimes even negative. When running without re-distribution in parallel, I see rather uniform values in the 1e-10 to 1e-11 range. Summary from my observations: There seems to be a bug when using distribution (both Zoltan and parMetis tried) with lagragian. One can see the issue by inspecting mass0 files in aachenBomb tutorial run in parallel in the processor directories, by first changing to ascii file format, and no other modifications required. @scramjetFoam: Could you confirm my observations to ensure that this isn't a local issue from our cluster / installation? |
|
|
Another observation: This does not depend on using the ascii format, one can run aachenBomb as is, and use foamFormatConvert to see the same issue ./Allrun-parallel foamDictionary -entry writeFormat -set ascii system/controlDict foamFormatConvert -latestTime I see unplausible values in 5e-05/lagragian/cloud/mass0 after converting to ascii: -nan, 3e-316, 0.5, 2050, negative values, ... |
|
|
@cgoessni: Then this is getting similar to issue #4174 |
|
|
@cgoessni I am able to reproduce this error on my local computer, local workstation and cloud HPC. |
|
|
The issue might be that the copy constructor in SprayParcel.C is missing the mass0-field. The constructor is rarely used, but I guess redistribution might use it? I can't confirm this now, as I'm just reading the source code, but clearly there is a bug in SprayParcel.C. |
|
|
Yes, it's the missing mass0 from the constructor. Almost certainly for issue #4174 also. Fixed in v12 and in dev. https://github.com/OpenFOAM/OpenFOAM-12/commit/fe01324f5366aac6e3dedcc4cc80a1bd34fe49a1 https://github.com/OpenFOAM/OpenFOAM-dev/commit/fed97e3529262cfb3c07fa7f697ac211ebd5807f |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-11-20 15:13 | scramjetFoam | New Issue | |
| 2024-11-21 08:19 | cgoessni | Note Added: 0013468 | |
| 2024-11-21 09:19 | cgoessni | Note Added: 0013469 | |
| 2024-11-21 09:54 | wyldckat | Relationship added | related to 0004174 |
| 2024-11-21 09:55 | wyldckat | Note Added: 0013470 | |
| 2024-11-21 11:01 | scramjetFoam | Note Added: 0013471 | |
| 2024-11-21 15:46 | tniemi | Note Added: 0013472 | |
| 2024-11-21 17:04 | will | Assigned To | => will |
| 2024-11-21 17:04 | will | Status | new => resolved |
| 2024-11-21 17:04 | will | Resolution | open => fixed |
| 2024-11-21 17:04 | will | Fixed in Version | => 12 |
| 2024-11-21 17:04 | will | Note Added: 0013473 |
