AMBER Archive (2009)

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

From: Wei Zhang (zgjzweig_at_gmail.com)
Date: Mon Mar 09 2009 - 09:38:56 CDT


Hi All,

     I checked the code of xleap/tleap, and I suspect that the
following function:

              zParmSetAddToTorsion() which is in file amber10/src/
leap/src/leap/parmSet.c

has some problem, because in the comments, it clearly states that

/*
  *
  *TODO: Fix this routine, it will not properly compare proper torsions
  *TODO: with wild cards.
  */

    I can dig into this some more, but it is going to take some time.
Meanwhile, I sincerely
hope people to start using sleap, which at least I know very well, and
can make changes
very easily.

     Sincerely,

     Wei

On Mar 9, 2009, at 8:27 AM, Astrid Maaß wrote:

> 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

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