Re: [Rdkit-discuss] difficulties with AllChem.EmbedMultipleConfs() on a macrocycle

[Curt Fischer]

Thanks for the notebook Sereina!

Unfortunately when I run it I get different results.  In your version, the
very first call to EmbedMolecule() returns 0, which presumably means that
embedding went OK.




*## Embed the molecule without HsAllChem.EmbedMolecule(m,
useExpTorsionAnglePrefs=True, useBasicKnowledge=True)Out[7]: 0*


When I run your notebook, this same call returns -1.  Maybe my rdkit is
different than yours?  I'm using '2016.09.2' on Mac OSX 64-bit.



On Thu, Mar 2, 2017 at 12:00 PM, Sereina  wrote:

> Hi Curt,
>
> This is an interesting one. If you add the hydrogens before generating the
> conformer as in your example, then no conformation can be found. However,
> if you add them *after* the conformer generation, it works fine. Maybe that
> could serve as a work around for you. I attach a notebook as illustration.
> As this occurs with both DG and ETKDG, it may be due to the tests to ensure
> that the chiral centers are correct. I will have a closer look (hopefully
> with Greg’s help).
>
> Best,
> Sereina
>
>
>
>
>
> On 02 Mar 2017, at 19:34, Curt Fischer  wrote:
>
> Hi all,
>
> I really like combination of rdkit and py3dmol and have been able to
> replicate e.g. Greg's notebook here: http://nbviewer.jupyter.
> org/github/greglandrum/rdkit_blog/blob/master/notebooks/
> Trying%20py3Dmol.ipynb
>
> But I can't seem to get AllChem.EmbedMultipleConfs() to generate any
> valid conformers for a macrotriolide, macrosphelide A.
>
> *macrosphelide_a_smiles =
> 'C[C@H]1CC(O[C@H](C)[C@H](O)/C=C/C(O[C@@H](C)[C@@H](O)/C=C/C(O1)=O)=O)=O'*
> *m = Chem.MolFromSmiles(macrosphelide_a_smiles)*
> *mh = Chem.AddHs(m)*
> *AllChem.EmbedMultipleConfs(mh, useExpTorsionAnglePrefs=True,
> useBasicKnowledge=True)*
> *mb = Chem.MolToMolBlock(mh)*
>
> The EmbedMultipleConfs() call never terminates for me.  If I use a
> non-zero value for *maxAttempts*, the call does terminate, but when I
> look at *mb*, the coordinates for all atoms are zero.
>
> I've tried playing around with a few of the other options, without luck.
> Either all atom coordinates are still zero after *EmbedMultipleConfs()*,
> or the function call never terminates.
>
> Any chance someone knows how to coax this function into yielding a useful
> conformation for my molecule?
>
> Curt
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot__
> _
> Rdkit-discuss mailing list
> Rdkit-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
>
>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss

[Rdkit-discuss] difficulties with AllChem.EmbedMultipleConfs() on a macrocycle

[Curt Fischer]

Hi all,

I really like combination of rdkit and py3dmol and have been able to
replicate e.g. Greg's notebook here:
http://nbviewer.jupyter.org/github/greglandrum/rdkit_blog/blob/master/notebooks/Trying%20py3Dmol.ipynb

But I can't seem to get AllChem.EmbedMultipleConfs() to generate any valid
conformers for a macrotriolide, macrosphelide A.

*macrosphelide_a_smiles =
'C[C@H]1CC(O[C@H](C)[C@H](O)/C=C/C(O[C@@H](C)[C@@H](O)/C=C/C(O1)=O)=O)=O'*
*m = Chem.MolFromSmiles(macrosphelide_a_smiles)*
*mh = Chem.AddHs(m)*
*AllChem.EmbedMultipleConfs(mh, useExpTorsionAnglePrefs=True,
useBasicKnowledge=True)*
*mb = Chem.MolToMolBlock(mh)*

The EmbedMultipleConfs() call never terminates for me.  If I use a non-zero
value for *maxAttempts*, the call does terminate, but when I look at *mb*,
the coordinates for all atoms are zero.

I've tried playing around with a few of the other options, without luck.
Either all atom coordinates are still zero after *EmbedMultipleConfs()*, or
the function call never terminates.

Any chance someone knows how to coax this function into yielding a useful
conformation for my molecule?

Curt
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss

Re: [Rdkit-discuss] PBF precision is to high to determine good planarity

[Dimitri Maziuk]

On 2017-03-02 04:37, Guillaume GODIN wrote:

> Based on the precision of the coordinates (in rdkit sdf files it's 4
> digits) can we infer the precision on the PBF value based on that ?

Only if you *know* the values are actually accurate to 4 digits and not 
e.g. were printed as "%.4f" just because the programmer thought it was a 
"reasonable" mask.
:(

Dimitri


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss

Re: [Rdkit-discuss] PBF precision is to high to determine good planarity

[Greg Landrum]

Guillaume,

Which test are you actually doing?

I would certainly always recommend adding some kind of tolerance value for
anything involving floating point values. This helps protect you from both
roundoff error and the precision of various file formats.

-greg


On Thu, Mar 2, 2017 at 11:37 AM, Guillaume GODIN <
guillaume.go...@firmenich.com> wrote:

> Dear Chris,
>
>
> Thanks,
>
>
> Yes that can be the case (I changed all 0 values to 1 or 2 or 3 and it's
> keep to be planar).
>
>
> Based on the precision of the coordinates (in rdkit sdf files it's 4
> digits) can we infer the precision on the PBF value based on that ?
>
>
> When you compute "pinv" for example even in matlab, there is a standard
> thresold to avoid those precision issues.
>
>
> Yes of course, I can put my own threshold that's true (Greg generaly
> takes 1e-4 to check if the results are similar from time to time).
>
>
> It's would be relevant to establish standard rules in term of threshold
> anyway.
>
>
> BR,
>
>
> Guillaume
> --
> *De :* Chris Earnshaw 
> *Envoyé :* jeudi 2 mars 2017 11:07
> *À :* Guillaume GODIN; Rdkit-discuss@lists.sourceforge.net
> *Objet :* Re: [Rdkit-discuss] PBF precision is to high to determine good
> planarity
>
> Hi Guillaume
>
> I suspect that your first case 'works' because all the Z-coordinates are
> exactly zero and so the structure can be perceived as exactly planar. The
> second SD file is probably not perfectly planar, due to the limited
> precision of the coordinates in the SD file and the internal representation
> of floating point numbers. In general, exact equality checks with floating
> point numbers are rather dangerous.
>
> Instead of RDkit imposing a default threshold PBF value - which may not be
> appropriate in all cases - why not simply check if the returned value is
> below whatever threshold is relevant for you?
>
> Best regards,
> Chris
>
> On 2 March 2017 at 08:22, Guillaume GODIN 
> wrote:
>
>> Dear All,
>>
>>
>>
>> I am working on the Whim implementation following the article of
>> Todeschini & Consonni in Handbook of Chemoinformatic book (
>> http://michem.disat.unimib.it/chm/download/materiale/geomet
>> rical_descriptors.pdf)
>>
>>
>> I used rkdit to generate 3D coordinates sdf file of chlorobenzene and I
>> also manually write another sdf file using the exact values x,y,z from the
>> book page 1015.
>>
>>
>>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss