Re: [AMBER] non integer charge in antechamber generated mol2 file

From: FyD <>
Date: Thu, 09 Aug 2012 17:53:54 +0200

Dear Raik,

When one derives charge values for a whole molecule or even for a
molecular fragment rounding off errors are always generated; however,
these rounding off errors are related to the number of digits after
the decimal point chosen by the user for the charge values.

Thus for a whole molecule, if four digits are requested one ends up
with charge values such as:
  +/- X.000Y; X the wanted integer value; Y the rounding off error
   generally, Y has a max. value of around 5-7.

In the case you presented: '-0.996001' there are 6 digits after the
decimal points. So the rounding off error should have the following
shape: '-0.99999Y'

My feeling is that the difference between -1.000000 (the value you
want) and -0.996001 is _not_ a rounding off error... (& I think this
problem is known; and Antechamber has used many different programs
with or without correct charge equivalencing in the past; so this is
'normal' (personally, I do not think this is 'normal') the charges
generated by Amber?->12/Antechamber are different).

If you do want to derive a correct integer value for your molecule,
you could download the R.E.D. tools or freely use R.E.D. Server to
generate the mol2 file for your molecule. The last version of R.E.D.
and R.E.D. Server do incorporate a new algorithm for automatically
correcting (real) rounding off errors at a chosen accuracy in
agreement with chemical equivalencing. Thus, instead of obtaining
-0.99999Y (which is correct compared to -0.996001) you will get
-1.000000 (or -1.0000 instead of -0.999Y; this accuracy was that
originally used).

I hope this helps.

regards, Francois

> I have used antechamber and parmchk to create a mol2 and frcmod file
> for a small organic protein ligand with a charge of -1. The original
> coordinates were extracted from the PDB and hydrogens added with
> Chimera.
> I then run:
> antechamber -i in.pdb -fi pdb -o out.mol2 -fo mol2 -c bcc -nc -1&
> followed by:
> parmchk -i *mol2 -f mol2 -o out.frcmod
> All seems to have worked and sqm.out reports a total charge of:
>> Total Mulliken Charge = -1.000
> In reality though, the charges of the mol2 file add up to:
> -0.996001
> (In fact, the charges in the output mol2 are different from the sqm.out.)
> This is enough to make the charge neutralization in tleap fail, i.e.
> one ion is added too little, and the overall charge of the system
> cannot be brought to a clean 0.
> I see the same thing happening on two different machines (Ubuntu 12.04
> 64bit), with a fresh Amber/AmberTools12 compilation (default gnu
> compilers), all patches applied.
> Funny enough, if I generate a mol2 with Chimera (which is using
> antechamber from amber version 11) the charges sum up well and the
> problem doesn't seem to exist. But the resulting charges are quite
> different in detail and I want to stick to Amber 12.
> I guess a workaround will be to write a simple script that scales all
> partial charges to enforce a -1.0000 overall charge. Is there any more
> general solution?

AMBER mailing list
Received on Thu Aug 09 2012 - 09:00:02 PDT
Custom Search