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.
Ben
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. > > Ben >
Daniel Russel wrote: > 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.
Agreed. There is no common functionality that I can think of (some cut and paste code, but that's no excuse for forcing inheritance). Initial implementation as r659.
Ben
participants (2)
-
Ben Webb -
Daniel Russel