exact restarts were problematic in amber9 REMD for many reasons, some
more difficult than others to have a simple fix. this is why it was
completely rewritten for amber10.
carlos
On Thu, Sep 11, 2008 at 12:32 PM, Volodymyr Babin <vbabin.ncsu.edu> wrote:
> Dear All,
>
> I believe I saw this Amber9 bug too; and even informed someone
> about it back in spring if I recall correctly.
>
> Have a great day,
> Volodymyr
>
> On Thu, September 11, 2008 11:59, David A. Case wrote:
>> On Wed, Sep 10, 2008, Holger Gohlke wrote:
>>>
>>> I sent the email below yesterday, but I am not sure whether it went
>>> through on the amber-developers reflector. If I am right, the problem
>>> that
>>> we found is severe, because restarting a REMD run would mean to take the
>>> wrong coordinates for the respective temperature. I attached a patch and
>>> I
>>> would be happy if you can have a look here.
>>
>> I'll forward this to the developers' list, since it doesnt' seem to be
>> on the archives.
>>
>>>
>>> Finally, may I ask to get CVS access again to the amber tree? Currently,
>>> we are correcting some overdue issues related to mm_pbsa, and we would
>>> like to carry over the changes to amber11.
>>
>> I'll look into this and get back to you.
>>
>> ...dave
>>
>>>
>>> ------------------------ Ursprüngliche Nachricht
>>> -------------------------
>>> Betreff: input coords for REMD in Amber9
>>> Von: "Holger Gohlke" <gohlke.pharmazie.uni-kiel.de>
>>> Datum: Di, 9.09.2008, 15:55
>>> An: amber-developers.scripps.edu
>>> --------------------------------------------------------------------------
>>>
>>> Dear all,
>>>
>>> I think we ran across a problem when restarting a REMD run in Amber 9
>>> using REPCRD=0. In this case, the wrong input coordinates for the
>>> anticipated temperature are read. This is shown in the REMD debug
>>> information below.
>>>
>>> I attach a patch file that should correct this, but I would be happy if
>>> somebody can confirm this.
>>>
>>> Best regards
>>>
>>> Holger
>>>
>>> >>>>>
>>> calling sander to get initial energy
>>>
>>> in runmd, myeptot is -3660.81356490524
>>> in runmd, mytargettemp is 300.000000000000
>>>
>>> back from first sander call
>>> MyEptot is -3660.81356490524
>>> MAIN LOOP, currx is 1
>>> calling subrem on exchange # 1
>>> gathering temperature/energy data
>>> doing myindex lookup
>>> mytargettemp is 300.000000000000
>>> temptable
>>> 300.000000000000 305.811500000000 311.735300000000
>>> 317.773400000000 323.928100000000 330.201600000000
>>> 336.596300000000 343.114400000000 349.758400000000
>>> 356.530600000000 363.433600000000 370.469900000000
>>> 377.642000000000 384.952600000000 392.404400000000
>>> 400.000000000000
>>> my index in sorted T list: 1
>>> my replica # is 9
>>> l_index and r_index are 16 2
>>> l_temp0 and r_temp0 are 400.000000000000 305.811500000000
>>> l_repnum and r_repnum are 16 2
>>> jumpright is T
>>> partner index 16
>>> partner repnum 16
>>> myeptot and o_eptot are -3660.81356490524 -2841.08902648973
>>> mytemp and o_temp are 300.000000000000 400.000000000000
>>> NOT controlling exchange
>>> done with exchange swap
>>> exchange is F
>>> newtargettemp is 300.000000000000
>>> leaving subrem
>>> called mdfil to change file names
>>> here is my post-exchange file info
>>> mdin:
>>> md_nvt_prod_impl_re_940.in.000
>>>
>>> mdout:
>>> md_nvt_prod_impl_re_940.out.000
>>>
>>> mdcrd:
>>> md_nvt_prod_impl_re_940.mdcrd.000
>>>
>>> mdinfo:
>>> mdinfo
>>>
>>> inpcrd:
>>> md_nvt_prod_impl_re_939.restrt.000
>>> ^^^^^
>>> !!! This should be 008 instead of 000, because at the end of run 939,
>>> !!! it was replica 9 that had a target temperature of 300K.
>>>
>>> restrt:
>>> md_nvt_prod_impl_re_940.restrt.008
>>>
>>> calling sander for MD run
>>> >>>>>
>>>
>>>
>>> --
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++
>>> Dr. Holger Gohlke
>>
>
>
Received on Fri Sep 12 2008 - 03:07:19 PDT
