Hi Francois,
thanks for pointing me to your tools + web server. Looks useful.
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? That's what the
quick and dirty python script is doing (attached to my previous mail).
Greetings,
Raik
On Thu, Aug 9, 2012 at 11:53 AM, FyD <fyd.q4md-forcefieldtools.org> 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
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
--
___________________________________
Raik Grünberg
http://www.raiks.de/contact.html
___________________________________
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Aug 10 2012 - 21:00:02 PDT
