Daniel Russel wrote: > We had discussed but never implemented some mechanism for having shared > state (such as non-bonded lists). It seems to me the right way to do it > is to have a class State (or some better name) which has a single > virtual method "void update()" which is called in Model::evaluate before > the restraints are evaluated. As with Particle, Restraint it stores a > ModelData pointer and Model would have add_state and get_state methods.
Well, I think we need to discuss this further, so let's drag in others here:
I agree that a shared state class is needed, and could be used by nonbonded lists. But what do you need it for right now, i.e. what else would people use it for?
Calling State::update() in Model::evaluate() would not be sufficient, at least for nonbonded lists, because you can also call Restraint::evaluate() on individual restraints from the Python interface.
How would a nonbonded list know that it needs to do an update? I don't like the Statistics class proposed in ModelData.h. (The idea of that class is to automatically keep min/max/change statistics on all float variables.) Why: because 1. if you don't want nonbonded lists, maintaining these statistics is inefficient, and 2. because it's part of the ModelData class, it can't easily be extended by other classes. Two suggestions: 1. Classes can register callbacks/actions with ModelData::set_float, or this could trigger a State::set_float method, to be notified whenever the model is changed. The advantage of the former is that the callback can go away after a nonbond update is triggered, saving the overhead of a function call for subsequent set_float()s. 2. Classes to allow the get/set of the 'optimizable state' (right now, this is just all optimizable floats) could have similar methods, useful for optimizers such as CG and steepest descent which change all attributes simultaneously.
Ben