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;
};
…
[View More]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
--
ben(a)salilab.org http://salilab.org/~ben/
"It is a capital mistake to theorize before one has data."
- Sir Arthur Conan Doyle
[View Less]
Apparently the %import directive is meant to be used with .i files
rather than .h files. impEM isn't doing the right thing (nor was
mine). I haven't yet checked if that solves my problems linking
multiple swig libs as I have only had my mac which doesn't exhibit the
problems.
In addition, we are not properly sharing the swig runtime info between
modules. Apparently we need to add " -DSWIG_TYPE_TABLE=IMP" to each
compilation of a _wrap.cc so that the information is properly shared. …
[View More]
Unfortunately, this includes EMbed (although EMbed doesn't have to
actually see any of the IMP code as the IMP there is just used as a
string).
I would also propose changing IMP_exceptions.i as follows in order to
allow other libraries to reuse the exception handling function by
%including IMP_exceptions.i rather than redefine a new one:
IMP_exceptions.i should contain:
%{
void IMP_swig_handle_exception(void);
%}
%exception {
try {
$action
} catch (...) {
IMP_swig_handle_exception();
/* This should be unnecessary, since handle_imp_exception cannot
return;
here just to quell lots of warnings about the 'result'
variable not
being initialized. */
SWIG_fail;
}
}
and putting the following in IMP.i to define the function uniquely.
%{
/* Code to convert C++ exceptions into scripting language errors.
Saves
having lots of catch statements in every single wrapper. */
void IMP_swig_handle_exception(void)
{
try {
throw;
} catch (std::out_of_range &e) {
SWIG_exception(SWIG_IndexError, e.what());
} catch (IMP::IndexException &e) {
SWIG_exception(SWIG_IndexError, e.what());
} catch (IMP::InvalidStateException &e) {
SWIG_exception(SWIG_ValueError, e.what());
} catch (IMP::ErrorException &e) {
SWIG_exception(SWIG_RuntimeError, e.what());
}
/* SWIG_exception contains "goto fail" so make sure the label is
defined */
fail:
return;
}
%}
Here is a patch for everything in IMP (not for EMbed).
[View Less]
