-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Continuing a Path Sampling Simulation with GROMACS #1101
Comments
Thanks for raising this issue! First, the quick and dirty solution:change your example code to
why this happensOPS stores things like the engine only once, mostly at the time of creation. Which means that it does not keep track of changing variables like these counters. After reloading; these counters restart at 0. possible OPS 1.x solutionsI don't know what the timeline from @dwhswenson is for a 2.0 release, so none of these fixes might be implemented
proposed OPS 2.0 solutionWe act on the comment in
and update the default on this line to @dwhswenson any thoughts on this? |
I think this is the best solution here. The best way for OPS 2.0 might be for simulation objects to implement a @jjfsteuer : As @sroet mentions in his suggestion for 2.0, 2.0 will default to using random filenames instead of sequential numbers. You can already use this functionality, and I would recommend it. It should solve the problem you're having. See #933 for details and some other reasons that it was originally implemented. Of course, this doesn't change the data you've already created, but for future data, it's easier. (Note to self -- not sure that the 2.0 branch actually has that default yet, but it should be possible to do.) |
It does not, hence my proposal for a deprecation warning + 2.0 update |
Thank you so much for the quick response! @sroet adjusting the filename_setter.count is a nice workaround and works great for me. @dwhswenson thanks for the #933 suggestion, I will update my code accordingly. I'm currently still trying out a lot of things, so the existing data is not that substantial. |
Hello, Two months ago I raised an issue (#1107, merged already with this one) with the same problem. Using the quick and dirty trick suggested by @sroet solved the problem of restarting from a given step.
Do you have an idea of what can go wrong? |
If I remember correctly, restoring a pathsimulator does not actually re-attach the storage object.
If that one is
before running the calculation |
It indeed resulted in
did solve the problem! Thank you! |
First of all a big thanks to the developers for the great software, documentation and continuous development.
I am currently trying to continue a TPS simulation using OPS with the GROMACS Engine.
My initial run consists of 100 steps, and to append to that simulation storage I use the following code:
While the OPS package appears to do what I expect
the executed GROMACS command does not adopt the corresponding index
gmx -nobackup mdrun -s topol.tpr -o ././prod_trr/0000001.trr -e ././prod_edr/0000001.edr -g ././prod_log/0000001.log
and the trajectory files from the initial run are overwritten.
I was able to reproduce the same problem for the alanine dipeptide example for GROMACS (trying to continue from the simulation in AD_tps_2a_run_flex.ipynb).
Again, the appending run appears to continue with the TPS where it is supposed to, but the GROMACS filenames are restarted at 0000001.
Any advice or suggestion what might be going wrong is greatly appreciated!
Best,
Jakob
The text was updated successfully, but these errors were encountered: