Hi Peter,
My 2c here which it seems the people who put together the ff99SBildn frcmod
file did not heed is that wildcards should NEVER be used in dihedrals. I
have actually been tempted to rip the support from the code entirely and
force people to update all their force field files to explicitly define
every dihedral combination. The problem is that it was never properly
documented what the behavior should be for wildcards. For example consider
the following (note the minus signs that people also do not use correctly
but Leap seems to just do the right thing):
CA-CA-CA-CA 1 5.0 180. -1 SCEE=1.2,SCNB=2.0
CA-CA-CA-CA 1 3.0 180. -2 SCEE=1.2,SCNB=2.0
CA-CA-CA-CA 1 1.0 180. 3 SCEE=1.2,SCNB=2.0
X-CA-CA- X 1 1.5 0. 1 SCEE=1.0,SCNB=1.0
What should happen here? - There are a couple of critical things that are
not well documented.
1) For anything like CT-CA-CA-CT there should be only 1 dihedral with
peridocity 1 and 1-4 scale factors of 1.0 and 1.0.
2) For CA-CA-CA-CA there should be 3 dihedrals and the corresponding 1-4
should have a scale factor of 1.2 and 2.0. However, since the wildcard came
last should it also override the 1 fold term for CA-CA-CA-CA? In my opinion
the answer should be NO. The order in which things are specified in the file
should have no bearing on the result. The entire file should be read and
then a consistent set of rules applied.
3) What then happens if there is an additional term:
X-CA-CA- X 1 1.7 0. 4 SCEE=1.0,SCNB=1.0
Should the CA-CA-CA-CA case also have this 4 fold term??? And what should
the 1-4 scale factor be for EEL and VDW? This is where it gets confusing and
is why I think wildcards should not be allowed. Particularly because, if I
remember correctly, the behavior of leap for terms in parmXX.dat files and
those in frcmod files is different.
This is why the FF99SB force field for example defines ALL dihedral
combinations that were changed including those that have zero barrier
heights.
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.
The 0.00 on the 1 and 4 fold terms are there to avoid any confusion from X -
N -CT -X terms that might exist in parm99.dat. This is the CORRECT way to do
things given the total lack of documented behavior.
In my opinion the rules should be as follows:
1) All dihedrals are passed and any wild card dihedrals are applied.
2) The files should be passed for any specific dihedrals and any specific
dihedral that occurs should result in ALL wildcards for that specific
dihedral being deleted and being replaced by the specific terms. In the
example shown above this means
CT-CA-CA-CT would have
X -CA-CA- X 1 1.5 0. 1 SCEE=1.0,SCNB=1.0
X -CA-CA- X 1 1.7 0. 4 SCEE=1.0,SCNB=1.0
and CA-CA-CA-CA would have:
CA-CA-CA-CA 1 5.0 180. -1 SCEE=1.2,SCNB=2.0
CA-CA-CA-CA 1 3.0 180. -2 SCEE=1.2,SCNB=2.0
CA-CA-CA-CA 1 1.0 180. 3 SCEE=1.2,SCNB=2.0
Note no 4 fold term for CA-CA-CA-CA.
In reality though I don't trust XYZ,S,G etc Leap (and other third party
programs) to implement this correctly so I i) do not use wildcards in ANY
force field files I develop and ii) explicitly define barrier heights of 0.0
where I think there might be a chance for confusion.
Now, the poor choice in the ILDN frcmod file is this:
X -C -CT-X 1 0.0000 0.0 2.
X -C5-CT-X 1 0.0000 0.0 2.
X -C6-CT-X 1 0.0000 0.0 2.
What is this supposed to do??? Is this expected to override any existing 2
fold terms? - I would hope not. My understanding is only there to cover
situations where there is not a specific definition for the dihedral and
they just want leap to proceed with creating the prmtop without complaining
about there being no dihedral term present. Of course the TOTAL LACK OF ANY
FORM OF COMMENTS makes the true intention of the author difficult to
discern.
The best you can hope for is to define the behavior of tleap as the 'defacto
correct answer' and just assume this is what should happen. In reality given
this force field only redefines the terms for the amino acids I, L, D and N
would it really have been so much hassle for the dihedrals to be explicitly
defined? - Note these wild cards may end up stomping on other parameters in
other amino acid side chains. Who knows! This is why the only force field I
really trust in AMBER right now is FF99SB. If I find a need to use ILDN then
I would start by going through everything by hand and comparing with Desmond
numbers etc but that would be a whole world of pain and I'd be shocked if
they came out the same.
Finally there has been some discussion on this in the past on the AMBER mail
reflector.
http://www.google.com/cse?cx=partner-pub-9700140137778662%3Arazg1fu9f1b&ie=I
SO-8859-1&q=wildcard+dihedral
http://archive.ambermd.org/201009/0837.html
http://archive.ambermd.org/200903/0109.html
Although without reading the various threads I am not sure if we came to a
consensus agreement or not.
Sorry if that all just muddies the water a bit.
All the best
Ross
> -----Original Message-----
> From: Peter Eastman [mailto:peastman.stanford.edu]
> Sent: Tuesday, October 04, 2011 10:06 AM
> To: amber.ambermd.org
> Subject: [AMBER] Ordering of torsion definitions
>
> Another question about interpreting parameter files. The format
> documentation at http://ambermd.org/formats.html includes the following
> comment:
>
> "Important note: all general type improper dihedrals (e.g. x -x -ct-hc)
> should appear before all specifics (ct-ct-ct-hc) in the parm list.
> Otherwise the generals will override the
> specific with no warning."
>
> That sounds straightforward: later definitions override earlier ones,
> and all general definitions should come before all specific ones. But
> when I look in frcmod.ff99SBildn I see the exact opposite: the general
> definitions come AFTER the specific ones. Does this really mean the
> general definitions are intended to override the specific ones? That
> seems very unlikely. Is this a bug? Or is the documentation
> incorrect, and AMBER actually uses a different rule for deciding which
> definition to use? If so, what is that rule?
>
> Peter
>
>
> _______________________________________________
> 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 Tue Oct 04 2011 - 11:00:06 PDT
