Hi Brent,
My understanding of this, at least in terms of explicit torsion types
(rather than wild cards) is that all lines containing the torsion with
different values of periodicity would be included regardless of their
position in the parameter file.
I.e. in your example this should give you a prmtop file with 4 torsion
values listed for the single dihedral type. The 1,2,3 and additional 4 fold
term. I believe that the position and ordering in the file is irrelevant as
is the use of -ve values for the periodicity.
I believe that if you have two identical torsions specified with the same
periodicity then the last term read would be used and it would overwrite the
previous torsion of the same periodicity - although really here I think that
this situation should quit with an error claiming that this torsion has
already been defined.
In essence you can think of a torsion term being uniquely defined as the 4
atoms making it up + the periodicity.
In the case of wild cards and loading of frcmod files this is where it gets
tricky. Perhaps others can comment more here on what the official behavior
should be but my understanding right now is that if it is in the parmxx.dat
file then wild cards are read and then any explicit fully defined torsions
that have the same periodicity as the wild card override that wildcard
value.
I.e. X-CT-CT-X 6 3.0 180.0 2.
would get overridden by HC-CT-CT-HC 1 2.0 180.0 2. in the case of just
HC-CT-CT-HC. However, any 1, 3 or 4 fold terms would be unaffected by this.
Additionally the ordering in the file does not matter so even if the wild
card comes after the explicit definition if they have the same periodicity
then the explicit definition trumps the wild card.
In the case of frcmod files read with 'readamberparams' then the behavior is
slightly different (I think). In this case any specification of an explicit
dihedral in the frcmod file overrides all wild cards that match that
dihedral even if they have different periodicities. I.e. the term in the
frcmod file effectively deletes all other torsion entries that match that
torsion type. However, while I believe this applies to wildcards I'm not
sure what the behavior should be for explicit torsions in the parm file and
an frcmod file. I guess I could try it and see but my standard approach is
to make sure I define all the periodicities that might be in the parm file
in the frcmod file to be certain I override everything including explicit
torsions in the frcmod file.
This is why the frcmod.ff99SB file defines all dihedrals from periodicity 1
through 4 even though some of them have zero barrier height. E.g.
C -N -CT-C 1 0.00 0.0 -4. four amplitudes
and
C -N -CT-C 1 0.42 0.0 -3. phases for phi
C -N -CT-C 1 0.27 0.0 -2.
C -N -CT-C 1 0.00 0.0 1.
I hope this makes sense - perhaps someone (Dave Case perhaps) knows what the
definitive answer should be here.
All the best
Ross
> -----Original Message-----
> From: amber-bounces.ambermd.org [mailto:amber-bounces.ambermd.org] On
> Behalf Of Gregersen, Brent
> Sent: Friday, March 06, 2009 6:15 PM
> To: AMBER Mailing List
> Subject: RE: [AMBER] Help with torsions in parm99.dat file
>
> 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.ambermd.org [mailto:amber-bounces.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.HH33 :1.CH3 :1.C :1.O
> (4,2,5,6)
> E 7: 0.000 0.00 2.0 :1.HH33 :1.CH3 :1.C :1.O
> (4,2,5,6)
> E 8: 0.080 3.14 3.0 :1.HH33 :1.CH3 :1.C :1.O
> (4,2,5,6)
> ...
> 10: 0.800 0.00 1.0 :1.HH32 :1.CH3 :1.C :1.O
> (3,2,5,6)
> E 11: 0.000 0.00 2.0 :1.HH32 :1.CH3 :1.C :1.O
> (3,2,5,6)
> E 12: 0.080 3.14 3.0 :1.HH32 :1.CH3 :1.C :1.O
> (3,2,5,6)
> ...
> 15: 0.800 0.00 1.0 :1.HH31 :1.CH3 :1.C :1.O
> (1,2,5,6)
> E 16: 0.000 0.00 2.0 :1.HH31 :1.CH3 :1.C :1.O
> (1,2,5,6)
> E 17: 0.080 3.14 3.0 :1.HH31 :1.CH3 :1.C :1.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.HH33 :1.CH3 :1.C :1.O
> (4,2,5,6)
> E 7: 0.000 0.00 2.0 :1.HH33 :1.CH3 :1.C :1.O
> (4,2,5,6)
> E 8: 0.080 3.14 3.0 :1.HH33 :1.CH3 :1.C :1.O
> (4,2,5,6)
> ...
> 10: 0.800 0.00 1.0 :1.HH32 :1.CH3 :1.C :1.O
> (3,2,5,6)
> E 11: 0.000 0.00 2.0 :1.HH32 :1.CH3 :1.C :1.O
> (3,2,5,6)
> E 12: 0.080 3.14 3.0 :1.HH32 :1.CH3 :1.C :1.O
> (3,2,5,6)
> ...
> 15: 0.800 0.00 1.0 :1.HH31 :1.CH3 :1.C :1.O
> (1,2,5,6)
> E 16: 0.000 0.00 2.0 :1.HH31 :1.CH3 :1.C :1.O
> (1,2,5,6)
> E 17: 0.080 3.14 3.0 :1.HH31 :1.CH3 :1.C :1.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.HH33 :1.CH3 :1.C :1.O
> (4,2,5,6)
> E 7: 0.080 3.14 3.0 :1.HH33 :1.CH3 :1.C :1.O
> (4,2,5,6)
> ...
> 9: 0.800 0.00 1.0 :1.HH32 :1.CH3 :1.C :1.O
> (3,2,5,6)
> E 10: 0.000 0.00 2.0 :1.HH32 :1.CH3 :1.C :1.O
> (3,2,5,6)
> E 11: 0.080 3.14 3.0 :1.HH32 :1.CH3 :1.C :1.O
> (3,2,5,6)
> ...
> 14: 0.800 0.00 1.0 :1.HH31 :1.CH3 :1.C :1.O
> (1,2,5,6)
> E 15: 0.000 0.00 2.0 :1.HH31 :1.CH3 :1.C :1.O
> (1,2,5,6)
> E 16: 0.080 3.14 3.0 :1.HH31 :1.CH3 :1.C :1.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.ambermd.org [mailto:amber-bounces.ambermd.org] On
> > Behalf Of Gregersen, Brent
> > Sent: Friday, March 06, 2009 2:44 PM
> > To: amber.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.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber
>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Sun Mar 08 2009 - 01:15:21 PST
