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.
> 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()
>> cg= IMP.core.ConjugateGradients()
>> would need to be replaced by
>> cg= IMP.core.ConjugateGradients(m)
>> IMP.core.MonteCarloWithLocalOptimization(cg, 10)
>> IMP-dev mailing list
> IMP-dev mailing list