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

From: Robert Duke <rduke.email.unc.edu>
Date: Tue, 6 Jan 2009 18:13:48 -0500

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
Received on Tue Jan 06 2009 - 15:34:22 PST
Custom Search