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