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?
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
On 1/14/10 11:36 AM, Keren Lasker wrote: > 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.
Sounds reasonable to me.
Ben
Dear developers, I'm a beginner IMP user and have a quick question. Suppose I got N particles defined in IMP.core.ListSingletonContainer() and need to restraint them inside either 2 separate spheres, e.g. having centers @(-100,0,0) and (100,0,0) with radius R<100. Can I use MinimumSingletonScoreRestraint to deal with it? Please advise me how to construct a script/recipe for it. Thanks in advance. Regards, Harianto.
What you want is kind of the opposite of what the MinimumSingletonScoreRestraint provides. Although, now that you mention it, the name does suggest it should do what you are asking. Oops.
As I understand it, the general version of what you need is something that scores a particle against two different singletonscores and returns the lower of the two scores (and the corresponding derivatives). This could be implemented as a SingletonScore which has two nested singleton scores. This would be quite easy to implement and seems like a reasonable general capability, so it can be added if you are interested. Or, if you will be implementing scoring functions for IMP, it would be a good starting point for figuring things out and I can help you with it.
That said, if efficiency is an issue for you, a custom score function would be much faster (since you can simply look eg x coordinate of the particle to decided which sphere it is closer to).
On Jan 19, 2010, at 11:27 AM, Harianto Tjong wrote:
> Dear developers, > I'm a beginner IMP user and have a quick question. > Suppose I got N particles defined in IMP.core.ListSingletonContainer() > and need to restraint them inside either 2 separate spheres, e.g. having > centers @(-100,0,0) and (100,0,0) with radius R<100. Can I use > MinimumSingletonScoreRestraint to deal with it? Please advise me how to > construct a script/recipe for it. > Thanks in advance. > Regards, > Harianto. > > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
participants (4)
-
Ben Webb -
Daniel Russel -
Harianto Tjong -
Keren Lasker