On Tue, Dec 20, 2016, David Poole wrote:
>
> Suppose a mol2 with a single atom, as generated by antechamber (no charges):
> 1 Pd 17.3460 0.7760 -3.2570 Pd 36 CEN 0.000000
>
> Loading this in tleap with the loadmol2 command, results in an entry as
> such:
> ATOM
> Name: Pd
> Type: Pd
> Charge: 0.0000
> Polarization: 0.0000
> Element: P
> Atom flags: (decimal 131072 hex 0x20000)
> posfxd n posblt n posdrwn n selected n
> pert n notdisp n touched n posknwn Y
> internal n needsmin n needsbuild n
> Atom position: 17.346000, 0.776000, -3.257000
> Atom velocity: 0.000000, 0.000000, 0.000000
> NO BONDS
>
> Correcting this with "set <unit> element Pd" works fine, so it is clearly
> worked around. The issue might be processing input as a fixed width rather
> than character delimited, and simply reading ' P' rather than 'Pd'.
This actually has nothing to do with how the mol2 file is read, since mol2
files don't contain element information in the first place.
Here is the way this is supposed to work: in order to run QM/MM
calculations, Amber requires the user to first set up an MM force field.
When done correctly, this establishes the element identification of
every atom. This should be done by the addAtomTypes in tleap.
In the absence of an addAtomTypes command, tleap has no way to know what
element corresponds to this atom type. In the far distant past, a decision
was made to guess the element based on the atom name. It would indeed be
safer to treat lack of element information as a fatal error, and demand
that the user fix it. But that would probably break existing workflows
for organic molecules, so it's hard to see any perfect solution here.
We are working on having antechamber fail with this sort of input, and I'm
cc-ing to Scott to see if there is progress there.
...thanks for the report....dac
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Dec 20 2016 - 18:30:02 PST
