Re: [AMBER-Developers] inconsistency in sander manual andcode forrestart velocities

From: Robert Duke <>
Date: Wed, 7 Jan 2009 12:37:49 -0500

I am not so sure this would work without breaking a lot of old stuff; I
would prefer that we just doc the stuff that exists correctly, or
potentially introduce an override based on a new variable that obsoletes the
old stuff completely, while still behaving correctly if the override is not
used (so you introduce a new namelist variable, that if present, controls
everything in a more transparent, less confusing manner; otherwise the old
namelist variables still exhibit the exact same behaviour as before, but
properly documented). At a minimum, we should get the doc right, and figure
out whether all the combos of irest and ntx that are allowed are legitimate
(I almost got to that point in pmemd, but figured there may be wierd things
folks want to do that I didn't understand).
Regards - Bob
----- Original Message -----
From: "Ross Walker" <>
To: "'AMBER Developers Mailing List'" <>
Sent: Wednesday, January 07, 2009 12:25 PM
Subject: RE: [AMBER-Developers] inconsistency in sander manual andcode
forrestart velocities

> When I first read Carlos's message I though it also meant that the random
> number seed was not set properly if ntx=5 and irest=0 which would be bad,
> but on re-reading I see this is not the case so it is not quite so bad.
> Hence it probably makes sense to just update the documentation, however,
> we
> should probably consider doing away with ntx altogether and just have
> sander
> detect what the file is. This way the use of velocities would be soley
> controlled by the value of irest. irest=1 reads the velocities while
> irest=0
> does not read them and calls setvel.
> Then if you want your own box sizes etc you need to specify the box values
> explicitly in the mdin file.
> We could make this behavior the case for amber11 and make a note in the
> manual about the difference in behavior over previous versions. If we
> simply
> ignore ntx then I think we maintain compatibility with older mdin files.
> Comments?
> All the best
> Ross
>> -----Original Message-----
>> From: [mailto:amber-developers-
>>] On Behalf Of Robert Duke
>> Sent: Tuesday, January 06, 2009 3:14 PM
>> To: AMBER Developers Mailing List
>> Subject: Re: [AMBER-Developers] inconsistency in sander manual and code
>> forrestart velocities
>> I would guess you would want to fix the doc, and leave the code such that
>> the behaviour is consistent with the past. This stuff has driven me
>> crazy
>> too, and I tracked down what really happens in sander once, and found I
>> could completely eliminate the init variable to disambiguate the code.
>> Now,
>> I BELIEVE that pmemd does exactly what sander does, and it may represent
>> a
>> more clear code source for figuring out what happens. There is code in
>> pmemd that insures that if ntx 1 or 2, then irest = 0, but not the other
>> way
>> around. Also, I believe, based on code inspection in pmemd, that if ntx
>> 1
>> or 2, if there is box info, WITH or WITHOUT velocities, it will be read.
>> Then all that irest 0 causes is that preamble 0 step in runmd(). So I
>> think
>> you have to get ntx 1 or 2, irest 0 to do what you want (and irest 0 is
>> default, ntx 1 default, so if you had 'said nothing', it would do what
>> you
>> want...). Every time you create an interface, you have to live with it
>> forever...
>> Regards - Bob
>> ----- Original Message -----
>> From: "Carlos Simmerling" <>
>> To: "Amber Developers Mailing List" <>
>> Sent: Tuesday, January 06, 2009 4:58 PM
>> Subject: [AMBER-Developers] inconsistency in sander manual and code
>> forrestart velocities
>> > hi all- I've been tracking down a bug in sander for amber9/10 and know
>> > that one exists, but it's hard to say if it's in the manual or the
>> > code.
>> > I just want some quick feedback since there could be several ways to
>> "fix"
>> > it.
>> > it's related to all of the overly complicated combinations of irest,
>> > ntx, tempi and init.
>> >
>> > my understanding, along with page 26 of the amber10 manual, is that
>> > for a PBC system, if one wants to restart with box info from inpcrd
>> > (say from a constant pressure run), then one should use ntx=5.
>> >
>> > from the manual:
>> > ntx = 5 X and V are read formatted; box information will be read if
>> > ntb>0. The velocity information
>> > will only be used if irest=1.
>> >
>> > it's the last part that's wrong. if I set ntx=5 to read the box, but
>> > irest=0 so that my velocities are assigned by sander, setvel() is
>> > still not called in sander.f (it is only called if ntx <=3). this
>> > means the run is the same no matter what the random seed is. also,
>> > init is passed to setvel but never used.
>> >
>> > irest is indeed used, in mdread2(), to set the value of init:
>> >
>> > init = 3
>> > if (irest > 0) init = 4
>> >
>> > the problem is that init isn't used for anything related to setting
>> > velocities, but it is used in runmd to do the setup if it's not a
>> > restart..
>> >
>> > I got burned on this by starting a large # of runs from the same
>> > structure with different ig values, thinking I would get different
>> > runs. all were identical (with ntt=1, with ntt=3 they would not be
>> > because the ig value would change the thermostat, but I still don't
>> > think that's what we want).
>> >
>> > SO, I think the problem is that we use ntx for deciding on calling
>> > setvel, but we really should use ntx for reading them, and irest for
>> > calling setvel (or init- this is really confusing since they map to
>> > different values). alternately, the setvel call could be moved into
>> > the init=3 part of runmd, though I haven't thought much about whether
>> > there is a reason it isn't there already.
>> >
>> > either that or we change the manual to say that any time we read
>> > velocities we will use them (but then can we still read the box? it
>> > appears that getcor() doesn't ever read the box for formatted files,
>> > but does so for unformatted! so it's unclear to me right now if we
>> > reliably read the box info for ntx=1 PBC restarts).
>> >
>> > I could fix it but want to make sure I know our "intent" before making
>> > changes or a bugfix. my suggestion is to fix the code, but it might
>> > break old inputs. still, given the issues lately with needing to set
>> > different ig values, we should allow users to actually do it the way
>> > that the manual has been describing!
>> >
>> > carlos
>> >
>> > _______________________________________________
>> > AMBER-Developers mailing list
>> >
>> >
>> >
>> _______________________________________________
>> AMBER-Developers mailing list
> _______________________________________________
> AMBER-Developers mailing list

AMBER-Developers mailing list
Received on Fri Jan 09 2009 - 01:11:31 PST
Custom Search