Greg-
Thanks again for the quick replies.
I will try and take a stab at this, but I'm definitely not promising
anything.
Just to double check, your suggestion to take a look at /Code/GraphMol/
ForceFieldHelpers/UFF/AtomTyper.cpp is concerning the 'EmbedMolecule'
function correct?
-Marshall
On Mar 23, 2009, at 10:33 PM, Greg Landrum wrote:
Dear Marshall,
On Mon, Mar 23, 2009 at 11:17 PM, Marshall Levesque
<[email protected]> wrote:
I was trying to embed and then UFFOptimize a molecule containing
nickel, and
I ended up with this error:
######### BEGIN PYTHON INPUT/OUTPUT #######
import Chem
from Chem import AllChem
m = Chem.MolFromMolFile('nickel.sdf')
m2 = Chem.AddHs(m)
AllChem.EmbedMolecule(m2)
[14:58:38] UFFTYPER: Unrecognized hybridization for atom: 11
[14:58:38] UFFTYPER: Unrecognized atom type: Ni (11)
[14:58:38]
****
Pre-condition Violation
bad params pointer
Violation occurred on line 22 in file ForceField/UFF/BondStretch.cpp
Failed Expression: end2Params
****
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: Pre-condition Violation
######## END INPUT/OUTPUT ###########
Here is the molecule:
http://www.emolecules.com/cgi-bin/more?vid=441795
Is this problem isolated to Nickel or are there other elements that
RDKit
will spit out this error? Or am I missing something?
If you start doing transition metal complexes, I would guess that you
are likely to encounter this error reasonably frequently. The error is
caused by the interplay of a few things:
1) Most transition metals don't have a large number of UFF atom types
available (nickel, for example, is just available as Ni4+2: square
planar and 2+; which is what your system has)
2) The file formats the RDKit supports (SDF, SMILES, mol2, etc.) don't
allow particularly accurate description of the bonding in transition
metal complexes. In your example molecule the Ni is four-coordinate,
but two of the bonds are dative. There's no way to describe this in
SDF (or SMILES), so you end up with two bonds to the Ni.
3) The RDKit atom typing code hasn't been made robust in the face of
the preceding two problems (since it hasn't been used much for
transition metal complexes).
The first two problems aren't really fixable, but the last one is.
There's already some "robustification" code in the atom typer
($RDBASE/Code/GraphMol/ForceFieldHelpers/UFF/AtomTyper.cpp) for common
"organic" elements. There's also a comment that it should handle main
group and organmetallic cases better. Adding additional special cases
for common transition metals would be no problem; it just requires
someone to invest the time to add them and put in some tests for those
special cases in
$RDBASE/Code/GraphMol/ForceFieldHelpers/testHelpers.cpp.
If you file a bug report for this on sourceforge, I will try to get
the problem fixed before the Q2 release. If you want to make the
changes yourself, I'd be happy to answer questions.
-greg
