Re: amber-developers: Question concerning wildcards in dihedral definitions.

From: David A. Case <case.scripps.edu>
Date: Tue, 28 Jun 2005 16:26:48 -0700

On Tue, Jun 28, 2005, Guanglei Cui wrote:
>
> I just want to add something related to what Ross is seeing here. I
> created a topology file for methylmonophosphate with gaff with a
> recalculated dihedral profile for dihedral type X -os-p5-X . The
> definition in gaff.dat for this term is,
>
> 3 2.400(pk) 0.00(phase) 2.0(pn)
>
> First, it's not clear to me why the periodicity is 2 here. I decide to
> overwrite the gaff definition with my own parameters (defined in frcmod
> as X -os-p5-X ). But what I found in the resulted pmftop (see
> attachement), this term was defined twice, one with the gaff term and
> another with my parameters. But this didn't seem to affect anything.
> This topology file (mmp.new.top) gave a good match with the enery
> profile calculated with QM, so I assume my definition was used. But it's

> confusing though.

You can reduce the confusion by using the rdparm program to print out
things explicitly. For your topologies:

-------------------------------------------------------------------------- 
--
quine% rdparm mmp.gaff.top
RDPARM MENU:  printdihedrals
Dihedral    pk     phase pn                atoms
       1:   0.383  0.00  3.0    :1.H1   :1.C1   :1.O1   :1.P1   (2,1,5,9)
       2:   0.383  0.00  3.0    :1.H2   :1.C1   :1.O1   :1.P1   (3,1,5,9)
       3:   0.383  0.00  3.0    :1.H3   :1.C1   :1.O1   :1.P1   (4,1,5,9)
       4:   0.800  0.00  2.0    :1.C1   :1.O1   :1.P1   :1.O2   (1,5,9,6)
       5:   0.800  0.00  2.0    :1.C1   :1.O1   :1.P1   :1.O3   (1,5,9,7)
       6:   0.800  0.00  2.0    :1.C1   :1.O1   :1.P1   :1.O4   (1,5,9,8)
--------------------------------------------------------------------------
--
quine% rdparm mmp.new.top
RDPARM MENU:  printdihedrals
Dihedral    pk     phase pn                atoms
       1:   0.383  0.00  3.0    :1.H1   :1.C1   :1.O1   :1.P1   (2,1,5,9)
       2:   0.383  0.00  3.0    :1.H2   :1.C1   :1.O1   :1.P1   (3,1,5,9)
       3:   0.383  0.00  3.0    :1.H3   :1.C1   :1.O1   :1.P1   (4,1,5,9)
       4:   0.800  0.00  2.0    :1.C1   :1.O1   :1.P1   :1.O2   (1,5,9,6)
E      5:  -0.143  3.14  3.0    :1.C1   :1.O1   :1.P1   :1.O2   (1,5,9,6)
       6:   0.800  0.00  2.0    :1.C1   :1.O1   :1.P1   :1.O3   (1,5,9,7)
E      7:  -0.143  3.14  3.0    :1.C1   :1.O1   :1.P1   :1.O3   (1,5,9,7)
       8:   0.800  0.00  2.0    :1.C1   :1.O1   :1.P1   :1.O4   (1,5,9,8)
E      9:  -0.143  3.14  3.0    :1.C1   :1.O1   :1.P1   :1.O4   (1,5,9,8)
--------------------------------------------------------------------------
--
If you add (via frcmod) a torsion that has a *different pn* than the one
in
the standard gaff.dat file, your torsion will be added to the torsion in
the
standard force field.  This is what you see above: the "mmp.new.top" has
both
the original 2-fold gaff term and your added 3-fold term.
On the other hand, if the frcmod torsion exactly matches both the atoms
and
the pn of the original file, then your term would overwrite the original
one.
Hence if you wanted to remove the original 2-fold term and add your 3-fold
term, your frcmod file would have to have a 2-fold term with 0.0 for pk
(to
effectively remove this term), and a 3-fold term (to add in what you
want).
Your message says "this didn't seem to affect anything"; I'm not sure what
you
mean there: your "new" topology file definitely seems to still have the
2-fold
torsion term.  Try adding a 2-fold term with zero pk value in your frcmod
file
to see what happens.
[Incidentally, it is very unusual to have a 3-fold term with a phase of
pi,
and with a negative pk!  Are you sure this is what you want?]
The rules for replacing torsions listed above make sense to me, and I
think(?)
they are correctly implemented in LEaP.  The problems seem to arise from
a similar question about whether a specific torsion should override a
wild-card torsion or not.  Here, it currently looks like LEaP does not do
such
comparisons in a consistent fashion (cf. recent posting by Ross Walker.)
...dac
Received on Wed Apr 05 2006 - 23:49:55 PDT
Custom Search