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>
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 Chemfrom 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
> listRdkit-discuss@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/rdkit-discuss
>
>
> _______________________________________________
> Rdkit-discuss mailing list
> Rdkit-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
>
_______________________________________________
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
