I think we should move RestraintSet to the kernel as the other solution we effect running times. Also - I would not leave core::RestraintSet. It is better that we would suffer once with a change of interface vs. people using core::RestraintSet without knowing that it should not really work. On Jan 14, 2010, at 10:49 AM, Daniel Russel wrote:
> Currently RestraintSets are opaque to the kernel, meaning that the > kernel doesn't know anything about the restraints contained in them. > This was fine for a while, but recently has been causing problems > - Model::evaluate(restraints) called with restraints from a > restraint set fails because the Model doesn't know about the > dependencies of the restraint. > - Restraint::evaluate() fails on restraints in restraint sets > because it uses the above function > - RestraintSets containing a mix of incremental and non-incremental > restraints don't support incremental evaluation, making using > restraint sets much slower than not using them in certain > circumstances > > There are two solutions that I see: > > - move RestraintSet to the kernel and have the model traverse them > internally so it is aware of the whole tree. This would slightly > complicated the Model and would break some existing code (we could > leave a deprecated core::RestraintSet with the above limitations) > > - directly address the above problems by having the Model compute > the dependencies of unknown restraints on the fly and adding a mixed > evaluation mode to restraints which do some of both incremental and > non-incremental. This might complicate all restraints a bit and I > worry that we would run into other problems later. Not too sure of > all of the implications of this route. > > Thoughts? > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev