Well, it is not a potential, it generates scoring function terms.
Perhaps something like ScoreFunctionCreator would be better.
More substantially, it is not clear to me that we shouldn't have it
directly evaluate the score from the particles and skip the function
object creation. Creating the ScoreFunc doesn't cache anything useful
and just adds another layer of indirection. Internally they can use
ScoreFuncs if they want.
On Jan 2, 2008, at 6:19 PM, Ben Webb wrote:
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
};
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.