For a while I have been thinking it would be nice to add another layer of indirection for particle storage in IMP. The idea would be that we add some base classes like: class ParticleContainer { //provide virtual get_number, get, find etc. } class ParticlePairContainer; class ParticleSetContainer;
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.
We can have containers that are collections of containers so you really only have to update things in one place.
We could get rid of the problematic get_particles sorts of methods that we add for python since we can always just return this container (and I am sure we can figure out how to make it iterable).
We could probably do something clever with the get_interacting_particles method so that, in most cases, it just returns the Restraints ParticleContainer instance.
Would anyone else find this extra level of indirection useful?
Daniel Russel wrote: > For a while I have been thinking it would be nice to add another layer > of indirection for particle storage in IMP. The idea would be that we > add some base classes like: > class ParticleContainer { > //provide virtual get_number, get, find etc. > } > class ParticlePairContainer; > class ParticleSetContainer;
Sounds like a reasonable interface to me.
> 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.
Ben
>> 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..
participants (2)
-
Ben Webb -
Daniel Russel