Thanks for the response Paolo.
I would still think that regardless of the MMFF94's aromaticity model,
the only modifications it should make to the ROMol passed to it should
be to the conformer. At the very least the documentation for
MMFFMolProperties should mention the side effect.
MolToInChI and MolToMolBlock don't modify the passed molecule, even
though InChI and mol files handle aromaticity differently than the
RDKit's default.
Maybe the fact that the MMFFMolProperties constructor doesn't take the
input mol as const is clue enough that there are side effects, but it
still caught me off guard and took some time to figure out what was
happening.
Jason
On Tue, Feb 5, 2019 at 3:43 PM Paolo Tosco <paolo.tosco.m...@gmail.com
<mailto:paolo.tosco.m...@gmail.com>> wrote:
Hi Jason,
The MMFF94 force field uses a different aromaticity model from the
RDKit; to restore the traditional RDKit aromaticity model you may
useChem.SetAromaticity():
from cresset import flare
from rdkit import Chem
from rdkit.Chem import AllChem
m = Chem.MolFromSmiles("Cc1cccc(Oc2cnc(=O)[nH]c2)c1")
m1 = Chem.AddHs(m)
m2 = Chem.Mol(m1)
AllChem.EmbedMolecule(m2);
m2.GetSubstructMatches(Chem.MolFromSmarts('a'))
((1,), (2,), (3,), (4,), (5,), (7,), (8,), (9,), (10,), (12,), (13,), (14,))
AllChem.MMFFOptimizeMolecule(m2);
m2.GetSubstructMatches(Chem.MolFromSmarts('a'))
((1,), (2,), (3,), (4,), (5,), (14,))
Chem.SetAromaticity(m2)
m2.GetSubstructMatches(Chem.MolFromSmarts('a'))
((1,), (2,), (3,), (4,), (5,), (7,), (8,), (9,), (10,), (12,), (13,), (14,))
Cheers,
p.
On 02/05/19 20:31, Jason Biggs wrote:
I noticed that I'm getting a different substructure match
depending on whether I have called the MMFF optimization. This
is reproducible in python with
>> m = Chem.MolFromSmiles("Cc1cccc(Oc2cnc(=O)[nH]c2)c1")
>> m1 = Chem.AddHs(m)
>> m2 = Chem.Mol(m1)
>> AllChem.EmbedMolecule(m2);
>> m2.GetSubstructMatches(Chem.MolFromSmarts('a'))
((1,), (2,), (3,), (4,), (5,), (7,), (8,), (9,), (10,), (12,), (13,), (14,))
>> AllChem.MMFFOptimizeMolecule(m2);
>> m2.GetSubstructMatches(Chem.MolFromSmarts('a'))
((1,), (2,), (3,), (4,), (5,), (14,))
Is this expected behavior? I notice in the C++ code that the
constructor for RDKit::MMFF::MMFFMolProperties will
call MolOps::Kekulize, so maybe this is expected. For my
application it's undesirable, and I can work around it by
creating a copy of my ROMol and generating the MMFFMolProperties
object using that copy (which can then be discarded). Is there a
better workaround?
Jason Biggs
_______________________________________________
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
<mailto:Rdkit-discuss@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
_______________________________________________
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
<mailto:Rdkit-discuss@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
