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
http://q4md-forcefieldtools.org/Tutorial/); 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...
See
http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2918240/
&
http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2918240/#S7title
the "Charge reproducibility" section...
regards, Francois
> 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
Received on Mon Aug 13 2012 - 10:00:03 PDT
