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

From: FyD <>
Date: Mon, 13 Aug 2012 18:35:31 +0200

Dear Raik,

> In this case though, I guess there is nothing wrong with my workaround
> of simply scaling all the partial charges in the mol2 by a tiny bit
> such that the sum is perfectly integer, or is there?

You can indeed modify by hand the charge values in the mol2 file in
agreement with chemical equivalencing; except that the program you use
should provide you a total charge value with correct chemical
equivalencing (for MD simulations) with rounding off errors (or
without rounding off errors). If not this might reflect a more
important problem...

> That's what the
> quick and dirty python script is doing (attached to my previous mail).

Many people 'arrange' by hand charge values - in particular, when one
wants to generate charge values for a molecular fragments. Personally,
I vote against this type of approach.

The R.E.D. program has been designed to rigorously derive MEP (RESP
and ESP) based charges for whole molecules _and_ molecular fragments
(see tutorials at; avoiding
quick and dirty work after charge derivation ;-) All the parameters
that affect MEP based charge values (when using a fixed charge model
so far) are fully controlled, were extensively tested and are in
agreement with the original publications...
the "Charge reproducibility" section...

regards, Francois

> On Thu, Aug 9, 2012 at 11:53 AM, FyD <> wrote:
>> 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 Mon Aug 13 2012 - 10:00:03 PDT
Custom Search