Re: [AMBER] Atom types for "alkene carbons", R.E.D.

From: FyD <fyd.q4md-forcefieldtools.org>
Date: Sat, 30 Nov 2013 10:04:49 +0100

Dear Dr Case,

>>> I am trying to obtain parameters for an alkene amide bond isostere using
>>> the R.E.D. server. My problem is at the very end of the procedure when
>>> trying to choose correct atom types for the two alkene carbons.
>>> I am using the force field amber99SB, and when checking the available
>>> atom types neither one of them seem correct. It is an sp2 carbon, but it
>>> is not aromatic, a member of a ring or a carbonyl ... Are there no atom
>>> types for these carbons?
>>
>> The ff99SB force field was designed for proteins and nucleic acids, not for
>> general organic molecules. So the list of atom types is quite limited.
>> You should consider using GAFF for more general molecules.
>
> I think there is no problem in this case...

The Amber99SB force field is in fact a set of dihedral FF parameters
re-optimized by Hornak et al. At the basis of these dihedrals is the
Amber99 force field. See:
http://q4md-forcefieldtools.org/REDS-Development/Demo2-Files/Configuration.py
# AMBERFF99SB: Wang et al. J.Comput.Chem. 2000, 21, 1049.
# Hornak et al. Proteins 2006, 65, 712.
and the title of the Wang et al. force field (i.e. parm99) is:
"How well does a restrained electrostatic potential (RESP) model
perform in calculating conformational energies of organic and
biological molecules?"

But you know that better than me - so I just want to underline these
points for new readers of the Amber mailing list and to describe the
approach followed in R.E.D. Python.

The tasks performed by R.E.D. Python are summarized at:
http://q4md-forcefieldtools.org/REDS-Development/news.php
  & among these tasks, one can find:
  - User-defined atom typing
  - Introduction of the q4md-forcefieldtools and of user-defined FF
thus here the Amber99 FF is extended in the context of the project of
the user when one selects FFPARM = "AMBERFF99SB" in the
Configuration.py file.

We voluntary decided not using GAFF for many reasons - the key reason
here is that GAFF contains many parameters/atom types which are
useless for the user in the context of her/his project.

The followed approach: R.E.D. Python identifies FF parameters which
are judged 'correct' by our algo. (frcmod.knowm), list FF parameters
which are identified by 'analogy' (frcmod.correspondence; obviously
more suspicious) and finally FF parameters, that should be recomputed
and that should be particularly checked if one copies them from a
different source (frcmod.unknown).

Finally a user can provide its own atom types in the Project.config
file for a given molecule instead of letting R.E.D. Python performing
atom typing; she/he can also provide its own force field parameters in
a frcmod.user file used as input.

regards, Francois



_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Sat Nov 30 2013 - 01:30:02 PST
Custom Search