Thanks for your insights, Jason.
Please correct me if I am wrong, but I think the main definition of a
restart simulation (irest=1) exactly is that initial velocities are
taken from an input file and never ever get generated randomly. As a
consequence, an important shared property of all other simulations
(irest=0) should be that initial velocities are *always* assigned randomly.
If this argumentation is correct, irest=0 must ensure that old
velocities, if provided, are not used, independent on other parameters.
If there is an ambiguity, some collision with any other parameter, an
error must be printed and the program must quit.
Hence, I vote for the irest behavior being implemented as currently
documented in the AT12 manual. All the irest/ntx combinations should be
checked for consistency.
Jan-Philip
On 07/04/2012 08:52 PM, Jason Swails wrote:
> So a little update here. I agree that in both sander and pmemd random
> velocities are only assigned if ntx is 1 or 2 (there is nothing about
> irest). In my opinion this is unexpected behavior. As I recall, there was
> a discussion on the developer list when I was trying to set smarter
> defaults (e.g., NTB is now set to 0 by default when igb != 0, 1 when igb==0
> and ntp==0, and 2 when ntp != 0, so that it effectively never needs to be
> set by hand, and CUT is 8 for periodic simulations and 999 for non-periodic
> simulations).
>
> I proposed setting irest=1 when ntx=5/7 (and irest=0 when ntx=1/2) since
> those two went together, but it was shot down when someone pointed out that
> velocities *could be* in the inpcrd file even if you don't want to use
> them, and so that combo made sense sometimes. Rightfully so, in which
> case, I assumed that was the behavior and so documented it in the manual.
>
> Checking the code just now, the velocity setting routine is only called if
> ntx < 3 -- it has nothing at all to do with irest. I have a simple patch
> that fixes the behavior to reflect what the manual dictates. I'll let some
> of the more experienced developers weigh in here on what they think should
> be done (i.e., retain the behavior we've had forever and publish a manual
> errata or switch to the behavior that the new manual v. 12 claims).
>
> After looking through the code a little, I'm quite sure that setting ntx=1
> will get the behavior you want...
>
> HTH,
> Jason
>
> On Wed, Jul 4, 2012 at 12:55 PM, Jan-Philip Gehrcke <jgehrcke.googlemail.com
>> wrote:
>
>> On 07/04/2012 06:46 PM, Jan-Philip Gehrcke wrote:
>>> Jason,
>>>
>>> do you think that it is fine to read an MD restart file (containing
>>> coordinates, velocities and periodic box information) with ntx=1 if one
>>> is only interested in coordinates and box information? As I said, I did
>>> exactly this and the first 5 frames of the subsequent simulation looked
>>> good to me. Did I just lose the periodic boundary conditions by doing so
>>> (of course I have set ntb=1 also in the subsequent simulation)?
>>>
>>
>> In order to make it easier to answer this, I provide here the
>> corresponding part of the mdout file:
>>
>>
>>> &cntrl
>>> ntx = 1,
>>> irest = 0,
>>> ntb = 1,
>>> cut = 8.0,
>>> ntc = 2,
>>> ntf = 2,
>>> tempi = 300.0,
>>> temp0 = 300.0,
>>> ntt = 1,
>>> tautp = 10.0,
>>> nstlim = 2000000,
>>> dt = 0.002,
>>> ntpr = 500, ntwx = 500, ntwr = 10000,
>>> ioutfm = 1,
>>> ig = -1,
>>> jar = 1,
>>> /
>> [...]
>>>
>>>
>> --------------------------------------------------------------------------------
>>> 1. RESOURCE USE:
>>>
>> --------------------------------------------------------------------------------
>>>
>>> | Flags: MPI
>>> getting new box info from bottom of inpcrd
>>> | INFO: Old style inpcrd file read
>>>
>>> | peek_ewald_inpcrd: Box info found
>>> |Largest sphere to fit in unit cell has radius = 33.405
>>> | New format PARM file being parsed.
>>
>> "getting new box info from bottom of inpcrd" and "peek_ewald_inpcrd: Box
>> info found" are promising, right? Looks like the box info has been read
>> although ntx is 1 and not 5.
>>
>>
>>
>>> And, yes, with irest=0 velocities _should_ be ignored, as explicitly
>>> stated in the Amber 12 manual. But this is not formulated in the Amber
>>> 11 manual. There, however, for ntx=5 it is noted "The velocity
>>> information will only be used if irest=1." which should be clear enough.
>>>
>>> I started two equivalent simulations with ntx=5 and irest=0 (and ig=-1,
>>> tempi=300) from the same restart file and _all_ statistics (energy
>>> values) in both mdout files were exactly the same up the step 3000, when
>>> I aborted the test. If velocities had been assigned randomly, the
>>> numbers should have differed already after the first step, right?
>>>
>>> Jan-Philip
>>>
>>>
>>> On 07/04/2012 06:28 PM, Jason Swails wrote:
>>>> If irest=0, no velocities should be used (even if ntx=5). I think you
>>>> need
>>>> to use ntx=5 so sander/pmemd knows that velocities are present (if
>>>> there is
>>>> periodic box information). If this is not the case, I think this
>>>> probably
>>>> needs to be fixed...
>>>>
>>>> All the best,
>>>> Jason
>>>>
>>>> On Wed, Jul 4, 2012 at 11:33 AM, Jan-Philip Gehrcke
>>>> <jgehrcke.googlemail.com
>>>>> wrote:
>>>>
>>>>> Hey,
>>>>>
>>>>> I am using sander from Amber 11 and read coordinates and velocities
>> from
>>>>> an MD restart file via ntx=5. However, I want to generate new
>>>>> velocities, i.e. not use the velocities from the restart file. So I set
>>>>> irest=0, ig=-1, tempi=300. But it seems like the velocities from the
>>>>> restart file are not overridden by randomly generated ones. In this
>>>>> case, I had to use ntx=1 (which seems to also work with restart files
>>>>> and not only with plain coordinate files).
>>>>>
>>>>> Is it new in Amber 12 that irest=0 leads to velocities from an MD
>>>>> restart file being ignored? The Amber 12 manual says for this setting
>>>>> "Velocities in the input coordinate file, if any, will be ignored".
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jan-Philip Gehrcke
>>>>>
>>>>> _______________________________________________
>>>>> AMBER mailing list
>>>>> AMBER.ambermd.org
>>>>> http://lists.ambermd.org/mailman/listinfo/amber
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> AMBER mailing list
>> AMBER.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber
>>
>
>
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Jul 05 2012 - 05:30:03 PDT
