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.