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.
Keren Lasker wrote: > 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 don't think this is quite true. The restraints that Bret has coded do all of their setup at construction time, but there's no reason that I can see why you couldn't do some of the particle selection at evaluation time - it's just less efficient.
> 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.
I agree that we need some more sensible way of constructing the system optimization state than simply iterating over all optimizable Floats. For example, rigid bodies, pseudoatoms (e.g. mass centers), or even restraints between particle groups (residues, chains) would need to use either derived properties (e.g. positions of centers of mass) or otherwise have pre/post optimization methods which populate these properties from the atomic particles and then map forces on mass centers, etc. back to forces on particles.
> 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
I'd be interested to hear more of your thoughts in this direction. I think I'm going to disagree with you, but I'm not sure yet. ;)
> 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.
Absolutely!
Ben
participants (2)
-
Ben Webb -
Keren Lasker