Repository navigation
Single replica multiple interface set minus move #331
Description
Activity
Great issue. The first thought that I have is that when the minus move works for the normal MSTIS, single replica version, we should use that.
A more advanced version can then be developed for multiple interface sets.My next solution would be to extend until all interfaces are satisfied, and then choose arbitrarily between the interfaces. This might be less efficient, but it does obey detailed balance and has 100% acceptance.
Agree?Your other ideas work too, but might be more difficult to implement.
The first thought that I have is that when the minus move works for the normal MSTIS, single replica version, we should use that.
Definitely. See #350.
My next solution would be to extend until all interfaces are satisfied, and then choose arbitrarily between the interfaces. This might be less efficient, but it does obey detailed balance and has 100% acceptance.
If I understand correctly, I don't think this satisfies detailed balance. Say we have 3 innermost interfaces, A, B, and C. We'll write the order of that the interfaces are crossed as a string of these letters, so AABC means "crossed A, re-entered state, crossed A again, re-entered, crossed B, re-entered, crossed C" -- whether you need to re-enter the state to switch letters is another question; for now let's say yes since you always can re-enter the state before crossing different interface.
We start in interface A. Suppose the extension to the ensemble you propose gives us AABAC: that's a path satisfying that ensemble. Suppose we chose the segment crossing C (possible by any approach to selecting one of the these segments). The reverse trajectory from here would only give us the last BAC part from the forward extension, making it impossible to return to the original trajectory, which was that first A in AABAC.
(As an aside, that ensemble is actually really interesting in the context of the ensemble code we've created. We have a
SequentialEnsembleto say "we want these events, in this order," but we don't have an ensemble for "we want these events, in any order." We would have to create it by enumerating all the possible orders -- not impossible, but not very efficient.)In the long run, I think the hybrid approach (one interface set close to the state, branching to multiple interface sets later) is going to be the best multiple-interface-set approach. There are so many problems with the multiple interface set minus move. (In addition to these issues with single replica, it also isn't easy to use it to determine the flux.)
The more I think about it, the more it seems that combining the multiple interface set minus move and single replica TIS is not so trivial as I’d hoped.
I think I have a couple possible solutions, so here’s the long description.
Keep in mind the things a good minus move should do:
Two ideas that fail
When there’s only one interface set, the single replica minus move just amounts to extending until we have a new interface crossing, and then only keeping the new excursion as the trajectory in the innermost interface. Very simple, satisfies detailed balance, and near 100% acceptance.
How might we adapt this for multiple interface sets (multiple innermost interfaces)? I see two obvious possibilities, but neither works:
SingleReplicaMinusMover: in the event of only 1 innermost interface, you do get 100% acceptance, and it satisfies detailed balance. It just isn't optimal for MISTIS setups.)Two ideas that work
Keeping the minus interface as an extra replica (as with a replica reservoir)
This requires initially creating many replicas in the minus ensemble, selecting one at random, and doing a normal multiple interface set minus move with it. Of course, this gets the 100% acceptance rate of the MISTIS move, and because it maintains the same number of trajectories in the reservoir, you have detailed balance.
The only downside is that you have to create the initial reservoir. However, you typically need to run MD in order to define your states (and even if we define states adaptively with MSMs, the initial trajectories will include several examples of minus trajectories). The number of trajectories in the reservoir is a parameter to experiment with: we could use as few as 1, although I think the decorrelation would be faster with more.
(And yes, we could use this replica reservoir idea in the regular TIS too… probably wouldn’t even be that hard to add in OPS.)
Splitting the minus move and really using the minus segment ensemble
Another approach would be to effectively split up the minus mover into a replica exchange between the innermost interface and what we now call the minus segment ensemble, and allow the replica segment ensemble to either replica exchange or to generate a new segment (in the minus segment ensemble) using an extension like the single replica minus move. Then it could replica exchange into another interface set later.
This doesn’t require the replica reservoir, but I am concerned that it would lead to multiple extensions in a row. That can be adjusted by changing the relative probability for the minus segment to try an exchange with an innermost ensemble or to try the extension.
I’m not sure which approach is better. Neither has been tried before. I might implement both, and then we can test them out later. Posting the issue to look for feedback on this -- any other ideas?