Update: AMBER 11 sander has had nscm hard coded to 0 with ntr=1 like Dave
suggests but AMBER 10 (which is what I was using) does not do this and
merrily runs ntt=3, ntr=1 with the default nscm value of 1000. Doh!!!
Note with gamma_ln > 1.0 this does not show up as an obvious problem, except
that it is still wrong, but as you reduce gamma_ln below 1.0 the system
becomes less and less stable due to this bug.
All the best
Ross
> -----Original Message-----
> From: amber-developers-bounces.ambermd.org [mailto:amber-developers-
> bounces.ambermd.org] On Behalf Of Ross Walker
> Sent: Tuesday, July 07, 2009 3:11 PM
> To: 'AMBER Developers Mailing List'
> Subject: RE: [AMBER-Developers] Possible bug with ntt=3 and ntr=1 -
> Possible Fix 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:37 PDT
