Repository navigation
Math on CVs #293
Description
Activity
Good idea to make it easier to have complex CVs. I have started implementing possible non-storable CVs.
In addition what you can do right now is to define a new function in the following way
import openpathsampling.cv_math as cv phi = paths.CV_MD_Function(name="phiname", fcn=md.compute_dihedrals, indices=phi_atoms) psi = paths.CV_MD_Function(name="psiname", fcn=md.compute_dihedrals, indices=psi_atoms) op = paths.CV_Function(lambda x : math.sqrt((phi(x)-phiA)**2 + (psi(x)-psiA)**2)) # op.name == "sqrt((phiname - (-50))**2 + (psiname - (-15))**2)" # (or something like that)If you want real math (which would be pretty cool) we need to implement the basic operators for CVs (which should be simple) and agreed, the tricky part is adding other math functions like
sqrt,logetc... But I do not think that is too difficult.I really like that idea and might add it to the nonstorable CV.
One thing we need to figure out is how to not start saving a chain of cached "intermediate" order parameters. For EnsembleCombination, etc that is no problem, but here each little CV building block could have a cache that we could store. Perhaps it is easiest to default to not store caches, but only the CV logic and only if the use request it, save the cache of a CV.
We might even decouple the cache storage from the CV. Need to think about that a little more.
In addition what you can do right now is to define a new function in the following way
Ah, yes, that is a better implementation in the current version than my attempt. With the new fancy tricks for storing the function in a CV, a CV implemented that way will be fully restorable?
One thing we need to figure out is how to not start saving a chain of cached "intermediate" order parameters. For EnsembleCombination, etc that is no problem, but here each little CV building block could have a cache that we could store.
If I understand correctly, you mean that it would be nice to not use additional storage/caching for the
psiandphivalues, but only for the finalop? I would say both options are sometimes wanted. In this particular case, it's probably good to keep around calculations ofphiandpsi. But in other cases, those intermediates would be a waste.Perhaps it is easiest to default to not store caches, but only the CV logic and only if the use request it, save the cache of a CV.
I think a
use_cache=Truedefault on CVs might be the approach here. Make your CV withuse_cache=Falseto not use the caching (as with undesired intermediate CVs). Under most circumstances, I think the default is that the user does want the caching.Ahh.. wait, I think I see better. You're saying the tree of
CVCombinations leads to a bunch of unecessary junk, right?Any
CVCombinationchecks if its members areCVCombinations; if so, sets theuse_cacheflag to False. (Make it a little better:use_cacheflag is a property; forCVCombination,_use_cachedefaults toNone. When parent checks children, if explicitly set, leave as is. Ifchild._use_cache is None, set toFalse. On callingself.use_cache; returnTrueifself._use_cache is None(topmost combination will haveNone, all others will haveFalseunless explicitly set toTrue.)
Would it be possible/desirable to have the ability to create CVs from other CVs using standard math notation?
For example, consider the CV used by Weina on Ala-dipeptide -- the distance in Ramachandran space from some point.
First, here's stuff that is needed by any approach:
Right now, to implement that we need to do something like this:
(okay, I know mdtraj has shortcuts for Ramachandran angles, but this is copy-paste from closer to what we currently have)
I think it would be nice to instead define the same distance according to:
This would require adding magics for the standard math operators to CVs, and then special supported operations would go into
cv_math, which should be pretty easy to write -- the trickiest bit would be in creating the names correctly.It's enough work that I doubt it fits in 1.0 (at least, I don't have time to write it), but I think it would be pretty cool. Most of the tricks we need are rehashes of what we've done elsewhere (
CVCombinationclass analogous withEnsembleCombinationto handle binary operators; etc.)