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
Received on Sun Sep 26 2010 - 07:00:06 PDT
