retis not restarting from preset trajectory number #1107
Description
Hello,
I am trying to restart a retis calculation from the last step by setting also the trajectory number the engine should use. I am trying this with a script that worked well with the nc database file, but somehow fails to get the right trajectory number now. The job starts alright but instead of numbering the saved trajectories from the requested number the counting starts at 1 (and it overwrites the old files). I am using gromacs as engine.
I copy my script below.
Thanks a lot in advance!!
Gyorgy
import openpathsampling as paths
from openpathsampling.experimental.storage import monkey_patch_all
from openpathsampling.experimental.storage import Storage
paths = monkey_patch_all(paths)
paths.InterfaceSet.simstore = True
os.environ["HDF5_USE_FILE_LOCKING"] = "FALSE"
tag = "retis1"
storage = Storage(tag+".db", mode='a')
engine = storage.engines[0]
engine._traj_num = 76
retis_calc = storage.pathsimulators[0]
retis_calc.restart_at_step(storage.steps[-1])
retis_calc.run(50000)
Activity
sroet commentedon Mar 7, 2022
Hey, is this a copy of #1101 ?
If so, would the quick and dirty solution from this comment work for you, while we swap to
RandomStringFilenamesfor OPS 2.0?gyorgy-hantal commentedon Mar 7, 2022
Hey,
Thanks a lot, this indeed does solve my problem!
However, for RETIS I needed to modify this:
num_steps = len(storage.steps)
because repex and path reversal moves don't yield new trajectories therefore, I need to provide the sum of the number of minus and shooting moves only. But otherwise the solution works fine!
Out of curiosity: why setting the trajectory number like this 'engine._traj_num = ...' doesn't work anymore (which used to with the old nc database files)?
Thanks again.
gyorgy
dwhswenson commentedon Mar 7, 2022
The easiest thing here is probably going to be to just manually figure out what the last step number used was. In fact, it doesn't matter whether the trajectory numbers are actually sequential (which is why we switched to random strings); it does matter that they don't repeat. So if the highest from the previous run was 76, and you restart from 100 (or 1000), everything should be fine.
Are you sure this is filetype-related and not OPS version? In #933 we made some major changes to internal structure of the Gromacs engine. That moved the internal location where we track the trajectory number (
_traj_num) out of the engine itself and into a separate modular object which sets the filename. The idea is that if you use the random string filenames instead of sequential numbers, there's no concept of a "number" to track. That change is definitely part of the difference that you're seeing. There may be also be something specific for nc files, but I don't immediately know what that would be.sroet commentedon Mar 7, 2022
This seems like a side effect of: #933 , specifically this changed line.
EDIT: Of course @dwhswenson beat me to the answer 😄
gyorgy-hantal commentedon Mar 7, 2022
Ah I see, probably that's related to the version indeed!
Thanks for clarifying.
sroet commentedon Mar 7, 2022
For a slightly more rubust solution (in my opinion) you could have a look at the proposed
restart_at_stepcode here (part of #1105 )I will close this as a duplicate of #1101 to keep our issue tracker clean. Feel free to reopen if you don't agree with this