>> 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..