Repository navigation
Fast ensemble check - #669
Merged
Merged
Conversation
Enables the use of this with path reversal or 2-way shooting.
Member
Author
|
This is ready for review. I couldn't do a performance analysis because #660 prevents me from running simulations locally, but this should speed up the sampling (especially for toy models). This faster check only comes into play when an ensemble overrides the implementation of |
jhprinz
approved these changes
Mar 13, 2017
jhprinz
left a comment
Contributor
There was a problem hiding this comment.
Looks good. I like the approach. Although carrying the additional argument is extra effort.
7 tasks done
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This adds a new argument to
Ensemble.__call__, calledcandidate. Ifcandidate is True, then shortcuts can be used to calculate whether the trajectory is in the ensemble. The assumption is that this is a "candidate trajectory," as described in path ensemble theory; i.e., a trajectory that could have been generated by shooting.For example, this will allow us to assume that all frames except first and last are not in any state for a (flexible length) TPS ensemble or a TIS ensemble. For ensembles where there is no shortcut to be had,
candidatejust has no effect.This is the first step toward using the generalized CVs of #662 in analysis (simply need to replace the
TISEnsemble's use of max(orderparameter(trajectory)) by a CV that stores that result). That will be a huge improvement on analysis speed. If the max lambda is known, a TIScandidatetrajectory can be checked by looking at the first frame, the last frame, and the max lambda. Currently, we loop over all frames, find the max lambda, and check that only the first and last are actually in the state. This will also make a big difference for sampling speed for toy models.Note that we'll still have the occasional
sanity_checkduring simulation, which will not use the candidate assumption. This is just to make sure that nothing goes terribly awry during the sampling.This
candidateapproach is very similar to what we already had astrustedforcan_appendandcan_prepend. Unfortunately, there appear to be a couple cases where the__call__withtrusted=Trueis being already being used in a way that would conflict with replacing__call__'strustedwith what I'm doing withcandidate, so it looks likecandidatemight be separate fromtrusted(Annoying, because they're almost the same, and__call__withtrusted=Truealmost never happens. When it does, it is deep inSequentialEnsemble, so there might be a way to fix it, but it'll take some thought.)candidateflag toEnsemble.__call__TISEnsembleusingcandidateTISEnsembleusingcandidate(including where candidate is too trusting)candidatein replica exchange checks, path reversal checks