Hi Ross,
In regard to all this stuff, pmemd 10 just replicates sander 10. So if you
guys have a bug, I have a bug, and whatever fix you apply for 11, it should
move over into pmemd. I have not been working in the pmemd tree for a
while, so feel free to just do what is needed. I think this stuff is
outside any areas critical to performance. I think my response is pretty
obvious, but you said you were looking for comments from me...
- Bob
----- Original Message -----
From: "Ross Walker" <ross.rosswalker.co.uk>
To: "'AMBER Developers Mailing List'" <amber-developers.ambermd.org>
Sent: Tuesday, July 07, 2009 6:11 PM
Subject: RE: [AMBER-Developers] Possible bug with ntt=3 and ntr=1 -
PossibleFix for PMEMD.
> Hi All,
>
> So it looks like nscm is getting set to 1000 both in sander and pmemd
> regardless of the value of ntr. I have not tracked this down yet although
> note that PMEMD does not have any code for setting nscm=0 when ntr=1. It
> just fails to work properly. However, I believe I have fixed the problem
> and
> I would appreciate comments - Bob's in particular and then I will fix
> sander
> as well and remove the restriction of nscm=0 with ntr=1.
>
> Currently in PMEMD (and equivalently the same in Sander) the call to
> re_position (in runmd.fpp) is:
>
> call re_position(atm_cnt, 0, crd, crd, vcm(1), vcm(2), vcm(3), &
> sys_x, sys_y, sys_z, sys_range, 0)
>
> subroutine re_position(n, ntr, x, xr, xc, yc, zc, x0, y0, z0, vec,
> verbose)
>
> So ntr is hard wired to 0 and additionally x and xr are the same
> coordinate
> arrays!
>
> Inside re_position we have:
>
> if (ntr .gt. 0) then
> do i = 1, n
> xr(1,i) = xd + xr(1,i)
> xr(2,i) = yd + xr(2,i)
> xr(3,i) = zd + xr(3,i)
> end do
> end if
>
> Which looks good except ntr is hard wired to 0. Changing the 0 in the call
> to ntr does not fix it because xr is crd here due to the double reference
> to
> crd in the call so you end up just moving the coordinates twice which
> makes
> the problem even worse. Thus I believe that the second crd reference (that
> becomes xr in the re_position routine) should actually be the reference
> coordinates. Thus the call should be:
>
> call re_position(atm_cnt, ntr, crd, atm_xc, vcm(1), vcm(2),
> vcm(3),
> &
> sys_x, sys_y, sys_z, sys_range, 0)
>
> This seems to run the nucleosome run nice and stable with the behavior I
> expect. Anyone got any comments? Does anybody know the history of why this
> was set this 'incorrect?' way in the first place? If not I'll fix PMEMD
> and
> sander (remove the ntr=1 requires nscm=0 code) and put a bugfix on the
> website.
>
> All the best
> Ross
>
>> -----Original Message-----
>> From: amber-developers-bounces.ambermd.org [mailto:amber-developers-
>> bounces.ambermd.org] On Behalf Of case
>> Sent: Tuesday, July 07, 2009 5:54 AM
>> To: AMBER Developers Mailing List
>> Subject: Re: [AMBER-Developers] Possible bug with ntt=3 and ntr=1
>>
>> On Mon, Jul 06, 2009, Ross Walker wrote:
>> >
>> > I am trying to track down what I think is a bug with GB runs where
>> ntt=3 and
>> > harmonic restraints (ntr=1) are in use.
>> >
>> > Interestingly everything looks good until NSCM is triggered at step
>> 1000.
>>
>> This is weird, since NSCM is supposed to be turned off when ntr=1, see
>> line
>> 848 of mdread.f:
>>
>> if (ntr.eq.1) &
>> nscm = 0
>>
>> and later, at line 865:
>>
>> if(nscm <= 0) nscm = 999999999
>>
>> So, what value is printed for ncsm in the output? The clear intent,
>> which I
>> think is correct, is to turn off re-positioning and com removal when
>> ntr=1.
>> So, we need to figure out why this is not happening.
>>
>> ...dac
>>
>>
>> _______________________________________________
>> 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 Tue Jul 07 2009 - 18:09:55 PDT
