I didn't see this feature in the documentation so I wanted to ask if I
am missing something.
I would like to be able to append to the output from a fix ave/time
file command to an existing file, much like you can with a log or a
dump file. Is this possible? If not, would that be a worthwhile
feature request? Seems like the logic is already built in to other
systems and would just need to be applied to fix ave/time.
Thanks.
- Jesse
appending to files is generally not such a great idea. the append feature was added because (too?) many people were requesting it, so i suspect it was easier to add the feature rather than explaining why it is problematic to do it. there may be the odd scenario, where appending may actually be an acceptable choice.
appending increases the risk of file corruption, especially on HPC clusters with parallel/networked file systems, and makes “repairing” files difficult, e.g. after a job was prematurely terminated or crashed. also, certain operating systems have problems with files beyond a certain limit, and just accessing and processing/viewing very large files can have significant performance limitations (certain widely used editors will try to make a copy of a file even when just viewing).
it is much better to have multiple files. if needed, they can always be easily concatenated, e.g. using “cat”.
i have learned this practice very early in my career, when HPC systems where much less reliable than now, and benefited a lot from it and never looked back.
that said, if you feel like adding an append feature to fix ave/time, feel free to add it and submit it for review as a pull request. there is not much to it, and you can look up in dumps and other fixes how it is done.
axel.
Understood. It looks like I'm going to have to post-process the files
anyway because the simulation time goes back to zero on restart. Is
there any way to start at an arbitrary time?
- Jesse
Understood. It looks like I’m going to have to post-process the files
anyway because the simulation time goes back to zero on restart. Is
there any way to start at an arbitrary time?
i don’t understand what you mean by that. can you explain with more detail.
time is not a recorded property, but the time step number is, and it is stored in and read from restart files.
for cleanly restarting certain fixes the run command also has the options start, stop and upto, which should allow a completely transparent restart except for items, that don’t store status information in restart files.
axel.
That makes sense.
I suppose what would be helpful is to set the start time to something
other than zero. I'm doing dynamic simulations and when restarting a
previous run, I'd like to set the time to the time at which my restart
file was written. That way both the step and time continue on from
where they left off. If the time isn't being written to the restart
file, then perhaps there is a command that I could run to set the time
to some arbitrary value, and use that command to get the time to match
with the time at the end of the previous run.
Currently, when I concatenate the thermo output or fix ave/time output
files from restarted runs with the first, the time jumps back to zero
at those restart points and I have to add the last good time value to
the appended output. You can imagine that if there are multiple
restarts then I have to do this multiple times to get a
monotonically-increasing time column.
Really this is just to facilitate plotting and I have a method that
works, I'd just like to not have to go back in an adjust time
after-the-fact. Hopefully that's all clear.
- Jesse
That makes sense.
I suppose what would be helpful is to set the start time to something
other than zero. I’m doing dynamic simulations and when restarting a
previous run, I’d like to set the time to the time at which my restart
file was written. That way both the step and time continue on from
where they left off. If the time isn’t being written to the restart
file, then perhaps there is a command that I could run to set the time
to some arbitrary value, and use that command to get the time to match
with the time at the end of the previous run.
you failed to explain what “time” you are talking about. i don’t understand your problem.
the time step number is what documents the progress of the simulation and that is being saved and restarted. otherwise you are not restarting properly.
best you provide a minimal working example (or rather two files, one creating a restart and the other continuing from a restart, e.g. based on the “melt” example) and a commented output where you show what “time” is being reset in an unwanted fashion.
axel.
If your time step size does not change, it is a lot more convenient to just use the time step as “time axis” and just multiply it by your time step size when plotting. That is probably the least error-prone. Anything else is contrived and will just add noise to your input files.
Axel, the “time” Jesse means relates to the time that is output by thermo (e.g., by a thermo_style custom time). Here is an input deck that I think shows the “issue”; if you run in.melt, time runs from 0 to 1.25, step from 0 to 250 and a restart file called melt.restart is created. If you load that up with the script in.melt.restart, another run is performed where the time reported by thermo again goes from 0 to 1.25 while step goes from 250 to 500.
I suppose a command could be added to directly change the time value, similar to reset_timestep, but to me it feels like solving a borderline non-existent problem.
in.melt (725 Bytes)
in.melt.restart (285 Bytes)
Yes, sorry, time as in the thermo keyword time. And I'm using a
variable time step (fix dt/reset), so I can't easily map step to time
or vice versa. Like I said, this is really more of a plotting issue as
I'm interested in the time evolution of my system, not the evolution
based on number of steps.
Not a big deal though. I was just wondering if there was some existing
command I could use to tweak the simulation time. I doubt it would be
worth adding a new command just for this.
- Jesse