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

From: Carlos Simmerling <carlos.simmerling.gmail.com>
Date: Wed, 7 Jan 2009 13:31:17 -0500

Hi Ross,

On Wed, Jan 7, 2009 at 12:25 PM, Ross Walker <ross.rosswalker.co.uk> wrote:
> 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.
>

maybe I wasn't clear- if ntx=5 and irest=0, the seed is set but not
used for velocities.
I'm not sure what you were thinking initially that would be worse...
not setting the seed for things other than velocities, like Langevin
or REMD?


> 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.

I agree, there's not much point to reading velocities that you won't
use, so users get confused easily.
if we don't need the velocities in order to read the box (which looks
like it depends on whether the restart is formatted or not), then
ntx=1 is the easy solution for not using velocities.
>
> Then if you want your own box sizes etc you need to specify the box values
> explicitly in the mdin file.

but for a restart nobody wants to do that- and are you sure they
override the ones in the restart (even with the PME peek stuff?)

>
> 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.
>

unless anyone has test cases or production runs that were broken
because of this.
carlos

> Comments?
>
> All the best
> Ross
>
>> -----Original Message-----
>> From: amber-developers-bounces.ambermd.org [mailto:amber-developers-
>> bounces.ambermd.org] 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" <carlos.simmerling.gmail.com>
>> To: "Amber Developers Mailing List" <amber-developers.ambermd.org>
>> 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.ambermd.org
>> > http://lists.ambermd.org/mailman/listinfo/amber-developers
>> >
>>
>>
>> _______________________________________________
>> AMBER-Developers mailing list
>> AMBER-Developers.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>

_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Fri Jan 09 2009 - 01:12:04 PST
Custom Search