Transitions and Networks

Different path sampling approaches use different kinds of ensembles. But what they all share in common is that those ensembles represent some network of transitions.

Under most circumstances, the user can directly work with TransitionNetworks, and never needs to work directly with Ensembles. This document describes the internal structure of TransitionsNetworks, and explains how to customize that structure with different ensembles if so desired.

This also covers some of the interface between TransitionNetworks and MoveStrategy objects. When developing new methodologies, this interface allows for high levels of flexibility. A new TransitionNetwork could be combined with a customized MoveStrategy to develop all sorts of path-sampling-like approaches.

Networks are made of Transitions

A transition describes a set of paths with certain allowed initial and final conditions. There are two groups of transitions that are important when working with networks. First, there are the sampling_transitions, which are what are actually sampled by the dynamics. Then there are analysis_transitions (or just transitions) which are the subjects of analysis.

The difference between these is easily described in the context of MSTIS. With MSTIS, you use one set of ensembles to sample the transitions from a given state to all other states. So you would sample \(A\to (B \text{ or } C)\), but the analysis transitions would include separate studies of \(A\to B\) and \(A\to C\).

The network is defined by the combination of what the underlying transitions to study are, and the approach used to study them. It defines a set of path ensembles which are sampled during the dynamics, and the way to combine those afterward into results that connect to physical meaning.

Handcrafting Networks

Beyond the simple tools to customize the networks you study, you can manually create them with whatever complexity you desire. The Network level of code is designed to interact with the MoveScheme and MoveStrategy code, as well as with some of the analysis tools. As long as you implement a few items, your custom Network will work seamlessly with those.

The main point is that there are two aspects of the network: there’s the sampling network, which is organizes the ensembles as used in sampling, and the analysis network, which actually consists of the specific transitions you’re interested in studying.

Handcrafting the sampling network

The sampling network consists of three objects:

  • network._sampling_transitions: a list of transitions; contains all the normal ensembles (accessible as network.sampling_transitions)
  • network.special_ensembles: a dictionary with strings for keys, describing the type of ensemble, and dictionaries for values. Those value dictionaries have the ensembles themselves as keys, and a list of associated transitions as values.
  • network.hidden_ensembles: this list is empty when built by the network, and is set by the MoveScheme if necessary. This consists of ensembles that aren’t part of the network, but are part of the move scheme.

The special ensembles need to have the correct key names to work with the MoveScheme and MoveStrategy subsystem. These are 'minus' for the minus interfaces, and 'ms_outer' for the multiple state outer interfaces.

If you do that, then MoveStrategy and MoveScheme will work with your networks.

Handcrafting the analysis network

The analysis network is determined by the list of all state pairs that represent the transitions you’re studying. It is contained in the network.transitions dictionary, which has keys of tuples in the form (stateA, stateB) with values of the Transition object that describes the \(A\to B\) transition. During analysis calculations, you will often perform the analysis on the sampling network, but copy the results of that analysis to the transition network using analysis_transition.copy_analysis_from(sampling_transition). For example, in MSTIS, you only run one crossing probability analysis per state (per sampling transition), but this is used to link to all the specific state-to-state transitions in the analysis network.

Examples of Networks and Transitions

Two-state network

It is perhaps easiest to understand the idea of networks and transitions if we visualize them for the case of transition interface sampling. Let’s take one of the commonly-used illustrations of TIS as a starting point:

../_images/two_state_tis.png

Here we see two transitions: \(A\to B\) and \(B\to A\). In this simple example, there is no distinction between sampling transitions and analysis transitions. Each transition consists of several ensembles. The ensembles define the paths that will actually be sampled during the path sampling simulation. The transitions provide a context for analyzing those results: in TIS, we combine results from sampling multiple ensembles in a specific way in order to determine rates. The Transition object keeps the information on how to combine information from its various ensembles.

In practice, this network can be created as either an MSTISNetwork or a MISTISNetwork:

# mstis version
mstis = paths.MSTISNetwork([
    (stateA, interfacesAB, orderparameterAB),
    (stateB, interfacesBA, orderparameterBA)
])

# mistis version
mistis = paths.MISTISNetwork([
    (stateA, interfacesAB, orderparameterAB, stateB),
    (stateB, interfacesBA, orderparameterBA, stateA)
])

Both of these would give the same behavior.

Note that there are other approaches that could give different networks. By default, both MSTISNetwork and MISTISNetwork create a “multiple state outer interface,” which links the two transitions. Whether this interface is actually used depends on the MoveScheme: however, another network type might not even make it. Similarly, the transitions in both of these create a MinusInterfaceEnsemble, which could be removed.

For simplicity, we recommend that users who wish to avoid making use of these ensembles adjust the MoveStrategy and MoveScheme to manage that, rather than creating a new TransitionNetwork.

Three-state networks

Now let’s consider a 3-state system. In the image below, we illustrate the sampling network for an MSTISNetwork for a 3-state system.

../_images/three_state_tis.png

In this example, there are 3 sampling transitions:

  • from state A, through the interfaces associated with A, and to either state B or state C
  • from state B, through the interfaces associated with B, and to either state A or state C
  • from state C, through the interfaces associated with C, and to either state A or state B

However, there are 6 analysis transitions: \(A\to B\), \(A\to C\), \(B\to A\), \(B\to C\), \(C\to A\), and \(C\to B\). Each sampling transition samples for two analysis transitions.

When you want a rate, you want the rate for the analysis transition. For example, you would typically want a rate for the \(A\to B\) process, not the \(A\to (B \text{ or } C)\) process, which is what the sampling transition would give you. However, the sampling transitions can be much more efficient to sampling: the number of analysis transitions scales as the square of the number of states, while, in MSTIS, the number of sampling transitions scales linearly with (actually, is equal to) the number of states.

MISTISNetworks, on the other hand, have a sampling transition for each analysis transition. This can give the advantage of allowing a better order parameter to be used as an approximation to very different reaction coordinates coming from the same state. It also allows you to focus on only a subset of the \(N^2\) possible transitions.

By distinguishing between sampling transitions and analysis transitions, OpenPathSampling makes it easy to allow this kind of flexibility in the underlying sampling style, while still making it very easy to set up a given kind of network with minimal code.