Re: [IMP-dev] Abstracting storage

[Daniel Russel <>]

> > Then restraints would internally have a appropriate particle
> > container. The nice thing would be that you could then choose to  
> > share
> > containers between restraints and states as needed, reducing the
> > number of things that need to be updated when something changes.
> >
> > This could be implemented without changing the existing API since we
> > could leave the exiting get/set methods in the restraints. And just
> > add a method to set the container if you want it shared.
> >
> > NonbondedListRestraint would go away we we would just have
> > PairListRestraint (you just set the ParticlePairContainer in the
> > restraint to be the NonbondedList). Likewise, the BondedList base
> > class goes away and the BondDecoratorListRestraint.
>
> There definitely needs to be a little more flexibility in the  
> nonbonded
> list implementations. For example, it is often necessary to exclude
> pairs other than bonded pairs, for example 1-3 (angle) or 1-4  
> (dihedral)
> pairs, or specifically listed pairs (e.g. protein-ligand close
> contacts). Seems like it would make sense to allow this  
> functionality in
> whatever container is used by the nonbonded list.
You can do it now, but it has to be called a BondedList which makes it  
a bit obscure :-)

My proposal for cleaning up the NBL is to have a list of  
ParticlePairsContainer to exclude (these can generate their lists on  
the fly to handle skipping angles) and use a ParticleContainer for  
storage. And the NBL will be a ParticlePairsContainer.

I'll change the NonbondedRestraint to take the pair list (and change  
its name) and change the BondDecorator restraint to be a list  
restraint which uses ParticleContainer. Probably after the review is  
due.

There is one complication: ideally a NonBondedListScoreState (or a  
BondedListScoreState) would be both a ScoreState and a  
ParticlePairsContainer. However, doing this now would result in two  
reference counts for the object. So our options are either:
- make Object a virtual base class which adds a small amount of  
overhead to memory usage and perhaps runtime speed
- make a NonBondedListScoreState contain a PairContainer which  
somewhat increases the complexity of the interface
- make all *Containers also ScoreStates. This is not bad as you can  
always leave the update methods empty and several of the containers  
will need to be updated as score states.

I think I favor the second, but don't have strong feelings at this  
point..