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
Received on Tue Jul 07 2009 - 18:09:31 PDT
