ok - my thought on the relationship between particles/restraints and
optimizers.
It might be that I am missing something since I used only I looked at
about half of the IMP classes - not all.
To my understating ( please correct me if I am wrong here) in the
current design:
1- attributes are used for two purposes to store the particles
information (x,y,z, radii, weight, .... ) and to manage the
optimization (is-opt)
and Model data has two responsibilities - hold the particles and
participate in the optimization process.
2 - The restraints holds a state (ie they know in construction time
what is the particle list that they are going to work on)
I think that we should divide the two.
Have ModelData which does not care at all about optimization, its
only responsibility is to maintain a valid set of particles.
We should have an additional class OpimizationData which holds all
optimization header data (is optimizable, should be included in the
scoring ). It can implement optimization logic nonbonded list , it
might be that we'll come up with other optimization logics as
well ... . So the Statistics class for example should be within the
OptimizationData class.
The restraints should be stateless - at each evaluation time they
will get the relevant attribute list and derivative list ( which
might be different from the attribute list) from the optimizationData
For example, for the nonbonded list case:
1 - ModelData holds all the particles.
2 - The user sets its attributes for optimization ( which sets the
OpimizationData class)
3 - At each optimization stage
a - the restraints are given a pointer to the OptimizationData
class - where all the header-optimization information about the
attributes and a reference to them is stored.
b - at the end of the optimization step the OptimizationData
class updates the header information in case some optimization
properties should be changed
4 - when adding or removing particles, the OptimizationData object
( there might be more than one - when dealing with hierarchy for
example - the OptimizationData objects are updated accordingly).
anyway , as I discussed earlier with Ben, I think that we can not
really have a serious discussion without having a few detailed use-
cases ( there are other than the non-bonded list one).
I will write a python unitest for fitting and docking of multiple
components, we should probably have another single protein
refinement one and maybe also ligand docking and then we can assess
solutions more realistically.