Closed EdwinChan closed 2 years ago
By the way, output#/file_number actually refers to the next output, in the same way next_time does; that is not documented in the wiki.
This isn't exposed as a user-controlled option for input files or the command line, I believe. What do you suggest we document about it in the Wiki?
By the way, how are you reading the binary timestamps of the .rst
files? I cant remember if there is a convenient command line option to do so.
If output#/next_time
is documented, why not output#/file_number
? We can simply say it overrides the numbering of the next output, i.e., the description can mirror output#/next_time
. A user carrying out a two-part simulation may want to restart the count for the second part.
The time is saved in a simple binary format in the restart files, so it can be easily read with, e.g., the Python package struct
. It'd be great if the user could override the time as well, for the same reason as above, but that'd be another issue.
By the way, how are you reading the binary timestamps of the
.rst
files? I cant remember if there is a convenient command line option to do so.
This was never robust enough (endianness, padding bytes, etc.) to make it to the codebase, but an example of using struct
to read restart metadata is here in case anyone wants it: https://www.physics.unlv.edu/astro/athena2019/scripts/restart_inspect.py
FYI for future readers, the script https://www.physics.unlv.edu/astro/athena2019/scripts/restart_inspect.py is only compatible with Python 2, not Python 3
Prerequisite checklist
Place an X in between the brackets on each line as you complete these checks:
Summary of issue
When
output#/dt
andoutput#/next_time
are specified during a restart, fix-ups applied to output times (see #310) are omitted when these two parameters are on the command line rather than in an input file.Steps to reproduce
We use two input files
athinput-time1
andathinput-time2
containing, among others, the following lines:Expected and actual outcomes
If we run Athena++ with
and we read the binary timestamps off the restart files, we get
That is to say, the next output after the restart happens at time
next_time + n * dt
that is later than the restart time for some non-negative integern
. I would argue the output should happen as soon as possible ifnext_time
is earlier than the restart time, because that would give us an easy way to make a debug dump right at the point of restart, which would be useful if the restart file has been modified externally, or if the restart process is customized to do more than just reading in the data, but that parameter interpretation is up for debate.A more serious problem arises if we then run
The timestamps are now
Output happens and
next_time += dt
every cycle untilnext_time
exceeds the simulation time. The utility of this catch-up is almost zilch, unless the user explicitly wantsnext_time == file_number * dt
. By the way,output#/file_number
actually refers to the next output, in the same waynext_time
does; that is not documented in the wiki.However, if we run:
The timestamps are normal:
Note that the parameters on the command line are changed to demonstrate that they do override the ones in the input file. The order of command-line arguments is immaterial.
The examples here use restart files for simplicity, but the same bug should apply to other forms of output as well.
Additional comments and/or proposed solution
There have been multiple issues addressing time-step issues: #36, #62, #116, #310. #62 mentions the function ParameterInput::ForwardNextTime(); it seems that this function and its friend ParameterInput::RollbackNextTime() are called only when an input file is supplied:
https://github.com/PrincetonUniversity/athena/blob/5871884c40f3d93d11bb8bd447fd03506ba24711/src/main.cpp#L229-L231 https://github.com/PrincetonUniversity/athena/blob/5871884c40f3d93d11bb8bd447fd03506ba24711/src/main.cpp#L297-L301
Version info