> 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.