Daniel Russel wrote: > Since my emails are long, here in brief are the ideas (which can be > chosen independently): > 1) forget about function generators and just make the restraints shift > the distance value itself before calling the ScoreFunc. Then each > restraint just has one ScoreFunc and so modifications to it (such as > reducing its stiffness) are easy. > 2) separate the choice of pairs of particles from the actual > computation on the pair. So we have a set of restraints each of which > applies a computation to a differently generated set of pairs and a > set of computation functions each of which simply computes on a pair.
I certainly agree that reducing the number of objects is a good thing. But I'm not sure what you're proposing for (1). Let's say you want an LJ restraint (but let's pretend we can model it with a harmonic term, since we have that already). So this would need to iterate over all pairs of atoms (potentially via a nonbonded list). This you propose should be in the restraint (as it is now, but at evaluate rather than constructor time). Yes?
But what happens next? As I understand it, you propose that this restraint would have a single harmonic ScoreFunc and a single Pair function. Restraint.evaluate calls Pair.something() for each pair, which calculates the distance and then the score. But it's this last step which I'm unclear on. Where do the mean and the stdev (or width or stiffness) live? They are different for every atom pair, so they surely can't live in the ScoreFunc if you have only one. Maybe some pseudocode would elucidate this.
Ben