Hi All,
First, my apologies for my previous emails about this where I referred
to Amber10, when the first email clearly stated it was an Amber9
problem.
After running my own tests I can see where the bug comes from. Amber9
REMD is a bit confusing in that even when repcrd=0 (print out
trajectories and information by temperature), restart files always
behave in a replica-specific fashion (which means among other things
that the lowest number restart file is not necessarily the lowest
temperature restart file). In multisander.f the input coordinates of
the current exchange are set to be the restart file of the previous
exchange, except on the first exchange where the input coordinates are
the ones specified by '-c'.
However, this doesn't take care of REMD run restarts; if we are
restarting the run, on the first exchange we want inpcrd to be the one
we read the temperature from, not the one with the extension that
corresponds to the temperature list. So, I just added a section that
will restore the original inpcrd that has the correct temperature on
the first exchange if irest=1. I am attaching a patch that will modify
multisander.f to do this. I have run it through the standard test
cases and it seems to work fine, but I would like Holger and perhaps
others to verify it works as well.
-Dan
On Mon, Sep 22, 2008 at 6:59 AM, Holger Gohlke
<gohlke.pharmazie.uni-kiel.de> wrote:
> Dear Dan,
>
> I haven't heard anything anymore about the REMD restart issue. Are you
> able to confirm what we found? If needed, we can send input files with
> which we observed the wrong behavior. I would be happy if you can have a
> look here again, because I think that a patch should finally be added to
> the web page for the benefit of other users.
>
> Best regards
>
> Holger
>
>> I've just run a test to confirm this behavior.
>>
>> So to recap, the temperature that is assigned to a replica depends on
>> the value of irest.
>>
>> irest=1: Replica Temperatures will be read from the restart files.
>> irest=0: Replica Temperatures will be read from mdin (as temp0).
>>
>> This is a departure from the previous behavior of REMD, where you had
>> to read the temperatures from the restarts no matter what. I noted
>> this in the 'Changes to REMD in Amber10' section of the manual, but
>> maybe the code should print out more information in the output file,
>> explicitly stating where the replica temperatures are being read from.
>>
>> What does everyone else think?
>>
>> -Dan
>>
>> On Thu, Sep 11, 2008 at 12:14 PM, Daniel Roe <daniel.r.roe.gmail.com>
>> wrote:
>>> Holger,
>>>
>>> I'm not sure if you checked this yet, but what is the value of irest
>>> you are using? This will change the behavior of how the temperatures
>>> are chosen. From the Amber10 manual:
>>>
>>> "The value for irest no longer needs to be 1. An irest value of 1 will
>>> cause the replica temperatures to
>>> be read from the restart files - otherwise the replica temperatures
>>> will be read from the input files."
>>>
>>> If your irest is 0 it will assign the temperature you specified in the
>>> mdin file to that replica.
>>>
>>> -Dan
>>>
>>> On Thu, Sep 11, 2008 at 11:59 AM, David A. Case
>>> <case.biomaps.rutgers.edu> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Daniel R. Roe, Ph.D.
>>> Research Chemist
>>> National Institute of Standards and Technology
>>> 100 Bureau Drive, Stop 8443
>>> Gaithersburg, MD 20899-8443
>>> (301) 975-8741
>>>
>>
>>
>>
>> --
>> Daniel R. Roe, Ph.D.
>> Research Chemist
>> National Institute of Standards and Technology
>> 100 Bureau Drive, Stop 8443
>> Gaithersburg, MD 20899-8443
>> (301) 975-8741
>>
>>
>
>
> --
> ++++++++++++++++++++++++++++++++++++++++++++++++++
> Dr. Holger Gohlke
> Professor fuer Pharmazeutische/Medizinische Chemie
>
> Christian-Albrechts-Universitaet zu Kiel
> Pharmazeutisches Institut
> Gutenbergstr. 76
> 24118 Kiel
> Germany
>
> Tel.: (+49) 431-880-1137; Fax: (+49) 431-880-1352
> Email: gohlke.pharmazie.uni-kiel.de
> URL: http://mbilab.uni-frankfurt.de
> ++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>
--
Daniel R. Roe, Ph.D.
Research Chemist
National Institute of Standards and Technology
100 Bureau Drive, Stop 8443
Gaithersburg, MD 20899-8443
(301) 975-8741
Received on Wed Sep 24 2008 - 05:07:58 PDT
