I am running a script that primarily consists of change_box and minimize commands (no run commands). I also periodically use write_dump.
When the number of timesteps exceeds the value corresponding to the largest 32-bit integer, the subsequent write_dump fails with a message like so:
ERROR: Invalid dump frequency 2160577564 (src/src/output.cpp:747)
This results in the simulation ending unexpectedly. Would it be possible to use 64-bit integers for this, just like what is used for actual timesteps?
Not really. To understand you have to know that “write_dump” is actually a bit of a shortcut for a regular “dump/dump_modify” set of commands followed by something similar to a “run 0” command, only that it only triggers output. In the past, the dump frequency would have been just set to “1”, but that could trigger “fix not computed at compatible times” errors. This is where the idea of using MAX(timestep, 1) came from, and it works for as long at the timestep number is a 32-bit signed integer.
After some experimenting, it seems, that one can also use the number of steps used in the “run” command (which is a 32-bit signed integer) for the same purpose and avoid the error with fixes (e.g. fix ave/atom) as well. You can try out the change shown here: Collected small changes and fixes by akohlmey · Pull Request #4094 · lammps/lammps · GitHub
I see… I understand. Thanks for the quick fix!
For now, I’m circumventing the issue by using reset_timestep with an incrementing integer, every time I write_dump.