AMBER Archive (2009)

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

From: Astrid Maaß (astrid.maass_at_scai.fraunhofer.de)
Date: Mon Mar 09 2009 - 08:27:30 CDT

Dear Ross, dear all,

some time ago I had a maybe related problem with tleap in combination
with gaff (extra torsion terms in top-file, possibly inherited from a
wildcard parameter set visited before; original text below). I really
do appreciate the ease in getting started simulations with any generic
organic compound via antechamber and gaff, but the general amber force
field comes with roughly 10 times the number of wildcard entries than
parm99.dat, no hope for me to fix those manually. Could you comment or
suggest how to proceed best?

Many thanks in advance & best regards
  Astri dMaaß

My original problem was this:
I am interested in understanding torsion rotations and for my test
compound ethanediol I noticed that in the topology file created by tleap
the oh-c3-c3-h1 torsions are differently assigned despite their chemical
equivalence.

In detail, I am using a prep file created by antechamber and using GAFF
to model the molecule (via AmberTools 1.2 with applied bugfixes.all from
the date of yesterday). Tleap does the processing without any
complaints. In the topology file the first two times that the
oh-c3-c3-h1 patterns show up, the force constant, periodicity and phase
shift exactly correspond to the entry in gaff.dat - i.e. 0.25 kcal/mol,
0 and 1. The third and fourth time however, the torsion is described not
only by the above parameters, but also by additional numbers: 0.1555
kcal/mol, 0 and 3.

I suspect these values were somehow inherited from the torsion visited
immediately before (H-C1-C2-H5), which were taken from a wildcard entry
in gaff.dat (X -c3-c3-X). When modifying gaff.dat by adding a single
line that provides the required pattern of atom types explicitly
(h1-c3-c3-h1) with the same numbers as the wildcart entry, the topology
file happens not to show the extra torsional terms.

Ross Walker wrote:
> 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