Correlation function TPS - #796

Isn't this used in the calculation of rate constants, where a reversible work calculation is used to compute the free energy of confining one endstate to state B through a series of intermediate staged calculations?

My understanding of this (see Section II.B) is that the ensemble must start in A but ends in B[i], where i denotes the intermediate number such that the final intermediate is B[N] = B, the initial intermediate B[0] is all configuration space, and the intermediates all overlap with their neighbors to a significant degree. (This is the path ensemble version of a staged alchemical free energy calculation.) This series of intermediates and endpoints would indeed be a great choice to design a TransitionNetwork from so that you could do this via replica exchange or expanded ensemble among path ensembles.

I have never heard of a fixed-length path ensemble where the trajectory starts in A, must pass through B, but need not end in B. Where did you get that concept from?

If indeed you're looking to name a network associated with the linked paper, I'd suggest something like StagedTPSRateCalculation (because it is used in TPS rate computations) or StagedStateCorrelationFunctionCalculation (because it actually computes a fixed-time correlation function for originating from some state).

I have never heard of a fixed-length path ensemble where the trajectory starts in A, must pass through B, but need not end in B. Where did you get that concept from?

1. From the reviewers, who both used almost exactly those words to describe this ensemble when they pointed to the linked paper.
2. From the paper, Sec. II C, Eq. (20), described as "the ensemble of all initial conditions $x_0$ in $A$ leading to trajectories visiting $B$ in the interval $[0, T]$." Reframe this as trajectories, instead of the initial conditions that lead to the trajectories, and you get exactly what you said. The $H_B$ term (note capital $H$), is the max of the normal lower-case $h_B$ over all frames in the trajectory (Eq. (17)), so it allows any frame to be in $B$ (as long as at least one frame is).

We shouldn't end the network name in Calculation, because it isn't the calculation; just the network to do the sampling. The calculation would be in the analysis after the sampling. And is Staged really correct in this case? I think of Staged as appropriate for the way you described it, sampling multiple ensembles. But that doesn't describe this ensemble. StateCorrelationFunctionTPSNetwork? A bit long; maybe StateCFTPSNetwork?

About the rate calculation: The original TPS approach was to construct and staged (umbrella-type) sampling in which B[i] was slowly changing. This would be sufficient for computing the rate, but requires long paths, to capture all possible transition (barrier crossing) path lengths. In this paper it was useful to split the calculation into an staged umbrella sampling with shorter paths, and a flux calculation with longer paths. This later flux calculation needed to have the H_B function, that allowed leaving the state B, to avoid spurious jumps at the end of the path, and hence a wrong flux estimate. In my opinion, this approach has been made obsolete by the flexible path length approach and the development of TIS. However, if people really want this, we can easily include it in OPS, not?

I agree with @dwhswenson that the naming should be consistent. The network is part of the FixedLengthTPSNetwork family, and thus should be called something like CaptitalHBFixedLengthTPSNetwork or VisitingBFixedLengthTPSNetwork or AnyFrameInBFixedLengthTPSNetwork or PartInBFixedLengthTPSNetwork or something similar.

In my opinion, this approach has been made obsolete by the flexible path length approach and the development of TIS. However, if people really want this, we can easily include it in OPS, not?

I fully agree. My main reason to add this is that I think that adding the network to OPS is the easiest way to answer reviewer questions about it (and with two reviewers mentioning it, it is probably worth adding). I don't want to add the associated analysis, in part because I think TIS is a better approach anyway.

The network is part of the FixedLengthTPSNetwork family, and thus should be called something like CaptitalHBFixedLengthTPSNetwork or VisitingBFixedLengthTPSNetwork or AnyFrameInBFixedLengthTPSNetwork or PartInBFixedLengthTPSNetwork or something similar.

These get a bit long..... paths.PartInBFixedLengthTPSNetwork is, I think, as long as we should go. That's already 35 characters, which is a lot on an 80-character terminal. I guess the main question is if that name would mean enough for users -- it describes the ensemble involved, but nothing about the use case. (On the other hand, I guess we don't want to encourage non-experts to use this, since TIS is probably a better choice.)

This is ready for review. Name is PartInBFixedLengthTPS, and I think the docstrings are sufficiently clear.