Subject: Re: [IMP-dev] Proposal: new OptimizerState class
From: Daniel Russel <>
Date: Thu, 20 Dec 2007 13:52:50 -0800
Reply-to:
Sounds generally good.
What is the role of the State base class (that OptimizerState and
ScoreState inherit from). Would you want to allow things derived from
State and OptimizerState but not ScoreState to to added as optimizer
states? We can do that if we want, but it is a bit unusual.
If not, I think we should nix the common base class.
Ben Webb wrote:
We currently have a State class, which you can use to update some kind
of shared state every time the score is calculated.
You could also in principle use State to generate a trajectory during an
optimization (e.g. see test/md_optimizer/test_md_optimizer.py). This
works fine for optimizers such as molecular dynamics, where each step of
the optimization has a single evaluation of the score function. But it's
no good for optimizers like CG and SD, which may do multiple trial
evaluations per step - you only want to include the accepted points in
the trajectory. You could also imagine doing other things during an
optimization - for example, periodic recentering of the system,
resetting of thermostats, or rescaling of particle velocities.
Thus, I propose an OptimizerState class, which is similar to State but
is added to an optimizer rather than a model. Its update method would
then be called at every successful optimization step, rather than at
every score evaluation. To prevent people adding OptimizerStates to the
model, the current State should be renamed ScoreState and both
OptimizerState and ScoreState should derive from a common State base
class. A derived MDOptimizerState or similar class could be used in turn
as a base class for MD-specific stuff such as velocity scaling.