Hi Jason,
Thanks, you've helping a lot, you are right about this dihedral and forget
about parm10.dat, since I am only focusing in ff99SB/parm99.dat now. However
I still see a problem, please review my email from 25 sept, with the
examples, Case 1, comparing rdparm out from reference vs antechamber, and
you see that because parmchk creates CC-H4-CW-NA in frcmod, when doing the
tleap step, it ends up overriding X -X -CW-H4 from parm99.dat, which should
be enough for addressing this dihedral (and it does when I create the
reference). The point is that CC-H4-CW-NA is not the same as X -X -CW-H4
because it's changing the order of atoms for a improper dihedral. Sounds
like for me that parmchk may be mixing rules from proper with improper?
One solution for sure for me is to put explicitly in parm99.dat:
CC-NA-CW-H4 1.1 180. 2. to disambiguate
from X -X -CW-H4
Thanks again for your attention.
Alan
On 29 September 2010 13:52, Jason Swails <jason.swails.gmail.com> wrote:
> Hello,
>
> All that parmchk does is search through the specified parameter file and
> matches the parameters it finds, including wildcards. Furthermore, the
> dihedral parameter in question is an improper, so it's not formed as a
> sequence between 2 atoms separated by 3 consecutive bonds. The dihedral I
> think it's finding is
>
> X -X -CW-H4 1.1 180. 2.
>
> located in parm10.dat. This is an improper formed from these 2 atoms and 2
> other atoms (X is a wildcard). I'm not exactly sure why it's printing it
> in
> the frcmod with CW-H4 in the middle, but it's the same dihedral, I'm pretty
> sure. This dihedral is also in parm99.dat, so you should get the same
> result dihedral using parm99.dat instead.
>
> Hope this helps,
> Jason
>
> On Wed, Sep 29, 2010 at 7:50 AM, Alan <alanwilter.gmail.com> wrote:
>
> > Dear Case and Jason,
> >
> > Thanks a lot for your observations.
> >
> > It is much clearer now for me. I am sticking with ff99SB.
> >
> > However, I still see an issue with dihedral CG-HD2-CD2-NE2 (CC-H4-CW-NA
> in
> > HHH_AC.frcmod). So, it is indeed not Antechamber which is generating the
> > dihedrals, it "parmchk".
> >
> > The atom types in HHH_gas_amber.mol2 are correct as they matched
> > identically
> > those from reference.
> >
> > Then, I did another test, based on Case1, by manually removing the
> dihedral
> > I believe is wrong from HHH_AC.frcmod:
> >
> > IMPROPER
> > H5-NA-CR-NB 1.1 180.0 2.0 General
> > improper
> > torsional angle (2 general atom types)
> > CR-CW-NA-H 1.0 180.0 2.0 General
> > improper
> > torsional angle (2 general atom types)
> > ------> removed! CC-H4-CW-NA 1.1 180.0 2.0
> > General improper torsional angle (2 general atom types)
> > CT-N -C -O 10.5 180.0 2.0 General
> > improper
> > torsional angle (2 general atom types)
> > CT-O2-C -O2 10.5 180.0 2.0 General
> > improper
> > torsional angle (1 general atom type)
> >
> > And got, correctly, DIHED = 17.9163, matching the reference value.
> >
> > Now, the question is, why parmchk is getting this extra dihedral?
> >
> > Many thanks for your attention,
> >
> > Alan
> >
> > On 26 September 2010 14:56, case <case.biomaps.rutgers.edu> wrote:
> >
> > > On Sat, Sep 25, 2010, Alan wrote:
> > >
> > > > First, I am not using ff10 for simulations. My interest is
> Antechamber
> > > (as
> > > > it is the core of ACPYPE). I am testing ff10 to validate according my
> > > > criteria (still working on a paper to be published) and doing so I
> hope
> > > to
> > > > help improve AmberTools.
> > >
> > > OK...I understand now what you are after. The point is that the "-at
> > > amber"
> > > flag in Antechamber cannot be used with parm10.dat. Antechamber
> doesn't
> > > know
> > > about changing C-alpha atoms in proteins to atom type "CX". The
> > parm10.dat
> > > parameters should only be used in conjunction with the corresponding
> > > "10" library files.
> > >
> > > In addition, I worry about the "-at amber" flag in general.
> Antechamber
> > > development has been primarily devoted to the GAFF force field. The
> "-at
> > > amber" option is only useful in certain, very restricted
> cases--basically
> > > when the molecule in question is a *small* modification of something
> > > appears in
> > > proteins or nucleic acids, so that using Amber atom types might be a
> > better
> > > option than GAFF. Amber atom types are *very* limited -- even
> seemingly
> > > minor changes in the bonding environment might lead to dramatically bad
> > > behavior.
> > >
> > > Second: although this is probably not stated well in the documentation,
> > > there
> > > will almost certainly need to be hand-editing of results that use this
> > > flag.
> > > There is no automated way of generating charges that match the Amber
> ff.
> > > R.E.D. might help, but for small changes from existing amino acids or
> > > nucleotides, one might really want to (somewhat arbitrarily) restrict
> the
> > > charge changes to a small region of the molecule. This will almost
> > > certainly
> > > involve hand-work and subjectivity.
> > >
> > > >
> > > > One point of this exercise is to know how good is Antechamber in
> > > reproducing
> > > > results for which we know the results.
> > >
> > > This does need to be checked (better than it has been), or else the
> "-at
> > > amber" flag is broken. But in this context, "amber" refers to the atom
> > > types
> > > in parm94/99. As we add new atoms types (e.g. CI in parmbsc0, or CX in
> > > parm10) the antechamber code itself will need to be modified if
> > > compatibility
> > > is to be maintained.
> > >
> > > >
> > > > Case 1: Using ff99SB/ff99bsc0 (they gave the same result)
> > > >
> > > >
> > > > So I believe antechamber is generating this particular class of
> > dihedrals
> > > > wrongly.
> > >
> > > Antechamber doesn't generate dihedrals, good or bad. That is done by
> > leap.
> > > In you example, you need to compare the atom types in
> HHH_gas_amber.mol2
> > > with
> > > the atom types in the standard Amber libraries.
> > >
> > > >
> > > > End of Case 1
> > > >
> > > >
> > #------------------------------------------------------------------------
> > > > Now Case 2: Running example above for ALA (AAA) and comparing ff99SB
> x
> > > ff10
> > > >
> > >
> > > > So, AAA ff10_ref works fine because when creating AAA, it gets CX
> atom
> > > type
> > > > instead of CT.
> > > > However, when using Antechamber, atom type identified is CT
> > >
> > > The options here are (1) don't use antechamber with ff10; (2) change
> the
> > > antechamber code (e.g. with a "-at amber10" flag), so that it creates
> the
> > > same atom types as are in the library files for ff10.
> > >
> > > Thanks for the detailed information and tests. Right now, as you have
> > > found,
> > > the "-at amber" flag is no substitute for having the "real" library
> > files.
> > > But it could come closer than it does.
> > >
> > > ....regards...dac
> > >
> > >
> > > _______________________________________________
> > > AMBER mailing list
> > > AMBER.ambermd.org
> > > http://lists.ambermd.org/mailman/listinfo/amber
> > >
> >
> >
> >
> > --
> > Alan Wilter S. da Silva, D.Sc. - CCPN Research Associate
> > Department of Biochemistry, University of Cambridge.
> > 80 Tennis Court Road, Cambridge CB2 1GA, UK.
> > >>http://www.bio.cam.ac.uk/~awd28 <http://www.bio.cam.ac.uk/%7Eawd28><<
> > _______________________________________________
> > AMBER mailing list
> > AMBER.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber
> >
>
>
>
> --
> Jason M. Swails
> Quantum Theory Project,
> University of Florida
> Ph.D. Graduate Student
> 352-392-4032
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
--
Alan Wilter S. da Silva, D.Sc. - CCPN Research Associate
Department of Biochemistry, University of Cambridge.
80 Tennis Court Road, Cambridge CB2 1GA, UK.
>>http://www.bio.cam.ac.uk/~awd28<<
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Sep 30 2010 - 03:30:03 PDT
