OPSPiggybacker is a tool to assist importing other simulation records into OpenPathSampling for analysis. Because of the extensive metadata that OPS tracks for each move, this isn’t completely trivial. The idea of OPSPiggybacker is to request a reasonable set of inputs that a user of another path sampling simulation tool can give, and then create from that a file that can use most of OPS’s standard analysis tools.
The current version, 0.1, only aims to cover one-way shooting moves in a single ensemble, as with TPS simulations. See the roadmap for future plans.
Since this combines OPS and some other sampler, you’ll need a little
familiarity with both. From the OPS side, you’ll need to set up an OPS
TransitionNetwork object that represents the simulation you’ll be
reading in. (For now, this only supports
TPSNetwork (and possibly
FixedLengthTPSNetwork, although I haven’t tested that.) This includes
creating collective variables and volumes as always done in OPS.
You’ll also need to prepare you previous simulation in an input format that can be read by OPSPiggybacker. Currently, we only support TPS simulations with one-way shooting. Even within that, there are several options.
- create a one-way shooting summary file
- use the API with one-way (partial) trajectory input
- use the API with full trajectory input
In general, the summary file is probably the easiest approach for users to implement. The two approaches that directly use the API are
What OPSPiggybacker does¶
The overall approach is very similar to the setup of an OPS simulation. You use the standard OPS volume, collective variable, network, and ensemble objects. The only things that change are the move scheme/path movers, and the simulation object.
Instead of an OPS move scheme or OPS path movers, you build what we call a
mover stub. Currently, the
ShootingStub is the only mover stub
ShootingStub is analogous to an
OneWayShootingMover in OpenPathSampling. It is initialized with an
UniformSelector is currently
supported) and optionally an
Once you’ve defined the mover stub, you create a pseudo-simulator.
Currently, the only supported pseudo-simulator is the
ShootingPseudoSimulator. The pseudo-simulator plays the same role
PathSampling object in OpenPathSampling. It is initialized with a
storage, a set of
initial_conditions (in the form of an
network, and a mover stub called
mover, which takes the place of the move scheme used in OPS.
Once this is done, you simply use the
run method of the
ShootingPseudoSimulator to generate your file. However, whereas
the run method of the
PathSampling object in OPS takes an integer with a
number of steps, in OPSPiggybacker, you must provide the output of your
previous simulation to the run method of the pseudo-simulator. The following
subsection will describe the moves.
Partial input trajectories¶
Full input trajectories¶
One of the input options for shooting moves is to use full input
pre_joined=True). In this case, the input trajectory must
be an OPS format trajectory for the full trial trajectory. In addition,
the frames which are shared with other trajectories must be identical in
memory frames. Since this is quite hard to do, it is usually easier to use
pre_joined=False version with partial input trajectories.
However, we full input trajectories, you don’t need to specify whether a given trial was forward or backward: the OPSPiggybacker can figure that out for you.
This is in
the format of a list of 4-tuples
shooting_point_index, accepted), where each 4-tuple represents a trial
move. In detail, the elements of the tuple are:
replica: the replica ID. Currently always the same (usually 0).
trial_trajectory: the generated trial trajectory, as an
openpathsampling.engine.Trajectoryobject. Note that there are two tricky things here. First, this must be the entire trial trajectory (not just the part generated during one-way shooting). Second, frames which are shared between two trajectories much actually be the same object in memory. This means that you have to rebuild the shooting process for your trajectories. (TODO: find ways to make this part easier on people)
shooting_point_index: the frame number of the shooting point from the previous trajectory (counting from 0).
accepted: boolean as to whether this trial move was accepted.
That’s it! If you can make that tuple for each of your moves, you can import those moves into OPS for analysis.