There have been a lot of minor changes since I last sent out such an
email, I'll leave those to the release notes and instead and detail
the more interesting ones.
Scoring of models is now organized around ScoringFunction objects. The
look kind of like how the scoring part of a the model used to look
(with evaluate calls), but are independent objects. You can create
different types and instances of them (most commonly, a
IMP::core::RestraintsScoringFunction from a list of restraints). They
can then be used to specify how a particular optimizer or sampler
scores it models (making it easier to use different scoring functions
for different things). And different scoring methods can be used (eg
an IMP::core::IncrementalScoringFunction when only moving a small
number of particles at a time). This change resulted in a vast
simplification on the code used to evaluate restraints and resulted in
the fixing of many bugs. Moving forwards, it makes it easier to
support multithreaded scoring (which can be done by implementing a new
ScoringFunction subclass). The changes are more or less backwards
compatible as basic scoring through Model::evaluate and
Restraint::evaluate is still supported, so little code should need to
be changed.
There is a new base class IMP::ModelObject for all objects which
introduce dependencies in the model. IMP::Particle, IMP::ScoreState,
IMP::Restraint, IMP::ScoringFunction and IMP::core::Mover all inherit
from it. Such objects, when they are registered with the Model (either
via a set_model() call or passing the Model to the constructor, or,
for backwards compatibility, adding a restraint to the Model or
ScoringFunction or adding a ScoreState to the Model) are considered
part of the Model (until they are unregistered or destroyed). They can
take action when the set of dependencies changes, so that
relationships can be correctly updated when, eg, rigid bodies are
destroyed or added (most classes don't do this yet). This also opens
the way for IMP::core::Movers to have more intelligence, so they can,
for example, weight the move probabilities based on how much a given
particle contributes to a score (and properly maintain this weighting
as things change).
Also, decomposing restraints into their simplest parts (eg a
non-bonded list into n^2 pairwise terms), works in the obvious manner
and so contexts that want to use such simple restraints (such as
incremental scoring) can do so directly.
Scoring in Domino has been simplified around a single
IMP::domino::RestraintCache object that provides a centralized cache
for all restraints used. This provides a single point to control
memory usage (by bounding the total number of cache entries),
serialize and unserialize. In addition, coupled with the previous
change, it removes the need for the IMP::domino::OptimizeRestraints
objects as the restraint cache does that operation internally.
Many unnecessary #include statements in IMP headers have been removed.
As a result, it may be necessary to add #includes to code not in the
IMP repository to get it to compile. As a general rule, you should
#include the header defining any symbol you use in a given .h or .cpp
file (and not depend on it being indirectly included through another
header).
Restraints now store (and can produce) the score returned in their
last evaluate call.
I made efforts to provide backwards compatibility throughout the
changes. But I did remove various methods that I though were unlikely
to be used by anyone and so not worth the trouble to provide in the
new internal architecture. If there is some method that I removed that
you really need, email me and we can figure out a work around or can
provide a backwards compatibility interface.