[IMP-dev] Proposal: replace BasicScoreFuncParams with PairPotential

[Ben Webb <>]

I propose to replace BasicScoreFuncParams with classes derived from 
PairPotential (of course the name is also up for discussion if you hate 
that one). This would then be used by restraints that need a ScoreFunc 
generator (Connectivity, ExclusionVolume, PairConnectivity, Proximity). 
PairPotential classes are simple generators that create new ScoreFunc 
objects, given two Particles:

class PairPotential
{
public:
  virtual ScoreFunc* create_score_func(Particle *p1, Particle *p2) = 0;
};

class UpperBoundPairPotential : public PairPotential
{
public:
  UpperBoundPairPotential(Float mean, Float stdev);
  UpperBoundPairPotential(FloatKey radius, Float stdev);
  ScoreFunc* create_score_func(Particle*, Particle*) {
    return new HarmonicUpperBound(some_mean, some_stdev);
  }
};

Restraints such as ProximityRestraint then take a pointer to a 
PairPotential, and own it. The advantage is that ProximityRestraint's 
two constructors (one using a fixed mean, and the other a fixed particle 
radius attribute) can now be collapsed into one; the 'add two radii 
together to get a mean distance' logic is now in the PairPotential. The 
other advantage is that pair potentials which do not use mean/stdev at 
all are straightforward. For example, a DOPE potential might look 
something like:

class DOPEPotential : public PairPotential
{
public:
  DOPEPotential();
  ScoreFunc* create_score_func(Particle* p1, Particle* p2) {
    return new CubicSpline(p1->get_value("atom_type"),
                           p2->get_value("atom_type"));
  }
};

Any thoughts/problems? I can of course clarify if any of this is unclear.

	Ben
--
                      http://salilab.org/~ben/
"It is a capital mistake to theorize before one has data."
	- Sir Arthur Conan Doyle