Restraint probably should provide an implementation of get_interacting_particles() that returns std::vector<Particles>(1, Particles(particles_begin(), particles_end()) since that is correct in many cases and just results in inefficiency if most other cases.
And I like the name "get_interacting_particles" a bit better than "get_interacting_sets" since we are talking about particles. But what do we call Particles's (i.e. std::vector<Particles>)?
On Aug 18, 2008, at 2:35 PM, Keren Lasker wrote:
> DOMINO does not know what type of restraints is given. > You can potentially give a NonBondedList - but then the optimization > will not be efficient. > The optimization workflow ( which calls DOMINO) excludes the > restraint. > > On Aug 18, 2008, at 11:29 PM, Daniel Russel wrote: > >> So what is the protocol for dealing with NonBondedList-like >> restraints? Do you feed domino a list of restraints which exclude >> them? That is probably better than having it try to detect and skip >> such restraints. >> >> >> On Aug 18, 2008, at 2:15 PM, Keren Lasker wrote: >> >>> >>> On Aug 18, 2008, at 11:06 PM, Daniel Russel wrote: >>> >>>>>> Keren, what is your use case? If it's not "get a list of >>>>>> interacting >>>>>> pairs" then we'll need to do something different. >>>>> Ben - as I wrote in my last reply - it is not all_pairs, since the >>>>> optimization tries to find that. We get MSMS data which says >>>>> a,b,c,d,e >>>>> create a complex - but we do not know which interacts with which. >>>>> so >>>>> what DOMINO needs out of the restraint is a-e . >>>> >>>> It seems there are four different classes of restraints: >>>> 1) simple restraints where all particles in the restraint do >>>> interaction (for example DistanceRestraint) >>>> >>>> 2) compound restraints where there are a number of different sets >>>> of >>>> particles where the particles interactions within the set but there >>>> are no interactions between sets within the restraint: >>>> PairListRestraint or BondedListRestraint or SingletonListRestraint >>>> or >>>> most of the other restraints >>>> >>>> 3) combinatorial restraits where ultimately there will be several >>>> interacting subsets of particles, but the makeup of the subsets are >>>> not known until the end of the optimization (ConnectivityRestraint >>>> or >>>> LowestNRestraint) >>>> >>>> 4) and a group without a good name where all of the particles >>>> interact >>>> in some sense, but only a few of the interactions directly affect >>>> the >>>> final solution (such as NonBondedRestraint). >>>> >>>> As far as I can tell, you want: >>>> 1) the set of all the particles >>>> 2) a list of sets of particles >>>> 3) the set of all the particles >>>> 4) I don't know what you want for this or perhaps just disallow it >>>> with Domino? >>>> >>>> So a get_interacting_sets method which returns a vector of >>>> Particles's >>>> (the two s's are intentional :-) would be what you want. >>>> ___________ >>> >>> thanks Daniel ! >>> DOMINO ignores NonBondedRestraint since otherwise the restraint >>> graph >>> is a clique. >>> so yes - get_interacting_sets would be sufficient ! :) >>> For example, for the MSMS restraint we use ConnectivityRestraint. >>> >>> is your solution ok with everyone? >>> >>> >>> >>> >>> >>>> ____________________________________ >>>> IMP-dev mailing list >>>> IMP-dev@salilab.org >>>> https://salilab.org/mailman/listinfo/imp-dev >>> >>> _______________________________________________ >>> IMP-dev mailing list >>> IMP-dev@salilab.org >>> https://salilab.org/mailman/listinfo/imp-dev >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev