The core::MonteCarlo code is rather a mess, has bugs and has subject to a lot of churn. This is primarily because it is trying to do too many different things, resulting is very complicated code. I'd like to break it up into several classes each with a single mode of operation. In particular, there would be
- core.MonteCarlo, which does simple Monte Carlo (apply some movers and accept or reject) as well as provide some finer grained functionality for implementing less trivial monte carlo protocols.
- core.MonteCarloWithLocalOptimization which applies some local optimization scheme after the moves and accepts or rejects the relaxed conformation
- core.MonteCarloWithBasinHopping which supports basin hopping (apply a monte carlo move and then accept or reject based on the score after
The main noticeably change would be that code that looks like mc= IMP.core.MonteCarlo() mc.set_model(m) cg= IMP.core.ConjugateGradients() mc.set_local_optimizer(cg) mc.set_local_steps(10)
would need to be replaced by cg= IMP.core.ConjugateGradients(m) IMP.core.MonteCarloWithLocalOptimization(cg, 10)
Comments?
Sounds good indeed. You talk of bugs, which are they? And I think having a HybridMonteCarlo optimizer would be nice, cause now we can only have python wrappers around MD to make it work. Y
On 06/03/2011 03:44 PM, Daniel Russel wrote: > The core::MonteCarlo code is rather a mess, has bugs and has subject to a lot of churn. This is primarily because it is trying to do too many different things, resulting is very complicated code. I'd like to break it up into several classes each with a single mode of operation. In particular, there would be > > - core.MonteCarlo, which does simple Monte Carlo (apply some movers and accept or reject) as well as provide some finer grained functionality for implementing less trivial monte carlo protocols. > > - core.MonteCarloWithLocalOptimization which applies some local optimization scheme after the moves and accepts or rejects the relaxed conformation > > - core.MonteCarloWithBasinHopping which supports basin hopping (apply a monte carlo move and then accept or reject based on the score after > > The main noticeably change would be that code that looks like > mc= IMP.core.MonteCarlo() > mc.set_model(m) > cg= IMP.core.ConjugateGradients() > mc.set_local_optimizer(cg) > mc.set_local_steps(10) > > would need to be replaced by > cg= IMP.core.ConjugateGradients(m) > IMP.core.MonteCarloWithLocalOptimization(cg, 10) > > Comments? > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
On Jun 3, 2011, at 12:48 PM, Yannick Spill wrote:
> Sounds good indeed. You talk of bugs, which are they? Not sure. Riccardo was getting bad answers with the current svn version, and gets better answers with the cleaned up one. The main point is I don't want to try to debug the old one.
> And I think having a HybridMonteCarlo optimizer would be nice, cause now > we can only have python wrappers around MD to make it work. The functionality provided in core.MonteCarlo should make that easier to implement as it exposes do_move() to apply the movers do_accept_or_reject_move(energy) to decide if that energy is good enough to accept everything that has happened and a hook do_step() so that individual implementations can do all the stuff they need to around moves and energy computations and stuff.
> Y > > > On 06/03/2011 03:44 PM, Daniel Russel wrote: >> The core::MonteCarlo code is rather a mess, has bugs and has subject to a lot of churn. This is primarily because it is trying to do too many different things, resulting is very complicated code. I'd like to break it up into several classes each with a single mode of operation. In particular, there would be >> >> - core.MonteCarlo, which does simple Monte Carlo (apply some movers and accept or reject) as well as provide some finer grained functionality for implementing less trivial monte carlo protocols. >> >> - core.MonteCarloWithLocalOptimization which applies some local optimization scheme after the moves and accepts or rejects the relaxed conformation >> >> - core.MonteCarloWithBasinHopping which supports basin hopping (apply a monte carlo move and then accept or reject based on the score after >> >> The main noticeably change would be that code that looks like >> mc= IMP.core.MonteCarlo() >> mc.set_model(m) >> cg= IMP.core.ConjugateGradients() >> mc.set_local_optimizer(cg) >> mc.set_local_steps(10) >> >> would need to be replaced by >> cg= IMP.core.ConjugateGradients(m) >> IMP.core.MonteCarloWithLocalOptimization(cg, 10) >> >> Comments? >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
>> And I think having a HybridMonteCarlo optimizer would be nice, cause now >> we can only have python wrappers around MD to make it work. > The functionality provided in core.MonteCarlo should make that easier to implement as it exposes > do_move() to apply the movers > do_accept_or_reject_move(energy) to decide if that energy is good enough to accept everything that has happened > and a hook > do_step() so that individual implementations can do all the stuff they need to around moves and energy computations and stuff. >
by core.MonteCarlo do you mean the new one you are planning to implement? Cause we had walked through the old code and it was incompatible with
oldconf = store_current_conf() for all gibbs_steps: ... sample other gibbs variables ... for all mc_steps: assign_velocities(300K) oldene = get_etot() md_NVE() newene = get_etot() if metropolis_reject(oldene,newene): reset_coordinates_to(oldconf)
because assign_velocities changes the total energy. Y
Yes, I mean the new core.MonteCarlo. It should facilitate implementation of your MC algorithm if we add a function that allows you to specify the old energy to use when deciding to accept or reject the step.
On Jun 3, 2011, at 1:17 PM, Yannick Spill wrote:
> >>> And I think having a HybridMonteCarlo optimizer would be nice, cause now >>> we can only have python wrappers around MD to make it work. >> The functionality provided in core.MonteCarlo should make that easier to implement as it exposes >> do_move() to apply the movers >> do_accept_or_reject_move(energy) to decide if that energy is good enough to accept everything that has happened >> and a hook >> do_step() so that individual implementations can do all the stuff they need to around moves and energy computations and stuff. >> > > by core.MonteCarlo do you mean the new one you are planning to implement? Cause we had walked through the old code and it was incompatible with > > oldconf = store_current_conf() > for all gibbs_steps: > … sample other gibbs variables … > for all mc_steps: > assign_velocities(300K) > oldene = get_etot() > md_NVE() > newene = get_etot() > if metropolis_reject(oldene,newene): > reset_coordinates_to(oldconf) > > > because assign_velocities changes the total energy. > Y > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
Has the set_temperature() method been removed from all of the MonteCarlo classes?
Davide
On Jun 3, 2011, at 9:44 PM, Daniel Russel wrote:
> The core::MonteCarlo code is rather a mess, has bugs and has subject to a lot of churn. This is primarily because it is trying to do too many different things, resulting is very complicated code. I'd like to break it up into several classes each with a single mode of operation. In particular, there would be > > - core.MonteCarlo, which does simple Monte Carlo (apply some movers and accept or reject) as well as provide some finer grained functionality for implementing less trivial monte carlo protocols. > > - core.MonteCarloWithLocalOptimization which applies some local optimization scheme after the moves and accepts or rejects the relaxed conformation > > - core.MonteCarloWithBasinHopping which supports basin hopping (apply a monte carlo move and then accept or reject based on the score after > > The main noticeably change would be that code that looks like > mc= IMP.core.MonteCarlo() > mc.set_model(m) > cg= IMP.core.ConjugateGradients() > mc.set_local_optimizer(cg) > mc.set_local_steps(10) > > would need to be replaced by > cg= IMP.core.ConjugateGradients(m) > IMP.core.MonteCarloWithLocalOptimization(cg, 10) > > Comments? > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
The method was renamed to set_kT since it was setting kT, not T.
On Jun 9, 2011, at 5:54 AM, Davide Baù wrote:
> Has the set_temperature() method been removed from all of the MonteCarlo classes? > > Davide > > > > On Jun 3, 2011, at 9:44 PM, Daniel Russel wrote: > >> The core::MonteCarlo code is rather a mess, has bugs and has subject to a lot of churn. This is primarily because it is trying to do too many different things, resulting is very complicated code. I'd like to break it up into several classes each with a single mode of operation. In particular, there would be >> >> - core.MonteCarlo, which does simple Monte Carlo (apply some movers and accept or reject) as well as provide some finer grained functionality for implementing less trivial monte carlo protocols. >> >> - core.MonteCarloWithLocalOptimization which applies some local optimization scheme after the moves and accepts or rejects the relaxed conformation >> >> - core.MonteCarloWithBasinHopping which supports basin hopping (apply a monte carlo move and then accept or reject based on the score after >> >> The main noticeably change would be that code that looks like >> mc= IMP.core.MonteCarlo() >> mc.set_model(m) >> cg= IMP.core.ConjugateGradients() >> mc.set_local_optimizer(cg) >> mc.set_local_steps(10) >> >> would need to be replaced by >> cg= IMP.core.ConjugateGradients(m) >> IMP.core.MonteCarloWithLocalOptimization(cg, 10) >> >> Comments? >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
It is worth reading the version history file (doc/history.dox) when you upgrade as it lists the various improvements and breaking changes. The dates are a bit vague at the moment, I should probably go back to giving actual dates or svn version numbers for things.
On Jun 9, 2011, at 5:54 AM, Davide Baù wrote:
> Has the set_temperature() method been removed from all of the MonteCarlo classes? > > Davide > > > > On Jun 3, 2011, at 9:44 PM, Daniel Russel wrote: > >> The core::MonteCarlo code is rather a mess, has bugs and has subject to a lot of churn. This is primarily because it is trying to do too many different things, resulting is very complicated code. I'd like to break it up into several classes each with a single mode of operation. In particular, there would be >> >> - core.MonteCarlo, which does simple Monte Carlo (apply some movers and accept or reject) as well as provide some finer grained functionality for implementing less trivial monte carlo protocols. >> >> - core.MonteCarloWithLocalOptimization which applies some local optimization scheme after the moves and accepts or rejects the relaxed conformation >> >> - core.MonteCarloWithBasinHopping which supports basin hopping (apply a monte carlo move and then accept or reject based on the score after >> >> The main noticeably change would be that code that looks like >> mc= IMP.core.MonteCarlo() >> mc.set_model(m) >> cg= IMP.core.ConjugateGradients() >> mc.set_local_optimizer(cg) >> mc.set_local_steps(10) >> >> would need to be replaced by >> cg= IMP.core.ConjugateGradients(m) >> IMP.core.MonteCarloWithLocalOptimization(cg, 10) >> >> Comments? >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
My bad, didn't know about the history file.
Davide
On Jun 9, 2011, at 4:45 PM, Daniel Russel wrote:
> It is worth reading the version history file (doc/history.dox) when you upgrade as it lists the various improvements and breaking changes. The dates are a bit vague at the moment, I should probably go back to giving actual dates or svn version numbers for things. > > On Jun 9, 2011, at 5:54 AM, Davide Baù wrote: > >> Has the set_temperature() method been removed from all of the MonteCarlo classes? >> >> Davide >> >> >> >> On Jun 3, 2011, at 9:44 PM, Daniel Russel wrote: >> >>> The core::MonteCarlo code is rather a mess, has bugs and has subject to a lot of churn. This is primarily because it is trying to do too many different things, resulting is very complicated code. I'd like to break it up into several classes each with a single mode of operation. In particular, there would be >>> >>> - core.MonteCarlo, which does simple Monte Carlo (apply some movers and accept or reject) as well as provide some finer grained functionality for implementing less trivial monte carlo protocols. >>> >>> - core.MonteCarloWithLocalOptimization which applies some local optimization scheme after the moves and accepts or rejects the relaxed conformation >>> >>> - core.MonteCarloWithBasinHopping which supports basin hopping (apply a monte carlo move and then accept or reject based on the score after >>> >>> The main noticeably change would be that code that looks like >>> mc= IMP.core.MonteCarlo() >>> mc.set_model(m) >>> cg= IMP.core.ConjugateGradients() >>> mc.set_local_optimizer(cg) >>> mc.set_local_steps(10) >>> >>> would need to be replaced by >>> cg= IMP.core.ConjugateGradients(m) >>> IMP.core.MonteCarloWithLocalOptimization(cg, 10) >>> >>> Comments? >>> _______________________________________________ >>> IMP-dev mailing list >>> IMP-dev@salilab.org >>> https://salilab.org/mailman/listinfo/imp-dev >> >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
participants (4)
-
Daniel Russel -
Daniel Russel -
Davide Baù -
Yannick Spill