Thanks to Greg for the feedback.

One more follow-up question: it seems that *Compute2DCoords()* offers an
argument *coordMap* which is a dictionary of the format {int:
rdkit.Geometry.rdGeometry.Point2D}, where int is an atom index.
It seems like this is a way to fix certain atoms in a predefined position,
so that only non-specified atoms can float during *Compute2DCoords()*.
Thus it seems like a "polishing" step for depictions would be to use this
function  after aligning to a template, fixing the template-associated
atoms in place and letting any non-templated atoms float.

What's the easiest way to get an appropriately formatted *coordMap*
dictionary?

I tried something like this:

my_dict = {idx: mol.GetConformer(0).GetAtomPosition(idx) for idx in atom_list}
AllChem.Compute2DCoords(radicicol, coordMap = my_dict)


But it seems that *GetAtomPosition(idx)*returns *Point3D* objects instead
of Point2D objects, so I'm not sure how I can get *Point2D* objects.

Help appreciated!

Curt

On Wed, Apr 5, 2017 at 12:38 AM, Greg Landrum <greg.land...@gmail.com>
wrote:

> Hi Curt,
>
>
> On Tue, Apr 4, 2017 at 12:03 PM, Curt Fischer <curt.r.fisc...@gmail.com>
> wrote:
>
>>
>> RDKit's default 2D-depictions of macrocycles are very "round".  I found
>> some slides
>> <https://www.slideshare.net/NextMoveSoftware/rdkit-ugm-2016-higher-quality-chemical-depictions>
>>  from
>> John Mayfield that come from a 2016 UK RDKit user group meeting that says
>> the same thing.  (See in particular slide 31.)
>>
>
> Yes, they are indeed very round and non-chemical.
>
>
>>
>> I'm wondering, what is the best way of forcing RDKit's depictions of
>> these types of molecules to be less round?  (And I'm aware that a possible
>> answer is, "there isn't a good way yet".)
>>
>
> I'm afraid the answer is "there isn't a good way yet". I do really hope
> that this answer will change in a not-too-distant release, but I cannot
> promise anything.
>
> In a Jupyter notebook, I (hopefully) illustrate three approaches: (i) just
>> importing an .sdf of your molecules from somewhere else, (ii) aligning to a
>> non-macrocyclic substructure, and (iii) using the TemplateAlign module.
>> https://github.com/tentrillion/ipython_notebooks/blob/
>> master/force_pretty_macrocycles.ipynb
>>
>>
> I think you hit on everything that's currently possible here. Using a
> template to organize the atoms of the macrocycle, like you do to produce
> outputs 8 and 11, seems to me like the strategy that's most likely to work.
> It's unfortunate that it doesn't. My normal answer to this kind of
> situation is "it's a hard problem and the code does what it can. Changing
> the algorithm is a lot of work.", but those particular pathologies almost
> look like bugs, not algorithmic deficiencies. I will take a look to see I
> can track down what's causing that.
>
> -greg
>
>
>
>
>> What approaches did I miss?  What should I be doing?
>>
>> 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

Reply via email to