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