AMBER Archive (2009)

Subject: RE: [AMBER] Help with torsions in parm99.dat file

From: Gregersen, Brent (Brent.Gregersen_at_DEShawResearch.com)
Date: Fri Mar 06 2009 - 20:15:11 CST

Thanks for the explanation and clarification Ross.

I agree that the behaviour wildcards and how parameters augment and/or
overide each other in forcefield files can be very ambigous. While Im
posting, I may as well ask one additional clarification.

What is the expected behaviour if a different "HC-CT-C-O" term say
"HC-CT-C-O 1 0.100 0.0 4." is placed at the end of the parm99.dat
file? Does it replace all of the explicit parameters previously defined
for that type, does it augment the explict parameters listed earlier in
the file or is it an error to have another term listed that's not on
successive lines. On one hand, there is "its whatever leap does",
however, I think my expectation would be that its either an error or
that the earlier set of parameters would be replaced by the single term
at the end of the file.

Brent

-----Original Message-----
From: amber-bounces_at_ambermd.org [mailto:amber-bounces_at_ambermd.org] On
Behalf Of Ross Walker
Sent: Friday, March 06, 2009 7:52 PM
To: 'AMBER Mailing List'
Cc: 'Wei Zhang'
Subject: RE: [AMBER] Help with torsions in parm99.dat file

Hi Brent,

This was apparently added by me to the AMBER 9 CVS tree on July 27th
2005 and was thus released as part of AMBER 9 and subsequently
ambertools. Here is the log message from the tree:

revision 8.2
date: 2005/07/27 19:25:40; author: rcw; state: Exp; lines: +1 -0
RCW: Explicitly added HC-CT-C-O 0.0 0.0 2.0 term which explicitly
defines one of the options of the X-C-CT-X term. Xleap misbehaves here
for NMA and only gets two of the three HC's. So you get a total of 24
dihedrals for NMA when there should be 25. This fixes that but means
that there is still an underlying problem with xleap and wildcards even
for proteins. While this fix doesn't affect the energies as is if the
barrier height was changed to something other than 0.0 (e.g. by fitting)
then we would have a big problem without this term being explicitly
defined.

I came across this while writing code that would adjust the barrier
heights while trying to automatically fit the force field to underlying
quantum data. The issue, I believe was that Xleap wasn't handling the
wildcard terms correctly. This was to force leap to ignore the wildcard
term here.

I agree that it probably should have -2.0 specified in that it should
run, for pn -1.0, -2.0, 3.0, however the specification of the minus sign
in the parm99.dat file is a left over from the days of prep, link, edit
and parm.
Leap does not, as far as I can tell, interpret the minus sign in the
parm file and instead deals with duplicate dihedrals internally by
running over the bond list. I should probably update the parm99.dat file
for the next release of ambertools to just be consistent though.

I checked the following options with the current development version of
xleap (which should be similar to the AmberTools 1.2 version):

1) parm99.dat file as released in AMBER 10

source leaprc.ff99SB
mol = sequence { ACE NME }
saveamberparm mol prmtop inpcrd

rdparm prmtop
printdihedrals

This gives:

...
       6: 0.800 0.00 1.0 :1_at_HH33 :1_at_CH3 :1_at_C :1_at_O
(4,2,5,6)
E 7: 0.000 0.00 2.0 :1_at_HH33 :1_at_CH3 :1_at_C :1_at_O
(4,2,5,6)
E 8: 0.080 3.14 3.0 :1_at_HH33 :1_at_CH3 :1_at_C :1_at_O
(4,2,5,6)
...
      10: 0.800 0.00 1.0 :1_at_HH32 :1_at_CH3 :1_at_C :1_at_O
(3,2,5,6)
E 11: 0.000 0.00 2.0 :1_at_HH32 :1_at_CH3 :1_at_C :1_at_O
(3,2,5,6)
E 12: 0.080 3.14 3.0 :1_at_HH32 :1_at_CH3 :1_at_C :1_at_O
(3,2,5,6)
...
      15: 0.800 0.00 1.0 :1_at_HH31 :1_at_CH3 :1_at_C :1_at_O
(1,2,5,6)
E 16: 0.000 0.00 2.0 :1_at_HH31 :1_at_CH3 :1_at_C :1_at_O
(1,2,5,6)
E 17: 0.080 3.14 3.0 :1_at_HH31 :1_at_CH3 :1_at_C :1_at_O
(1,2,5,6)
...
Total = 25 torsions

Replacing the 3 lines in the parm file with:

HC-CT-C -O 1 0.80 0.0 -1. Junmei et
al,
1999
HC-CT-C -O 1 0.00 0.0 -2. Explicit of
wild
card X-C-CT-X
HC-CT-C -O 1 0.08 180.0 3. Junmei et
al,
1999

And repeating the above gives:

...
       6: 0.800 0.00 1.0 :1_at_HH33 :1_at_CH3 :1_at_C :1_at_O
(4,2,5,6)
E 7: 0.000 0.00 2.0 :1_at_HH33 :1_at_CH3 :1_at_C :1_at_O
(4,2,5,6)
E 8: 0.080 3.14 3.0 :1_at_HH33 :1_at_CH3 :1_at_C :1_at_O
(4,2,5,6)
...
      10: 0.800 0.00 1.0 :1_at_HH32 :1_at_CH3 :1_at_C :1_at_O
(3,2,5,6)
E 11: 0.000 0.00 2.0 :1_at_HH32 :1_at_CH3 :1_at_C :1_at_O
(3,2,5,6)
E 12: 0.080 3.14 3.0 :1_at_HH32 :1_at_CH3 :1_at_C :1_at_O
(3,2,5,6)
...
      15: 0.800 0.00 1.0 :1_at_HH31 :1_at_CH3 :1_at_C :1_at_O
(1,2,5,6)
E 16: 0.000 0.00 2.0 :1_at_HH31 :1_at_CH3 :1_at_C :1_at_O
(1,2,5,6)
E 17: 0.080 3.14 3.0 :1_at_HH31 :1_at_CH3 :1_at_C :1_at_O
(1,2,5,6)
...
Total = 25 torsions

Which is the same thing implying that leap doesn't care about the minus
signs on the periodicity.

Repeating this again but with the following:

HC-CT-C -O 1 0.80 0.0 -1. Junmei et
al,
1999
HC-CT-C -O 1 0.08 180.0 3. Junmei et
al,
1999

Such that the wild card:

X -C -CT-X 6 0.00 0.0 2.
JCC,7,(1986),230

gets included and then the prmtop that leap spits out is:

...
       6: 0.800 0.00 1.0 :1_at_HH33 :1_at_CH3 :1_at_C :1_at_O
(4,2,5,6)
E 7: 0.080 3.14 3.0 :1_at_HH33 :1_at_CH3 :1_at_C :1_at_O
(4,2,5,6)
...
       9: 0.800 0.00 1.0 :1_at_HH32 :1_at_CH3 :1_at_C :1_at_O
(3,2,5,6)
E 10: 0.000 0.00 2.0 :1_at_HH32 :1_at_CH3 :1_at_C :1_at_O
(3,2,5,6)
E 11: 0.080 3.14 3.0 :1_at_HH32 :1_at_CH3 :1_at_C :1_at_O
(3,2,5,6)
...
      14: 0.800 0.00 1.0 :1_at_HH31 :1_at_CH3 :1_at_C :1_at_O
(1,2,5,6)
E 15: 0.000 0.00 2.0 :1_at_HH31 :1_at_CH3 :1_at_C :1_at_O
(1,2,5,6)
E 16: 0.080 3.14 3.0 :1_at_HH31 :1_at_CH3 :1_at_C :1_at_O
(1,2,5,6)
...
Total = 24 torsions...

So an interesting bug that doesn't seem to have ever been identified or
fixed - perhaps Wei can take a look at this and comment.

Personally my opinion is that there should be no wildcards in the force
field files. They are too ambiguous. As it stands though this bug is
innocuous but only because the wildcard barrier height is zero.

My introduction of the explicit value for HC-CT-C-O was to override this
torsion (and side step this bug) such that I could do some fitting
whereby I varied the barrier height for this torsion.

In the meantime I'll update the parm99.dat file for the next release so
the use of -ve periodicities is at least consistent.

All the best
Ross

> -----Original Message-----
> From: amber-bounces_at_ambermd.org [mailto:amber-bounces_at_ambermd.org] On
> Behalf Of Gregersen, Brent
> Sent: Friday, March 06, 2009 2:44 PM
> To: amber_at_ambermd.org
> Subject: [AMBER] Help with torsions in parm99.dat file
>
> Can anyone comment on the following torsion parameters (found in
> parm99.dat in at least amber 8-10):
>
> HC-CT-C -O 1 0.80 0.0 -1. Junmei et
> al, 1999
> HC-CT-C -O 1 0.08 180.0 3. Junmei et
> al, 1999
> HC-CT-C -O 1 0.00 0.0 2. Explicit
of
> wild card X-C-CT-X
>
> The question I have regards the last line. Is it intended that this
> parameter overwrites the previous two? Or should it be included with
> the two above parameters (in which case the "3" should be "-3"). Also,

> why is it even necessary to list an explicit parameter of zero when a
> torsion for the 4 atom types already exists?
>
> I believe leap just ignores this parameter (or includes it with the
> previous two torsions), but from the documentation on the param.dat
> files http://ambermd.org/formats.html#parm.dat its not clear what the
> behaviour should be in this case.
>
> Thanks,
> Brent
>
> _______________________________________________
> AMBER mailing list
> AMBER_at_ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber

_______________________________________________
AMBER mailing list
AMBER_at_ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber

_______________________________________________
AMBER mailing list
AMBER_at_ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber