Repository navigation
Add callbacks option to PathSampling #765
Description
I have thought (a long) while about how to best implement the on the fly shooting range optimization and I think I finally came to a result that may be worth your time :)
The idea is to add an optional callbacks argument to the PathSampling, which is expected to be a list of PathSamplingCallback (callable objects with an interval attribute), which would then be called by the PathSampling, with the PathSampling as argument, every interval steps. This way one can call custom code every interval PathSampling steps. This enables advanced users to write their own code to select shooting points based on the information from all previous shooting attempts and thereby iteratively improving the efficiency of their simulation.
I already went ahead and wrote a preliminary implementation which defines a PathSamplingCallback abstract baseclass and added the necessary code to the PathSampling at https://github.com/hejung/openpathsampling/tree/pathsamp_callback.
See also the rewritten ShootingRangeOptimizer initially developed at Leiden and now using the callbacks option to be more flexible and lightweight at the same time (https://gitlab.e-cam2020.eu:10443/hejung/sr_shooter/tree/refactor_callback).
Please let me know if this is something that could be accepted into OPS sometime in the future.
Activity
dwhswenson commentedon Apr 10, 2018
What you're proposing here is very similar to something that's already in development. I was using the term "hook" to describe it, thinking of several places in during the process of a simulation step that you might want to add behavior. In addition to use cases like yours, the same approach could be used for things like on-the-fly analysis, or to make some output optional (for example, step number becomes less meaningful when running in parallel). In fact, even storing to a file can be thought of as a "hook" that we add, which can be re-used between different types of simulations. (As you said, this whole approach makes the code both more flexible and more lightweight.)
In other words, I think it is a good idea, and I already started working on it!
The first draft of that is in #755. I think the best approach would be for you to look over that, and see if the structure of hooks implemented there will give you enough flexibility for the
ShootingRangeOptimizer-- if not, let me know how to improve it!In particular, you'll want to look at:
hooks.pyshoot_snapshots.py, especially the.runmethodpath_simulator.py, methods related to hooks(Note also that this is all after the refactor of path simulators into multiple files; #754. I would suggest that any work on simulator objects should be based after that change.)
Current status: So far, I've added hooks for "shoot-from-snapshot" (i.e., committor and related) simulations. That's still being tested, and will be followed by some work parallelizing the committor simulation (handling these hooks while parallelizing takes some careful attention). That work is not yet in a PR, but you can see it in the
dask_committorbranch of my fork, which is still extremely experimental (the filetask_schedulers.pyis the main one to look at; we're planning to usedask.distributedto handle the parallelization; I would recommend YouTube videos of talks about dask by Matt Rocklin and/or Jim Crist as a great way to get introduced to how dask works).I haven't added support for hooks to
PathSamplingobjects, but that is coming (if you want to work on it, feel free, just add lots of tests along the way, and make sure that the default behavior is exactly like it used to be. This change will be part of the 1.x series.)I don't know enough about the shooting range optimization algorithm to know whether the trajectories you launch can be run in parallel or not; if so, you'll need to pay attention to ensuring the task graph has the right dependencies. (That's the tricky part with this parallelization approach.)
But overall, yes, an approach similar to this is exactly what I was planning for the near future.
hejung commentedon Apr 11, 2018
Great to hear that!
From a first glimpse it looks like the hooks can do everything I need (and probably more).
I will start working on adding them to the
PathSamplingand see how it goes.Should I close this Issue and ask everything else that comes up in #755?
hejung commentedon Jul 20, 2021
Closing this now, the hooks for
PathSamplingare in the main branch and also in v1.5. @dwhswenson Feel free to let me know/reopen if you think we should not close it yet.