[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [IMP-dev] Restraint::get_particles()

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
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
create a complex - but we do not know which interacts with which.
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
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

4) and a group without a good name where all of the particles
in some sense, but only a few of the interactions directly affect
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
(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 mailing list


IMP-dev mailing list


IMP-dev mailing list