[gmx-users] Re: Re: help with chromophore of a GFP

[Mark Abraham]

On Mon, Mar 25, 2013 at 4:56 PM, Anna MARABOTTI <amarabotti at unisa.it> wrote:

>
>
> Dear gmx-users,
>
> I'm still dealing with my problem of obtaining
> parameters for my chromophore of the GFP family, in order to treat it as
> a new residue. I'm trying (VERY hardly) to add missing parameters into
> ffbonded.itp file for AMBER99SB ff, using those parameters found in
> files calculated by Antechamber. To date, I've added those parameters
> related to bonds, now I have to add those related to angles, dihedrals
> and impropers.
>
> I'm dealing with section [angletypes] of file
> ffbonded.itp, and I'm looking at the values of cth (that I imagine is
> the angle force constant expressed in kJ mol^-1 rad^-2, correct?) I see
>

Yes, table 5.5 is definitive.

that all parameters in ffbonded.itp are multiple of the value of 4.184,
> corresponding to the conversion factor between kcal and kJ. If I divide
> each of these values, I obtain a value corresponding to a number such as
> 80, 70, 120, 40 etc.


These are (should be) based on the original definition in the AMBER force
field.


> Instead, if I look at those corresponding values
> found using Antechamber, I see, as expected, numbers with decimals, that
> are often very different from those present in ffbonded.itp (when I
> compare angles present in both files). For example, for the angle
> CT-CT-CT (3 C sp3), I see in ffbonded.itp a value of cth equal to 334.72
> kJ mol^-1 rad^-2. For the same angle, Antechamber calculated a value of
> 63.21 kcal/mol^-1 rad^-2. If I do 334.72/4.184 the result is 80, which
> is different from the value of Antechamber. If I consider the angle
> CT-CT-HC (2 C sp3 and one H) the angle force constant in Antechamber is
> 46.37 kcal mol-1 rad-2, in ffbonded.itp is 418.4, that divided by 4.184
> is exactly 100.
>

I gather you asked Antechamber to do an unconstrained optimization, so it
did. That's clearly not so reasonable for incorporating the result into a
force field that uses the same atom types. Either you need to use a
different atom type for the newly-parameterized CT (perhaps by naming the
atoms differently in the input to Antechamber) so there's no mismatch, or
you need to explore how to constrain Antechamber's optimization (e.g. its
documentation or the AMBER mailing list).


> Moreover, the same values of angles and forces are
> applied to angles that in my opinion are quite different among them. For
> example, I found the same value of 109.5 (th) and 418.4 (cth) for:
> H2-CT-N*, H1-CT-N*, H1-CT-OH, H1-CT-OS, H2-CT-OS, N*-CT-OS, C-CT-H1,
> H1-CT-N2, C-CT-HC... All these angles involve atoms that seem very
> different to me, and I'd expect to find different values of these
> parameters.
>

Welcome to the joys of parametrisation. If you were to parameterise each of
those separately, you would need data that would be sensitive to each, and
ideally more than one kind of data. The number of possible interaction
types, the amount of parametrisation data required, and length of the
overall optimisation process explodes fast (each parameter should be
optimised in the context of *all* the others, remember). The additional
value delivered by the specialised parameters would be low. So "catch-all"
parameters are, unfortunately, common. It is not possible to model these
interactions accurately with a single force constant that is valid in all
chemical contexts of interest, so one has to give up at some point.

It seems to me that values into ffbonded.itp related to
> these force constants are quite "strange", especially for the fact that
> they are EXACTLY multiple of 4.184, and I wonder if I'm correctly
> interpreting these values.
>

It sounds like the original parametrisation used a granularity of 10
kcal/mol for these force constants. Optimising any of the parameters to
arbitrary precision is likely to lead to over-fitting the parameters to the
data used for parametrisation. Losing the capacity to generalise to
observables outside the parametrisation set is another hidden trap in the
process. Fortunately, discretising the problem domain also speeds up the
optimisation.

Mark