[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [IMP-dev] Proposal: GravityCenterScoreState



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.