On Thu, Jul 22, 2010, Don.Bashford.stjude.org wrote:
> It looks to me like the usage of any of the charge methods, "mul",
> "cm1", "cm2" when using antechamber with mopac (the default) results
> in Coulson-type charges rather than Mulliken, etc.
Don: thanks for pointing this out. The history is that antechamber was
originally written to use divcon output, which has options for outputting
lots of charge models (including cm1, cm2, mulliken...)
We later went to mopac (for a variety of reasons); the main interest was
to get am1-bcc charges, which use "Coulson" charges as input. No one seemed
to notice that certain less-used options no longer worked (= test suite
failure).
Since AmberTools 1.3, yet a third program, "sqm" is used (mopac is not longer
the default). Again, testing has concentrated on am1-bcc stuff.
I'm cc-ing this to Junmei for ideas about mopac, and to Andy Goetz and Tim
Giese for comments on sqm. [Andy: it looks to me(?) like what sqm calls
"Mulliken" charges in the output are in fact not Mulliken, but Coulson
charges....can we find volunteers to get correct labelling (if it is
indeed wrong) and more options into sqm? Please see Don's comments below.
>
> Examining the source code, I see that specifying "-c mul" on the
> command line leads to calling the function, mul in charge.c which sets
> up a mopac calculation (AM1) without "MULLIK" among the mopac
> keywords, so no Mulliken analysis gets done. Then the mopac output is
> processed by the rmopcharge function which looks for a block of
> charges following a line like, "NET CHARGES AND DIPOLE CONTRIBUTIONS".
>
> I think these are not Mulliken charges. According to the mopac
> documentation (http://openmopac.net/manual/index.html -> Features ->
> Derived Properties), these are Coulson charges. To get Mulliken
> charges in the mopac output you need the MULLIK keyword, and then they
> end up following a line that says, "MULLIKEN POPULATIONS AND CHARGES",
> while the "NET CHARGES AND DIPOLE CONTRIBUTIONS" block still just has
> Coulsons.
>
> As a test I tried running,
>
> antechamber -i ptr.pdb -fi pdb -o ptr-mul.mol2 -fo mol2 -c mul
>
> and
>
> antechamber -i ptr.pdb -fi pdb -o ptr-cm1.mol2 -fo mol2 -c cm1
>
> and similarly for cm2.
>
> In all cases the ptr-*.mol2 file has identical charges, and they are
> the Coulsons, as described above.
>
> I can get the mopac run to actually do a Mulliken analysis by using
> the -ek option with the argument,
>
> " AM1 ANALYT MMOK GEO-OK PRECISE MULLIK ",
>
> but then the final mol2 file STILL gets the Coulson charges rather
> than the Mullikens even though mopac.out contains a block of Mulliken
> charges.
>
> The above tests were done using AmberTools-1.2, but the source code I
> examined was from AmberTools-1.4, so I think the behavior will be the
> same.
>
> So it looks like way to get real Mulliken charges is to run mopac with
> the MULLIK keyword, use an awk script or something to get the charges
> from the Mulliken block and into an 8-float-per-line format as needed
> for the "rc" charge method, and use "-c rc" on the antechamber command
> line.
>
> By the way, we are currently using a similar workaround to get
> mopac-generated ESP charges into a mol2 file. At present, antechamber
> insists on Gaussian input if you want to use ESP or RESP charges.
>
....dac
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Jul 22 2010 - 20:00:03 PDT
