View Issue Details

IDProjectCategoryView StatusLast Update
0001557OpenFOAM[All Projects] Bugpublic2015-03-08 00:30
Reporteruser838Assigned Tohenry 
PrioritynormalSeverityminorReproducibilityunable to reproduce
Status closedResolutionno change required 
PlatformLinux RHel 6OSRHel 6OS Version6
Product Version 
Fixed in Version 
Summary0001557: Solver not able to read folder above 1 million, if not written in scientific notation
DescriptionI ran into the following bug:

When I start a simulation from "latest time step" and the time step is above 1 million, this timestep has to be written in scientific notation in order to be recognized.

I'm using CHF multiregion foam.

In other words, 1250000 is not recognized whereas 1.25e+06 is recognised.

This implies that I have to rename the folder accordingly if I want to run the case from "latest time"
Steps To ReproduceRename a latest time folder as a time step above 1 million, without using scientific notation: for example rename it to 1250000.

run the case from "latest time step".

The solver will say:

--> FOAM FATAL IO ERROR:
cannot find file

file: /afs/cern.ch/work/g/gbozza/private/OpenFOAM/SLC6/OpenFOAM/gbozza-2.3.x/run/mqxfnewGeometryNewEnergyDepositionMap/aperture150mmNewCoilsQuenchHeaters50mmHolesSpacing2.1KHX7.5e34LuminosityNewPeakOpenKeys/1.25e+06/Helium/T at line 0.

    From function regIOobject::readStream()
    in file db/regIOobject/regIOobjectRead.C at line 73.

FOAM exiting
TagsNo tags attached.

Activities

user15

2015-03-06 06:48

  ~0003974

what is the value of your timePrecision in controlDict?

what happens if you increase it to...lets say 10?

henry

2015-03-06 09:30

manager   ~0003976

I am unable to reproduce the problem. No matter what I set timePrecision the writing and reading of the time directories is consistent. So if timePrecision is large I get the 1250000 directory written and the case will restart from it. If I set timePrecision small the time directory is written as 1.25e+06 and the case restarts from it i.e. IO is symmetric.

user838

2015-03-06 09:51

  ~0003979

Dear Henry,

thanks for your reply. Can you please try with chtMultiRegionFoam? I can always reproduce the problem and it has been going on for months.

henry

2015-03-06 09:54

manager   ~0003981

What timePrecision are you running with?

user838

2015-03-06 10:49

  ~0003983

Hi Henry,

problem fixed! For time precision 6, it only reads scientific notation. For time precision higher than 6, it reads everything.

However, this is definitely a bug.

Thanks

Gennaro

henry

2015-03-06 10:51

manager   ~0003984

In what way is this a bug? The IO formats are consistent, I checked. I am still unable to reproduce the behavior you see.

user838

2015-03-06 12:38

  ~0003985

I explain you why this is a bug:

let's assume I name the folder 1260000 and use time precision 6.

I run the solver:

[gbozza@pcca3017 aperture150mmNewCoilsQuenchHeaters50mmHolesSpacing1.9KHX7.5e34LuminosityNewPeakOpenKeys]$ hellChtMultiRegionSimpleFoam
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2.3.x |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : 2.3.x-36fdb4787770
Exec : hellChtMultiRegionSimpleFoam
Date : Mar 06 2015
Time : 13:33:37
Host : "pcca3017.cern.ch"
PID : 7669
Case : /afs/cern.ch/work/g/gbozza/private/OpenFOAM/SLC6/OpenFOAM/gbozza-2.3.x/run/mqxfnewGeometryNewEnergyDepositionMap/aperture150mmNewCoilsQuenchHeaters50mmHolesSpacing1.9KHX7.5e34LuminosityNewPeakOpenKeys
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Disallowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create fluid mesh for region Helium for time = 1.26e+06

Create solid mesh for region Al-Collars-Bottom for time = 1.26e+06

Create solid mesh for region Al-Collars-Left for time = 1.26e+06

Create solid mesh for region Al-Collars-Right for time = 1.26e+06

Create solid mesh for region Al-Collars-Top for time = 1.26e+06

Create solid mesh for region AlignmentKeyG10-BL1 for time = 1.26e+06

Create solid mesh for region AlignmentKeyG10-BL2 for time = 1.26e+06

Create solid mesh for region AlignmentKeyG10-BR1 for time = 1.26e+06

Create solid mesh for region AlignmentKeyG10-BR2 for time = 1.26e+06

Create solid mesh for region AlignmentKeyG10-UL1 for time = 1.26e+06

Create solid mesh for region AlignmentKeyG10-UL2 for time = 1.26e+06

Create solid mesh for region AlignmentKeyG10-UR1 for time = 1.26e+06

Create solid mesh for region AlignmentKeyG10-UR2 for time = 1.26e+06

Create solid mesh for region Axial-Rod-BL for time = 1.26e+06

Create solid mesh for region Axial-Rod-BR for time = 1.26e+06

Create solid mesh for region Tit-WPole-Int-UR2 for time = 1.26e+06

*** Reading fluid mesh equation constants and
    thermophysical properties for region Helium

    Reading Alambda

    Reading Slambda

    Reading Tlambda

    Reading SMALL

    Reading Sigma

    Reading Lref

    Reading Cp0

    Reading rho0

    Reading rho1

    Reading rho2

    Reading rho3

    Reading rho4

    Reading rho5

    Adding to TFluid

--> FOAM FATAL IO ERROR:
cannot find file

file: /afs/cern.ch/work/g/gbozza/private/OpenFOAM/SLC6/OpenFOAM/gbozza-2.3.x/run/mqxfnewGeometryNewEnergyDepositionMap/aperture150mmNewCoilsQuenchHeaters50mmHolesSpacing1.9KHX7.5e34LuminosityNewPeakOpenKeys/1.26e+06/Helium/T at line 0.

    From function regIOobject::readStream()
    in file db/regIOobject/regIOobjectRead.C at line 73.

FOAM exiting

[gbozza@pcca3017 aperture150mmNewCoilsQuenchHeaters50mmHolesSpacing1.9KHX7.5e34LuminosityNewPeakOpenKeys]$


So what did you notice? That even if the folder was named 1260000, OpenFOAM correctly read the folder as 1.26e+06 during "Create solid mesh for region AlignmentKeyG10-UL2 for time = 1.26e+06", but wrongly misread the folder after "Adding to TFluid".

henry

2015-03-06 13:07

manager   ~0003986

Indeed, with a timePrecision of 6 the correct format for the time directory is 1.26e+06, 1260000 is not consistent with a timePrecision of 6.

wyldckat

2015-03-06 14:02

updater   ~0003987

Last edited: 2015-03-06 14:03

View 2 revisions

I was browsing by and I think I understand Gennaro's (in fact, everyone's) confusion with this.
The solver (most of them) is a bit misleading regarding the time snapshot from which it's actually reading the mesh from.
The solver advertised lines like these:

   Create fluid mesh for region Helium for time = 1.26e+06

When in fact, the mesh came from either "constant" or "0.0". By indicating that it was created for "time = 1.26e+06", it leads the user to believe that the respective time folder is working as intended.

And the reason why "1.26e+06" is used in the first place, is likely because is was picked up by the "startFrom latestTime" setting in "controlDict".
But what happens then is that the code reinterprets the value in accordance to the setting in "controlDict", resulting in "1.26e+06".


Therefore, the question for Gennaro is this: What were the specific conditions and work-flow you used for creating the time folder "1250000" and/or "1260000"?
Because from what I understand from Henry's statement is that this folder should not have been created this way in the first place, at least not if "timePrecision" was still 6?


@Henry: There is a feature in OpenFOAM that extends the time precision on a need basis, introduced by the need for transient solvers that have auto-adjusting "deltaT" and that cannot loose time precision in certain cases. This is likely how the folder was created in the first place. I haven't double-checked this, but perhaps it's this feature that needs a bit of revisiting for consistency?
In fact, I believe there is another bug report related to this... I'll bump it when I find it.

henry

2015-03-06 14:10

manager   ~0003988

@Bruno: It is not clear to me how the 1250000 directory was created. In the initial post it says "Rename a latest time folder as a time step above 1 million, without using scientific notation: for example rename it to 1250000" but it is not clear if that is how it was generated in the first place. So far I have not been able to recreate the issue other than by explicit renaming of the directory in a manner which makes it explicitly inconsistent with the time precision.

user838

2015-03-06 14:15

  ~0003989

Hi Wyldckat,

thanks for your comment. Actually, since I selected "latest time" in controlDict, it is not correct to say that the mesh came from 0.

The mesh would have come from 0 if I had selected "start time" in controlDict, and we would have in this case read

Create fluid mesh for region Helium for time = 0

Having said that, I invite you to rename the latest time folder to any number you want: for example 4512000. In this case, the solver would still read
  
Create fluid mesh for region Helium for time = 4.512e+06

but then it would crash to

    Adding to TFluid

--> FOAM FATAL IO ERROR:
cannot find file

file: /afs/cern.ch/work/g/gbozza/private/OpenFOAM/SLC6/OpenFOAM/gbozza-2.3.x/run/mqxfnewGeometryNewEnergyDepositionMap/aperture150mmNewCoilsQuenchHeaters50mmHolesSpacing1.9KHX7.5e34LuminosityNewPeakOpenKeys/4.512e+06/Helium/T at line 0.

The inconstency is the following: why after starting a solver, the solver is able somewhere to interpret 4512000 as 4.512e+06 and somewhere else is not?

Genn

user838

2015-03-06 14:20

  ~0003990

@Henry: I agree that it is inconsistent with the time precision. No discussion about it.

But while it is inconsistent, it keeps working for "Create fluid mesh for region Helium for time = 4.512e+06" but not afterwards.

Not only it keeps working for Create fluid mesh, but also the solver reads 4512000 and it turns it into 4.512e+06.

henry

2015-03-06 14:38

manager   ~0003993

> Create fluid mesh for region Helium for time = 1.26e+06

Is there a mesh in the time directory 1.26e+06 or 1260000 or is the mesh being read from time 0 or constant? If the latter then there is no issue with the consistency of the time precision for the reading of the mesh.

Note that it says creating the mesh "for time" note "from time", and the mesh "for time" 1260000/1.26e+06 may be in one of the earlier time or constant directories.

henry

2015-03-06 16:25

manager   ~0003994

The format of the time directories and the timePrecision specification need to be consistent for the directory to be read.

Even if the fields from time-directory cannot be found the mesh may still be found in the constant directory which is unaffected by the timePrecision specification and time-directory format.

Issue History

Date Modified Username Field Change
2015-03-05 14:47 user838 New Issue
2015-03-06 06:48 user15 Note Added: 0003974
2015-03-06 09:30 henry Note Added: 0003976
2015-03-06 09:31 henry Priority immediate => normal
2015-03-06 09:31 henry Severity major => minor
2015-03-06 09:31 henry Reproducibility always => unable to reproduce
2015-03-06 09:51 user838 Note Added: 0003979
2015-03-06 09:54 henry Note Added: 0003981
2015-03-06 10:49 user838 Note Added: 0003983
2015-03-06 10:51 henry Note Added: 0003984
2015-03-06 12:38 user838 Note Added: 0003985
2015-03-06 13:07 henry Note Added: 0003986
2015-03-06 14:02 wyldckat Note Added: 0003987
2015-03-06 14:03 wyldckat Note Edited: 0003987 View Revisions
2015-03-06 14:10 henry Note Added: 0003988
2015-03-06 14:15 user838 Note Added: 0003989
2015-03-06 14:20 user838 Note Added: 0003990
2015-03-06 14:38 henry Note Added: 0003993
2015-03-06 16:25 henry Note Added: 0003994
2015-03-06 16:25 henry Status new => closed
2015-03-06 16:26 henry Assigned To => henry
2015-03-06 16:26 henry Resolution open => no change required
2015-03-24 00:17 liuhuafei Issue cloned: 0001632