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

Re: [IMP-dev] Proposal: replace BasicScoreFuncParams with PairPotential



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
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
_______________________________________________
IMP-dev mailing list

https://salilab.org/mailman/listinfo/imp-dev