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

Re: [IMP-dev] Proposed bonded/nonbonded list interfaces



Ben Webb wrote:
The interfaces look reasonable to me. But the list of bonded particles
should be static, IMHO - it's a waste to rebuild it at every score evaluation - since it'll only change if you add/remove particles or bonds. But I guess that's an implementation detail.
What do you mean by static? Only updated occasionally? You only call the set_particles method when the set of particles you care about changes. For most people, that will be exactly never. But I need to be able to update things and you can't easily rebuild the state as there is no way of knowing all the Restraints which need pointers to it short of rebuilding everything.

Static as in the keyword would be bad :-)

This is the only thing I have a problem with. What do these three
parameters mean? I guess length and stiffness translate to the mean and standard deviation of a Gaussian restraint. But this isn't the best place to put this kind of thing - what if the user wanted to use a cubic spline instead? A bond generally just identifies a pair of atoms, and the restraint contains the length/stiffness/whatever information. This could in turn be populated from your force field (e.g. using atom types).
I guess I should have been more careful in how I described things. The BondedState is oblivious to what is actually put in the BondDecorator. It just passes some (unknown) information back (we could just pass back a Particle* instead). What is done with that information is up to the restraint that uses it. I have a restraint that just uses them to make a harmonic potential, but the restraints are trivial and new ones can be written easily.

We do, eventually, need some way of having different types of bonds (with different BondedListStates) all of which are used by the same NonbondedListState. One way to do this would be to have the bond restraints check a bond type field in the bond and only process ones of a recognized type. An alternative would be to have the NonbondedListState have a vector of BondedListStates and look in each of them.

Given that the number of bonds should generally be smaller than the number of non-bonded pairs, it should be a bit more efficient to have the restraints check the bond type.