Re: [Rdkit-discuss] drawing code take 3

[Dimitri Maziuk]

On 2016-09-26 18:19, Peter S. Shenkin wrote:

> 2D drawing code is tough. The 90/10 rule applies: the last 10% of
> I think for the present purposes what we need is something correct,
> robust and legible, and of course the example shown does not exhibit
> that. (But I don't know what the starting SMILES is, so I don't know
> whether the 7-bonded C is due to a bad SMILES, in which case all bets
> are off.)

That was actually a "kudos to RDKit" post.

I have an application where I need a drawing with all Hs and all atom 
labels, and molecule description in mmCIF(-ish) format. I use RDKit for 
the latter because of OpenBabel's stereochemistry "model", and OpenBabel 
for the drawings because 90% of the time it generates better layouts.

THE comment is that RDKit's layout algorithm appears to be more stable: 
for this molecule OB generated a "better" picture from the original SDF 
downloaded from PubChem, and that complete mess when we re-ordered the 
atoms. RDKit generated the same picture in both cases. only one is a 
mirror image of the other.

Dima


--
___
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss

Re: [Rdkit-discuss] (no subject)

[Curt Fischer]

Last week, Greg gave us a nice example of substructure matching using a
SMARTS query (see below).  I learned a lot from this thread, not the least
of which was to use the IPythonConsole module and to enable SVG for
beautiful drawings.

This style is indeed much better than the old drawings.

I was interested in making grid images of molecules, where some molecules
in the grid matches a query structure and some didn't.  I eventually
figured it out.  See my Jupyter notebook at
http://nbviewer.jupyter.org/github/tentrillion/ipython_notebooks/blob/master/smarts_queries_in_rdkit.ipynb
if you are interested.

I had a question about these lines:

highlight_lists = [mol.__sssAtoms for mol in
my_molecules]Draw.MolsToGridImage(my_molecules, highlightAtomLists =
highlight_lists)


It took my forever to figure out that this was required.  Is this desired
behavior?

I ask because it seems to differ from what's required to show matches in
single molecules.  No explicit reference to atoms for highlighting was
required.  The behavior for multiple molecules -- at least the way I am
doing it -- seems different.  Would it just be a small addition to the
ShowMols() function in rdkit.Chem.Draw.IPythonConsole to fix this, if it is
indeed a bug?

Curt


On Wed, Sep 21, 2016 at 8:31 PM, Greg Landrum 
wrote:

> Hi Markus,
>
> Curt's instincts are dead on: the problem here is the rings.
>
> I'll show the fix and then explain what's going on. You just need to add
> one line to your code:
>
> core = "[a]12[a][a][a][a][a]1[a][a][a]2"
> pattern = Chem.MolFromSmarts(core)
> Chem.GetSSSR(pattern)
> AllChem.Compute2DCoords(pattern)
>
> when I do this, I get the following depiction for "c1(ocn2)c21":
>
> (The highlighting is due to the substructure match that's done during the
> generation of coordinates).
>
> So why is this necessary?
> The code that generates 2D coordinates uses information about the size of
> ring systems in the molecule as part of the coordinate generation. If no
> ring information is present (which is true of molecules generated from
> SMARTS since they are not fully sanitized on construction) then the code
> calls FastFindRings(). This function is perfectly capable of identifying
> all ring atoms and bonds, but it isn't very good at getting ring sizes
> correct for fused systems (it finds rings, but not the smallest rings). The
> consequences are the badly generated coordinates for fused ring systems
> that you were seeing.
>
> I think the current behavior of the code "isn't really ideal": the
> coordinate generation code should call the SSSR algorithm in these cases so
> that it can generate better coordinates. I'll take a look at the code and
> think about changing it.
>
> As an aside: if you're puzzled by the behavior of
> AllChem.GenerateDepictionMatching2DStructure() you can always just take a
> look at the drawing of the query molecule itself. It's not always the most
> informative depiction when it comes to what the atom and bond queries are,
> but you at least will see the coordinates.
>
> A second aside: the molecule depictions in that notebook indicate that you
> are stuck using the fallback drawing code, which creates fairly ugly
> pictures. You can get better drawings by either installing cairo and
> pycairo (in which case the code should automatically use those) or telling
> the drawing code to use SVG for the rendering:
>
> from rdkit.Chem.Draw import IPythonConsole
> IPythonConsole.ipython_useSVG=True
>
> It really does make the drawings a lot better.
>
> I hope this helps,
> -greg
>
>
>
>
>
>
> On Wed, Sep 21, 2016 at 8:47 PM, Markus Metz  wrote:
>
>> Hello all:
>>
>> I am trying to perform a 2D alignment of molecules by using a pattern for
>> which I am using Compute2DCoords.
>>
>> If I use a smarts string matching napthalene the 2D depiction is as one
>> would expect.
>> However, if I am switching to a 5,6 aromatic smarts pattern the matched
>> benzoxazol the 2D structure looks rather unusual.
>>
>> Is there a way to match the 5,6 with the 6,6 pattern behavior?
>>
>> Any hint is very much appreciated,
>>
>> Markus
>>
>> P.S. a work book is attached.
>>
>> 
>> --
>>
>> ___
>> 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
>
>
--
___
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss

Re: [Rdkit-discuss] OCEAN: Our Target Prediction Paper (including Source Code)

[George Papadatos]

Hi guys,

Congrats - great use of ChEMBL and myChEMBL too :)


George



On 27 September 2016 at 05:13, Paul Czodrowski <
paul.czodrow...@merckgroup.com> wrote:

> Dear RDKitters,
>
>
>
> Our target prediction method – fully based on RDKit – has become online:
>
> OCEAN: *O*ptimized *C*ross r*EA*ctivity estimatio*N*
>
> http://pubs.acs.org/doi/abs/10.1021/acs.jcim.6b00067
>
>
>
> The source code can be found here:
>
> https://github.com/rdkit/OCEAN
>
>
>
> We will give a talk as well an hands-on workshop at the upcoming RDKit UGM
> end of October.
>
>
>
> Cheers,
>
> Guido & Paul
>
>
>
> This message and any attachment are confidential and may be privileged or
> otherwise protected from disclosure. If you are not the intended recipient,
> you must not copy this message or attachment or disclose the contents to
> any other person. If you have received this transmission in error, please
> notify the sender immediately and delete the message and any attachment
> from your system. Merck KGaA, Darmstadt, Germany and any of its
> subsidiaries do not accept liability for any omissions or errors in this
> message which may arise as a result of E-Mail-transmission or for damages
> resulting from any unauthorized changes of the content of this message and
> any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its
> subsidiaries do not guarantee that this message is free of viruses and does
> not accept liability for any damages caused by any virus transmitted
> therewith.
>
>
>
> Click http://www.merckgroup.com/disclaimer to access the German, French,
> Spanish and Portuguese versions of this disclaimer.
>
> 
> --
>
> ___
> 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

Re: [Rdkit-discuss] OCEAN: Our Target Prediction Paper (including Source Code)

[Axel Pahl]

Hi Paul,

very interesting, thanks a lot for sharing!
Looking forward to the presentation at the UGM!

Kind regards,
Axel

On 27.09.2016 06:13, Paul Czodrowski wrote:


Dear RDKitters,

Our target prediction method – fully based on RDKit – has become online:

OCEAN: *O*ptimized *C*ross r*EA*ctivity estimatio*N*

http://pubs.acs.org/doi/abs/10.1021/acs.jcim.6b00067

The source code can be found here:

https://github.com/rdkit/OCEAN

We will give a talk as well an hands-on workshop at the upcoming RDKit 
UGM end of October.


Cheers,

Guido & Paul

This message and any attachment are confidential and may be privileged 
or otherwise protected from disclosure. If you are not the intended 
recipient, you must not copy this message or attachment or disclose 
the contents to any other person. If you have received this 
transmission in error, please notify the sender immediately and delete 
the message and any attachment from your system. Merck KGaA, 
Darmstadt, Germany and any of its subsidiaries do not accept liability 
for any omissions or errors in this message which may arise as a 
result of E-Mail-transmission or for damages resulting from any 
unauthorized changes of the content of this message and any attachment 
thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do 
not guarantee that this message is free of viruses and does not accept 
liability for any damages caused by any virus transmitted therewith.


Click http://www.merckgroup.com/disclaimerto access the German, 
French, Spanish and Portuguese versions of this disclaimer.




--


___
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