Proposal: GravityCenterScoreState
Keren and Frido want to be able to create restraints that act on spherical 'blobs' - which may correspond to protein domains or perhaps to some other defined group of atoms - while at the same time having restraints on the underlying atoms themselves. Thus, the positions of the blobs need to match the positions of the atoms. (In the Modeller or CHARMM worlds, this would be achieved with a gravity center pseudoatom).
Thus, a proposal: a GravityCenterScoreState, which would take a list of hierarchy particles and a boolean flag (to turn on/off mass weighting). It would provide a method set_positions() which would set xyz attributes for each hierarchy particle to match the gravity center of the child atoms. (These attributes would be marked as non-optimizable, of course, since they are derived.) It would also have a protected method transform_derivatives(), which would back-transform any forces on the gravity center to the children.
(Note that there are several other kinds of pseudo or virtual atom, such as the several Modeller uses for NMR. If there is interest in these we could of course come up with a suitable class hierarchy. For example, one extension would be to turn the hierarchy particle into a sphere, by also populating a radius attribute, e.g. from the radius of gyration of the children. But I think currently nobody uses anything but gravity centers anyway.)
This ScoreState would require a change to the API. ScoreState::update (called before the score is evaluated) would be renamed ScoreState::pre_update and a new ScoreState::post_update method would be added (called after the score is evaluated). Gravity centers would simply call set_positions() from pre_update() and transform_derivatives() from post_update(). Existing ScoreStates would provide a do-nothing implementation for post_update().
Comments?
Ben
> Thus, a proposal: a GravityCenterScoreState, which would take a list > of > hierarchy particles and a boolean flag (to turn on/off mass > weighting). > It would provide a method set_positions() which would set xyz > attributes > for each hierarchy particle to match the gravity center of the child > atoms. (These attributes would be marked as non-optimizable, of > course, > since they are derived.) It would also have a protected method > transform_derivatives(), which would back-transform any forces on the > gravity center to the children.
If the derived positions are not optimizable then some current restraints won't modify their derivatives. For example, the non-bonded list is using non-optimizable x,y,z to mean fixed particles, which get treated separately (since they don't need to move in the grid and collisions between them are not meaningful). I think some of the others may skip non-optimized particles too.
Simply letting the optimizers optimize them and then ignoring the result works, but is kind of inelegant (and inefficient if the branching factor is small). The fixed particle case may be enough of a special case anyway that we can just get rid of it. I can replicate the current behavior in my code by having several nonbonded lists and corresponding restraints-- the main change will be that it checks that the particles indeed didn't move.
So I think removing the checks from the other restraints and states looks like the right way to go.
> This ScoreState would require a change to the API. ScoreState::update > (called before the score is evaluated) would be renamed > ScoreState::pre_update and a new ScoreState::post_update method > would be > added (called after the score is evaluated). Gravity centers would > simply call set_positions() from pre_update() and > transform_derivatives() from post_update(). Existing ScoreStates would > provide a do-nothing implementation for post_update(). Perhaps we should call the methods before_evaluate and after_evaluate as they are called before and after the Model::evaluate work is done. pre_update is a bit strange as the states are the things doing the updating.
Otherwise sounds good.
Daniel Russel wrote: > If the derived positions are not optimizable then some current > restraints won't modify their derivatives. For example, the non-bonded > list is using non-optimizable x,y,z to mean fixed particles, which get > treated separately (since they don't need to move in the grid and > collisions between them are not meaningful). I think some of the > others may skip non-optimized particles too. > > Simply letting the optimizers optimize them and then ignoring the > result works, but is kind of inelegant (and inefficient if the > branching factor is small). The fixed particle case may be enough of a > special case anyway that we can just get rid of it. I can replicate > the current behavior in my code by having several nonbonded lists and > corresponding restraints-- the main change will be that it checks that > the particles indeed didn't move. > > So I think removing the checks from the other restraints and states > looks like the right way to go.
Sounds reasonable to me. Your patch to fix this is in r496.
>> This ScoreState would require a change to the API. ScoreState::update >> (called before the score is evaluated) would be renamed >> ScoreState::pre_update and a new ScoreState::post_update method >> would be added > Perhaps we should call the methods before_evaluate and after_evaluate > as they are called before and after the Model::evaluate work is done. > pre_update is a bit strange as the states are the things doing the > updating.
Agreed. I'll put this in later today.
Ben
participants (2)
-
Ben Webb -
Daniel Russel