Re: [Rdkit-discuss] GenerateDepictionMatching[23]DStructure (a bit off-topic)

[Peter S. Shenkin]

That's a really nice presentation.

-P.

On Fri, Nov 18, 2016 at 3:16 AM, Greg Landrum 
wrote:

> This is a very big topic, and one where I would very much like to improve
> the RDKit. John Mayfield gave a great talk on the issues (and some ideas
> about fixing them based on his work with the CDK) at the UGM that some of
> you may find interesting :
> https://github.com/rdkit/UGM_2016/blob/master/Presentations/JohnMayfield_
> Depiction.pdf
>
> Fixing the larger problems is a *lot* of work and not something that is
> likely to happen quickly, but there is some low-hanging fruit (like cutting
> crossed bonds) that I ought to be able to do something about.[1]
>
> -greg
> [1] the trick is to avoid, as much as possible, creating drawings that
> look like Möbius strips.
> _
> From: Peter S. Shenkin 
> Sent: Thursday, November 17, 2016 11:23 PM
> Subject: Re: [Rdkit-discuss] GenerateDepictionMatching[23]DStructure (a
> bit off-topic)
> To: 
>
>
>
>
> On 17 Nov 2016, at 4:12 PM, Dimitri Maziuk  wrote:
>
> Philosophically speaking, there must exist molecules for which a legible
> 2D projection is simply not possible.
>
>
> Hi,
>
> I don't think that 2D projection of a 3D structure is an appropriate
> paradigm for 2D depiction, in general. I think of it as being more about 2D
> construction. I don't think camphor is a particularly difficult example,
> though, and I think that the hidden-line elimination (for lack of a better
> term) that Marvin does gives it a leg up on RDKit's representation.
>
> By the way, I do not think that Marvin is the best there is out there;
> it's just what I happen to have available for comparison.
>
> Stereochemistry adds complications, because 3D information has to be
> encoded in some way. Camphor (your suggestion) has a little of this. I gave
> Marvin a non-stereo SMILES and it picked an enantiomer. I drew the same
> enantiomer. I did not specify stereochemistry to RDKit, so, despite the
> visual confusion of the bond crossings, I suppose it's good that it didn't
> depict an explicit enantiomer.
>
> And labels add further complications. The two approaches I've seen for
> labels are using them as the atomic vertices, as RDKit does, and adding
> them adjacent to the vertices. I personally prefer the latter, because to
> my eye, it's easier to see the connectivity without being distracted by the
> labels.
>
> But my philosophical point was that different forms of 2D depiction work
> better for different purposes. Stéphane wants to see sugars drawn as
> carbohydrate chemists are used to seeing them. I would like to see the 2D
> connectivity as clearly as possible and would sacrifice some conventions
> for that purpose. And so on.
>
> -P.
>
>
>
>
> 
> --
>
> ___
> 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] Coot heading to Fedora

[Paul Emsley]

On 18/11/2016 23:47, Greg Landrum wrote:
> Hopefully you know that there is already a Cairo-based renderer in C++ and are
> modifying/improving that?

Oh. Either I didn't know about that or I'd forgotten about it.  My code was 
well under-way 
before I heard about David's contribution and I haven't kept an eye on it - I 
preferred to 
edit/write my own code than read/understand/edit/improve someone else's ;-/.

> Or does what is there "have so much room for improvement" that it's better to 
> start over?

Only in ignorance.  However, this does encourage me to checkout the latest 
rdkit and do some 
side-by-sides.

The implicit point of my post was to say that if you wanted to install coot on 
your fedora 
box, then the part that most intertwined RDKit was the ligand builder gui.

Paul.


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

Re: [Rdkit-discuss] Coot heading to Fedora

[Greg Landrum]

Hopefully you know that there is already a Cairo-based renderer in C++ and are 
modifying/improving that?
Or does what is there "have so much room for improvement" that it's better to 
start over?
-greg






On Fri, Nov 18, 2016 at 3:05 PM +0100, "Paul Emsley" 
 wrote:










On 18/11/2016 18:35, Gianluca Sforna wrote:
> I just wanted to mention that coot (crystallographic macromolecular
> building toolkit)[1] is the first package (at least, that I know of)
> requiring rdkit as a dependency under review [2] to enter Fedora
> repositories.

I've been cheering you on since 2013 :-)

FWIW, I've been tinkering with a cairo-based rendering of the RDKit's layout 
and hence found 
the slides of John Mayfield's presentation, which Greg mentioned recently, 
fascinating. If 
only it weren't so difficult to meet in person we'd have a lot to discuss.

Paul.


--
___
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] Coot heading to Fedora

[Paul Emsley]

On 18/11/2016 18:35, Gianluca Sforna wrote:
> I just wanted to mention that coot (crystallographic macromolecular
> building toolkit)[1] is the first package (at least, that I know of)
> requiring rdkit as a dependency under review [2] to enter Fedora
> repositories.

I've been cheering you on since 2013 :-)

FWIW, I've been tinkering with a cairo-based rendering of the RDKit's layout 
and hence found 
the slides of John Mayfield's presentation, which Greg mentioned recently, 
fascinating. If 
only it weren't so difficult to meet in person we'd have a lot to discuss.

Paul.


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

Re: [Rdkit-discuss] GenerateDepictionMatching[23]DStructure (a bit off-topic)

[Téletchéa Stéphane]

Le 18/11/2016 à 09:16, Greg Landrum a écrit :
> Fixing the larger problems is a *lot* of work and not something that 
> is likely to happen quickly, but there is some low-hanging fruit (like 
> cutting crossed bonds) that I ought to be able to do something about.[1]
>
> -greg
> [1] the trick is to avoid, as much as possible, creating drawings that 
> look like Möbius strips.

Dear Greg,

I appreciate your tremendous, and I have always wanted to give back to 
the community when possible.

Do you have any guidelines about getting something better (a draft or 
links to ideas / papers?), I do have the possibility to mentor some 
students and this kind of subjects would be a perfect C++ / python 
project for them ...

Just my two cents :-)

Stéphane

-- 
Team Protein Design In Silico
UFIP, UMR 6286 CNRS, UFR Sciences et Techniques,
2, rue de la Houssinière, Bât. 25, Nantes cedex 03, France
Tél : +33 251 125 636 - Fax : +33 251 125 632
http://www.ufip.univ-nantes.fr/ - http://www.steletch.org


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

[Rdkit-discuss] Coot heading to Fedora

[Gianluca Sforna]

I just wanted to mention that coot (crystallographic macromolecular
building toolkit)[1] is the first package (at least, that I know of)
requiring rdkit as a dependency under review [2] to enter Fedora
repositories.

Regards

G.


[1] https://www2.mrc-lmb.cam.ac.uk/personal/pemsley/coot/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1359402

-- 
Gianluca Sforna

http://plus.google.com/+gianlucasforna - http://twitter.com/giallu
Tinker Garage - http://tinkergarage.it

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

Re: [Rdkit-discuss] GenerateDepictionMatching[23]DStructure (a bit off-topic)

[David Cosgrove]

As Greg says, this is a large area and somewhat of a diversion from my
original intention. All I was asking for was a set of test cases so I can
ensure that my port of the original Python code in AllChem.py to C++
behaves correctly. That seems like a sensible first step before embarking
on something more ambitious.

Dave

On Fri, 18 Nov 2016 at 08:17, Greg Landrum  wrote:

> This is a very big topic, and one where I would very much like to improve
> the RDKit. John Mayfield gave a great talk on the issues (and some ideas
> about fixing them based on his work with the CDK) at the UGM that some of
> you may find interesting :
>
> https://github.com/rdkit/UGM_2016/blob/master/Presentations/JohnMayfield_Depiction.pdf
>
> Fixing the larger problems is a *lot* of work and not something that is
> likely to happen quickly, but there is some low-hanging fruit (like cutting
> crossed bonds) that I ought to be able to do something about.[1]
>
> -greg
> [1] the trick is to avoid, as much as possible, creating drawings that
> look like Möbius strips.
> _
> From: Peter S. Shenkin 
> Sent: Thursday, November 17, 2016 11:23 PM
> Subject: Re: [Rdkit-discuss] GenerateDepictionMatching[23]DStructure (a
> bit off-topic)
> To: 
>
>
>
>
> On 17 Nov 2016, at 4:12 PM, Dimitri Maziuk  wrote:
>
> Philosophically speaking, there must exist molecules for which a legible
> 2D projection is simply not possible.
>
>
> Hi,
>
> I don't think that 2D projection of a 3D structure is an appropriate
> paradigm for 2D depiction, in general. I think of it as being more about 2D
> construction. I don't think camphor is a particularly difficult example,
> though, and I think that the hidden-line elimination (for lack of a better
> term) that Marvin does gives it a leg up on RDKit's representation.
>
> By the way, I do not think that Marvin is the best there is out there;
> it's just what I happen to have available for comparison.
>
> Stereochemistry adds complications, because 3D information has to be
> encoded in some way. Camphor (your suggestion) has a little of this. I gave
> Marvin a non-stereo SMILES and it picked an enantiomer. I drew the same
> enantiomer. I did not specify stereochemistry to RDKit, so, despite the
> visual confusion of the bond crossings, I suppose it's good that it didn't
> depict an explicit enantiomer.
>
> And labels add further complications. The two approaches I've seen for
> labels are using them as the atomic vertices, as RDKit does, and adding
> them adjacent to the vertices. I personally prefer the latter, because to
> my eye, it's easier to see the connectivity without being distracted by the
> labels.
>
> But my philosophical point was that different forms of 2D depiction work
> better for different purposes. Stéphane wants to see sugars drawn as
> carbohydrate chemists are used to seeing them. I would like to see the 2D
> connectivity as clearly as possible and would sacrifice some conventions
> for that purpose. And so on.
>
> -P.
>
>
>
>
> --
> ___
> 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] uff atomic partial charge

[Paolo Tosco]

Dear Rafal,

the RDKit UFF implementation does not include an electrostatic term.

Best regards,
Paolo

On 11/18/16 08:58, Rafal Roszak wrote:
> Hi all,
>
> How can I get atomic partial charged used by UFF? In original paper is
> stated that "Partial charges are obtained using the recently published
> QEq charge equilibration scheme" as described in
> http://pubs.acs.org/doi/pdf/10.1021/j100161a070. Is RDKit follow this
> scheme?
>
> Regards,
>
> Rafał
>
> --
> ___
> 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] uff atomic partial charge

[Rafal Roszak]

Hi all,

How can I get atomic partial charged used by UFF? In original paper is
stated that "Partial charges are obtained using the recently published
QEq charge equilibration scheme" as described in
http://pubs.acs.org/doi/pdf/10.1021/j100161a070. Is RDKit follow this
scheme?

Regards,

Rafał

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

Re: [Rdkit-discuss] GenerateDepictionMatching[23]DStructure (a bit off-topic)

[Greg Landrum]

This is a very big topic, and one where I would very much like to improve the 
RDKit. John Mayfield gave a great talk on the issues (and some ideas about 
fixing them based on his work with the CDK) at the UGM that some of you may 
find interesting 
:https://github.com/rdkit/UGM_2016/blob/master/Presentations/JohnMayfield_Depiction.pdf

Fixing the larger problems is a *lot* of work and not something that is likely 
to happen quickly, but there is some low-hanging fruit (like cutting crossed 
bonds) that I ought to be able to do something about.[1]
-greg[1] the trick is to avoid, as much as possible, creating drawings that 
look like Möbius strips.
_
From: Peter S. Shenkin 
Sent: Thursday, November 17, 2016 11:23 PM
Subject: Re: [Rdkit-discuss] GenerateDepictionMatching[23]DStructure (a bit 
off-topic)
To:  



On 17 Nov 2016, at 4:12 PM, Dimitri Maziuk  wrote:
Philosophically speaking, there must exist molecules for which a legible
2D projection is simply not possible.
Hi,
I don't think that 2D projection of a 3D structure is an appropriate paradigm 
for 2D depiction, in general. I think of it as being more about 2D 
construction. I don't think camphor is a particularly difficult example, 
though, and I think that the hidden-line elimination (for lack of a better 
term) that Marvin does gives it a leg up on RDKit's representation. 
By the way, I do not think that Marvin is the best there is out there; it's 
just what I happen to have available for comparison.
Stereochemistry adds complications, because 3D information has to be encoded in 
some way. Camphor (your suggestion) has a little of this. I gave Marvin a 
non-stereo SMILES and it picked an enantiomer. I drew the same enantiomer. I 
did not specify stereochemistry to RDKit, so, despite the visual confusion of 
the bond crossings, I suppose it's good that it didn't depict an explicit 
enantiomer.
And labels add further complications. The two approaches I've seen for labels 
are using them as the atomic vertices, as RDKit does, and adding them adjacent 
to the vertices. I personally prefer the latter, because to my eye, it's easier 
to see the connectivity without being distracted by the labels.
But my philosophical point was that different forms of 2D depiction work better 
for different purposes. Stéphane wants to see sugars drawn as carbohydrate 
chemists are used to seeing them. I would like to see the 2D connectivity as 
clearly as possible and would sacrifice some conventions for that purpose. And 
so on.
-P.



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