View Issue Details

IDProjectCategoryView StatusLast Update
0004181OpenFOAMBugpublic2024-11-21 11:01
ReporterscramjetFoam Assigned To 
PrioritynormalSeveritycrashReproducibilityalways
Status newResolutionopen 
PlatformGNU/LinuxOSOtherOS Version(please specify)
Product Versiondev 
Summary0004181: 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 ReproduceChange writeFormat to binary in the aachenBomb tutorial to repeat the error.
TagsNo tags attached.

Relationships

related to 0004174 closedhenry The reconstruct process crashes when there is a -nan value in the Lagrangian mass0 

Activities

cgoessni

2024-11-21 08:19

reporter   ~0013468

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?

cgoessni

2024-11-21 09:19

reporter   ~0013469

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

wyldckat

2024-11-21 09:55

updater   ~0013470

@cgoessni: Then this is getting similar to issue #4174

scramjetFoam

2024-11-21 11:01

reporter   ~0013471

@cgoessni I am able to reproduce this error on my local computer, local workstation and cloud HPC.

Issue History

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