Re: [IMP-dev] Update SphericalRestraint
Daniel Russel wrote: > I think we may want to think about removing the list of particles from > the Restraint base class and providing several restraint subclasses > which use different containers to store the particles (this would be a > fairly minor change given the IMP_RESTRAINT macro and the current > interface). Then, we could have restraints which require a dynamic set > use a std::set, and ones which just have a static list or (like distance > restraint) a fixed number, use a vector or just member variables.
Agreed - although I suggest there's little point in doing that unless we have specific restraints in mind which need such functionality.
> I have ended up rolling my own version of ExclusionVolume. I have a > version which either enforces excluded volume, or, if the particles are > bonded, enforces the bond (it uses the BondDecorator def of bond). I > suspect something on those lines will be more useful in the long run as > we rarely have a set of particles where nothing is interacting tightly.
As you mention elsewhere, this is probably pretty slow. The usual way of doing such a thing efficiently (at least in molecular mechanics packages) is to have two restraints - one is the stereochemical restraint, a simple loop over all bonds (in the Modeller case, this is done just once and restraints are set up for each bond) while the second is the excluded volume restraint, a loop over all nonbonded pairs. Part of the nonbonded pair generation mechanism excludes bonded particles.
Ben
>> while the second is the excluded volume restraint, a loop over all >> nonbonded pairs. Part of the nonbonded pair generation mechanism >> excludes bonded particles. Right, then the interesting question is how to do the non-bonded particle generation. From what I gather with modeller, the speedups compared to what I am describing come from using a proximity structure and caching the list rather than separating the bonded from the nonbonded computations. When generating the list you have to do a similar lookup to see if each pair is bonded? Or is there some more clever way of structuring things?
Daniel Russel wrote: >>> while the second is the excluded volume restraint, a loop over all >>> nonbonded pairs. Part of the nonbonded pair generation mechanism >>> excludes bonded particles. > Right, then the interesting question is how to do the non-bonded > particle generation. From what I gather with modeller, the speedups > compared to what I am describing come from using a proximity structure > and caching the list rather than separating the bonded from the > nonbonded computations. When generating the list you have to do a > similar lookup to see if each pair is bonded? Or is there some more > clever way of structuring things?
The separation of bonded from nonbonded interactions isn't an efficiency issue - it's a flexibility issue. Bonded and nonbonded interactions are rather different, so it's more much useful to have them handled by separate restraints; bonded interactions are local high-frequency interactions, while nonbonded are nonlocal and lower frequency. So for example you may want to treat them differently in multi-timescale treatments. Many molecular mechanics packages achieve efficiency gains by simply neglecting the high frequency oscillations of the system, i.e. using constraints such as SHAKE to fix bond lengths and angles rather than using restraints. And in the Modeller world, in most optimizations we calculate bond terms at every step, but either scale or turn off the nonbonded interactions.
Modeller uses the more-or-less standard cell-based nonbonded list generator, which has O(NlogN) performance. Bonded pairs (and any other excluded pairs, such as 1-4 interactions) are excluded from the list using a hash table with a sensibly chosen hash function.
Ben
A good setup to aim for might be to have a State which builds a fast lookup structure on the bonds for a set of particles and another State which maintains the volume grid for a set. Then the ExclusionVolumeRestraint can use the two States to find nearby pairs and pairs to skip pairs which are bonded. Same for various Restraints for handling bonds (although it is not immediately clear what the best way to handle multiple types of bonds is).
On Dec 16, 2007, at 10:33 AM, Ben Webb wrote:
> Daniel Russel wrote: >>>> while the second is the excluded volume restraint, a loop over all >>>> nonbonded pairs. Part of the nonbonded pair generation mechanism >>>> excludes bonded particles. >> Right, then the interesting question is how to do the non-bonded >> particle generation. From what I gather with modeller, the speedups >> compared to what I am describing come from using a proximity >> structure >> and caching the list rather than separating the bonded from the >> nonbonded computations. When generating the list you have to do a >> similar lookup to see if each pair is bonded? Or is there some more >> clever way of structuring things? > > The separation of bonded from nonbonded interactions isn't an > efficiency > issue - it's a flexibility issue.
> Bonded and nonbonded interactions are > rather different, so it's more much useful to have them handled by > separate restraints; bonded interactions are local high-frequency > interactions, while nonbonded are nonlocal and lower frequency. So for > example you may want to treat them differently in multi-timescale > treatments. Many molecular mechanics packages achieve efficiency gains > by simply neglecting the high frequency oscillations of the system, > i.e. > using constraints such as SHAKE to fix bond lengths and angles rather > than using restraints. And in the Modeller world, in most > optimizations > we calculate bond terms at every step, but either scale or turn off > the > nonbonded interactions. > > Modeller uses the more-or-less standard cell-based nonbonded list > generator, which has O(NlogN) performance. Bonded pairs (and any other > excluded pairs, such as 1-4 interactions) are excluded from the list > using a hash table with a sensibly chosen hash function. > > Ben > -- > ben@salilab.org http://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
participants (2)
-
Ben Webb -
Daniel Russel