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
--
http://salilab.org/~ben/
"It is a capital mistake to theorize before one has data."
- Sir Arthur Conan Doyle