[Rdkit-discuss] Trouble with conda build in Docker

[Markus Sitzmann]

Hi (Riccardo).

I have trouble with the conda build in Docker (I just updated to the most
recent version which triggered the new build) - below is the error trace. I
took the original Docker file and just edited out all non-Python35 builds -
so it does only the Python35 builds and ends somewhere when
rdkit-postgres95 is built. Does somebody have the same problem?

Thanks,
Markus

make[3]: Entering directory
`/home/rdkit/bld/postgresql95_1491429385957/work/postgresql-9.5.2/src/port'
make -C ../backend submake-errcodes
make[3]: Entering directory
`/home/rdkit/bld/postgresql95_1491429385957/work/postgresql-9.5.2/src/backend/catalog'
cd ../../../src/include/catalog && /bin/sh ../../../config/missing perl
./duplicate_oids
make -C utils probes.h
***
ERROR: Perl is missing on your system. It is needed unless you are building
from an unmodified official distribution of PostgreSQL.
***
make[3]: Leaving directory
`/home/rdkit/bld/postgresql95_1491429385957/work/postgresql-9.5.2/src/backend/catalog'
make[3]: *** [postgres.bki] Error 1
make[2]: *** [submake-schemapg] Error 2
make[2]: *** Waiting for unfinished jobs
make[3]: Entering directory
`/home/rdkit/bld/postgresql95_1491429385957/work/postgresql-9.5.2/src/backend/utils'
sed -f ./Gen_dummy_probes.sed probes.d >probes.h
make[3]: Leaving directory
`/home/rdkit/bld/postgresql95_1491429385957/work/postgresql-9.5.2/src/backend/utils'
make[4]: Entering directory
`/home/rdkit/bld/postgresql95_1491429385957/work/postgresql-9.5.2/src/backend'
make[4]: Nothing to be done for `submake-errcodes'.
make[4]: Leaving directory
`/home/rdkit/bld/postgresql95_1491429385957/work/postgresql-9.5.2/src/backend'
make[3]: Leaving directory
`/home/rdkit/bld/postgresql95_1491429385957/work/postgresql-9.5.2/src/port'
make -C ../../src/common all
make[3]: Entering directory
`/home/rdkit/bld/postgresql95_1491429385957/work/postgresql-9.5.2/src/common'
make -C ../backend submake-errcodes
make[4]: Entering directory
`/home/rdkit/bld/postgresql95_1491429385957/work/postgresql-9.5.2/src/backend'
make[4]: Nothing to be done for `submake-errcodes'.
make[4]: Leaving directory
`/home/rdkit/bld/postgresql95_1491429385957/work/postgresql-9.5.2/src/backend'
make[3]: Leaving directory
`/home/rdkit/bld/postgresql95_1491429385957/work/postgresql-9.5.2/src/common'
make[2]: Leaving directory
`/home/rdkit/bld/postgresql95_1491429385957/work/postgresql-9.5.2/src/backend'
make[1]: *** [all-backend-recurse] Error 2
make[1]: Leaving directory
`/home/rdkit/bld/postgresql95_1491429385957/work/postgresql-9.5.2/src'
make: *** [all-src-recurse] Error 2
Traceback (most recent call last):
  File "/home/rdkit/miniconda/bin/conda-build", line 6, in 
 path in binary file share/terminfo/w/wsvt25
Detected hard-coded path in binary file share/terminfo/w/wsvt25m
Detected hard-coded path in binary file share/terminfo/x/x68k
Detected hard-coded path in binary file share/terminfo/x/x68k-ite
Detected hard-coded path in binary file share/terminfo/z/z29a
Detected hard-coded path in binary file share/terminfo/z/z29a-kc-bc
Detected hard-coded path in binary file share/terminfo/z/z29a-kc-uc
Detected hard-coded path in binary file share/terminfo/z/z29a-nkc-bc
Detected hard-coded path in binary file share/terminfo/z/z29a-nkc-uc
Detected hard-coded path in binary file share/terminfo/z/z340
Detected hard-coded path in binary file share/terminfo/z/z340-nam
Detected hard-coded path in text file bin/ncurses6-config
Detected hard-coded path in text file share/man/man1/captoinfo.1m
Detected hard-coded path in text file share/man/man1/infocmp.1m
Detected hard-coded path in text file share/man/man1/infotocap.1m
Detected hard-coded path in text file share/man/man1/ncurses6-config.1
Detected hard-coded path in text file share/man/man1/tic.1m
Detected hard-coded path in text file share/man/man1/toe.1m
Detected hard-coded path in text file share/man/man1/tput.1
Detected hard-coded path in text file share/man/man1/tset.1
Detected hard-coded path in text file share/man/man3/ncurses.3x
Detected hard-coded path in text file share/man/man3/panel.3x
Detected hard-coded path in text file share/man/man5/term.5
Detected hard-coded path in text file share/man/man5/terminfo.5
Detected hard-coded path in text file share/man/man7/term.7
/home/rdkit/bld/linux-64/ncurses-6.0-0.tar.bz2
Nothing to test for: /home/rdkit/bld/linux-64/ncurses-6.0-0.tar.bz2
BUILD START: postgresql95-9.5.2-py35_0

The following NEW packages will be INSTALLED:

libiconv:   1.14-0
libxml2:2.9.4-0
libxslt:1.1.29-0
ncurses:6.0-0 local
openssl:1.0.2k-1
pip:9.0.1-py35_1
python: 3.5.3-1
readline:   6.2-2
setuptools: 27.2.0-py35_0
sqlite: 3.13.0-0
tk: 8.5.18-0
wheel:  0.29.0-py35_0
xz: 5.2.2-1
zlib:   1.2.8-3

Source cache directory is: /home/rdkit/bld/src_cache
Downloading source to cache: postgresql-9.5.2.tar.bz2
Downloading

Re: [Rdkit-discuss] forcing better depictions for macrocycles

[Curt Fischer]

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 
wrote:

> Hi Curt,
>
>
> On Tue, Apr 4, 2017 at 12:03 PM, Curt Fischer 
> wrote:
>
>>
>> RDKit's default 2D-depictions of macrocycles are very "round".  I found
>> some slides
>> 
>>  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

[Rdkit-discuss] ChEMBL technical internships

[Michał Nowotka]

Hi,

Most of you know ChEMBL DB so if you want to make this resource even
better, please share information about our technical internships:

http://chembl.blogspot.co.uk/2017/04/technical-internships-at-chembl.html

Cheers,

Michał

--
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] forcing better depictions for macrocycles

[Greg Landrum]

To answer a question from the notebook: the best way I can think of at the
moment to match a 14 ring with SMARTS is:
ring14smarts = '*@1 '+ '@*'*12 + '@*@1'

The "@"s are the most compact way to express the bond queries. If you leave
them out then the query will only match single or aromatic bonds.

-greg
--
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] forcing better depictions for macrocycles

[Greg Landrum]

Hi Curt,


On Tue, Apr 4, 2017 at 12:03 PM, Curt Fischer 
wrote:

>
> RDKit's default 2D-depictions of macrocycles are very "round".  I found
> some slides
> 
>  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