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