retis not restarting from preset trajectory number

[gyorgy-hantal]

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)

[sroet]

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 RandomStringFilenames for OPS 2.0?

[gyorgy-hantal]

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]

However, for RETIS I needed to modify this: num_steps = len(storage.steps)

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.

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)?

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]

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)?

This seems like a side effect of: #933 , specifically this changed line.

EDIT: Of course @dwhswenson beat me to the answer 😄

[gyorgy-hantal]

Ah I see, probably that's related to the version indeed!
Thanks for clarifying.

[sroet]

The easiest thing here is probably going to be to just manually figure out what the last step number used was.

For a slightly more rubust solution (in my opinion) you could have a look at the proposed restart_at_step code 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