Repository navigation
Reweighted path ensemble #307
Description
Activity
I have no idea what you're trying to calculate here. First, what are you referring to as the "total path ensemble"? To my knowledge (and Google's), that expression has only been used to refer to what might also be called the "natural path ensemble": the ensemble of trajectories with their natural weights (i.e., if we didn't put the interface-based restriction on them). We calculate that using the reweighted path ensemble (RWPE), which we haven't implemented in our analysis routines yet. But this is _not_ a property of a single
Transition! This is the final output from the entire analysis!In general, my suggestion for analysis is to use different objects wherever possible. Otherwise, we'll end up with hundreds of functions for each object, making it very hard for users to learn how to use it. So
rwpe = ReweightedPathEnsemble(network)(which may calculate the RWPE or, more likely, just sets it up so that it is ready to calculate in a second step). Then maybe you'd have a specialized method in that object to calculate correlations based on the weights from the RWPE. This is much more manageable in the long run thannetwork.reweighted_path_ensemble().Is RWPE a target for 1.0? I thought we had decided not.
I just noticed that the original paper does abbreviate it as RPE, not RWPE. I don't know where I got the idea that the standard abbreviation included a W.
On the (semantic) distinction between TPE (or NPE as I've sometimes called it, or UPE [unbiased] in the paper John linked) and RPE: The RPE is a method and the result of that method. The TPE is more of a platonic ideal that could be calculated in other ways. With a simple system you could run a really long trajectory and mask out the frames that are in the states.(*) Save the segments as separate trajectories, and you have the TPE, but not obtained via RPE.
Obviously, this isn't practical for real systems. The RPE is our tool to calculate the TPE, so in common use, the terms are interchangeable. With regards to the original post, my points of confusion were: (1) why associate the RPE/TPE with a transition, not the entire network? (2) why would the RPE/TPE be a method that takes CVs as parameters and returns correlations (instead of an object that includes such a method)? (3) What exactly are the correlations being calculated? In principle you could calculate any correlation function, but it isn't clear to me what the purpose is.
(*) Actually, mask out frames in the states except the first one next to entrance/exit, in order to get the exact same trajectories we get with TIS.
Thanks for the thoughtful clarification!
(1) Associating the RPE/TPE with a network sounds reasonable.
(2) An RPE/TEP object that can calculate correlation functions or transition probabilities does sound more useful.
(3) I think we're particularly interested in computing transition probabilities
$T_{ij}(\tau)$ for building MSMs, but other correlation functions may also be of interest.Sorry for the sloppiness. I did not really think about all the distinctions. I was only referring to reweighted set of all sampled paths which is the RWPE. I was also thinking that we might have a Transition-based version. So take all paths appearing in a single transition and reweight these. These will still allow to compute certain conditional properties. No idea you would call that. If you combine and reweight all of these single transition based ensembles you would reach the RWPE.
The goal was indeed to use the RWPE to compute other dynamical properties from it, like transition probabilities for a MSM as John pointed out.
- changed the title
[-]Access to Total Path Ensemble (TPE)[/-][+]Reweighted path ensemble[/+]on Feb 12, 2021 The current status on this is that necessary things for the RPE were been exposed in #825. We just need someone to think through the RPE paper to link the quantities, and to write the code and tests. Marking this as a good first issue.
This will be a set of functions for the
Transitionclass. It should allow to retrieve correlations from the total path ensemble. Like thisCould either return a list of values or a function that will compute correlations given tau (and could cache these). Even better if we could allow lists of cvs. Then the following would work
and we can just get state_to_state correlation matrices with a single command. You should even be able to combine results from other transitions, since the trajectories are disjoint.