Code Monkey home page Code Monkey logo

coordgenlibs's Introduction

CoordgenLibs

Azure_Build_Status

This is Schrödinger, Inc's 2D coordinate generation. It was formerly proprietary code, but is now released under the BSD license. The emphasis of these algorithms are on quality of 2D coordinates rather than speed of generation. The algorithm distinguishes itself from many others by doing well with both macrocycles and metal complexes. It also does extremely well on typical drug-like small molecules, and has been validated on millions of compounds.

Schrodinger intends to continue to contribute to this code as it still uses it inside its products, but will also be happy if others contribute pull-requests when there are improvements they would like to make. We'll also be happy to hear bug reports or feature requests from use of this code, though make no guarantee on our ability to process these.

Documentation

Examples and documentation will be added/improved over time

Templates

Coordgen uses templates for some macrocycle systems. The source for the templates is templates.mae. If you're an end user of coordgen, you can add local templates in a file called user_templates.mae in a directory specified by CoordgenTemplates::setTemplateDir(). If you want to update the templates, add new templates to templates.mae and run mol_generator.py to generate the source files.

Usage example

Code for a sample executable is provided in the example_dir directory. Building the example executable is enabled by default, but can be disabled by means of the COORDGEN_BUILD_EXAMPLE option.

Automated Testing

Automated testing is still primarily taking place inside Schrodinger's internal build system, although tests are incrementally being added to the testing directory. Building the tests is enabled by default, but can be disabled by means of the COORDGEN_BUILD_TESTS option.

Memory debugging is, by default, configured to use valgrind. It can be run on the tests by passing -DCMAKE_BUILD_TYPE=Debug to cmake, to enable building the debugging symbols, and then using ctest -T memcheck inside the build directory.

Building from source

Requirements

To build coordgen, you will need to have the following installed in your system:

  • CMake version 3.2 or later.
  • The development files for the Boost libraries. At least the iostreams and regex components are required. In case of also building the unit tests, the filesystems and unit_test_framework components will also be required.
  • A C++ compiler supporting the C++11 standard.
  • A compiled instance of the maeparser library or its source code.

In case maeparser is not available on your system, neither as a compiled library or as source code, if a working git executable and an internet connection are available, the builder can automatically download the source and build maeparser for you.

Building

  1. Create a build directory inside the the one that contains Coordgen, and move into it:

    mkdir build
    cd build
  2. Run cmake to configure the build, passing the path to the directory where the sources are located (just .. if you created build inside the sources directory). At this point, you should add any required flags to the cmake command. Check the 'Options' section in CMakeLists.txt to see which options are available.

    cmake .. -Dmaeparser_DIR=/home/schrodinger/maeparser_install -DCMAKE_INSTALL_PREFIX=/home/schrodinger/coordgen_install`

    A few notes on the maeparser dependency:

    • CMake will, by default, search your system's default library paths for the maeparser library. If a CMAKE_INSTALL_PREFIX was specified to Coordgen, CMake will also search for maeparser there.

    • If you already built and installed maeparser using the CMAKE_INSTALL_PREFIX to set the installation path, you should pass the exact same path to Coordgen with maeparser_DIR.

    • If CMake cannot find a compiled library for maeparser, it will attempt to download the source code from GitHub and build it. The release to be downloaded if the library is not found can be set using the -DMAEPARSER_VERSION flag. The sources will be stored in a directory named like maeparser-{MAEPARSER_VERSION} under the coordgen sources.

    • If maeparser_DIR was passed to CMake, and the library was not found, CMake will NOT download the sources from GitHub (since we expected to find a compiled library).

    • If a copy of maeparser's source is found under the proper path, it be used, instead of being downloaded again.

    • If you want to use Coordgen in a CMake project that also depends on maeparser, set up the maeparser first, as Coordgen will be able to find and use it, without searching for further libraries or compiling it again from the source code.

  3. Build and install:

    make -j install

coordgenlibs's People

Contributors

antonio-rojas avatar cdvonbargen avatar christopheryoung avatar d-b-w avatar e-kwsm avatar greglandrum avatar jarrettsjohnson avatar lorton avatar peter-levine avatar rachelnwalker avatar ricrogz avatar smoe avatar torcolvin avatar zontanicola avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

coordgenlibs's Issues

How to contribute in your repository

Hey, I am new to this community and gsoc and I am struggling with how to start contributions.
Can Someone please help me and I am sorry if I have raised an issue in the wrong place?

NaN coordinates crash coordgen

Related to : rdkit/rdkit#4845 (@greglandrum) and #106

On arm64 only (this doesn't happen on amd64), we see failures in
sketcherMinimizerAtom::clockwiseOrderedNeighbors (in sketcherMinimizerAtom)
where sketcherMinimizerMaths::signedAngle returns NaN but this method can't handle it.
What happens is that the loop doesn't trigger the if that sets lastPoppedIndex so it keeps the value to its previous one.

when the value was 1, and neighs only has one element left, it tries to delete an element out of the vector. And when the glibc destructor hits at the exit of the function we get a
"double free or corruption (out)".

By resetting lastPoppedIndex to 0 before that loop, we avoid the issue and the tests pass (at least the rdkit ones).

while (neighs.size()) {
        float smallestAngle = 361;
        lastPoppedIndex = 0;
        for (unsigned int i = 0; i < neighs.size(); i++) {
            float newAngle = sketcherMinimizerMaths::signedAngle(
                lastPoppedAtom->coordinates, coordinates,
                neighs[i]->coordinates);
            if (newAngle < 0) {
                newAngle += 360;
            }
            if (newAngle < smallestAngle) {
                smallestAngle = newAngle;
                lastPoppedIndex = i;
            }
        }
        lastPoppedAtom = neighs[lastPoppedIndex];
        orderedNeighs.push_back(lastPoppedAtom);
        neighs.erase(neighs.begin() + lastPoppedIndex);
    }

We could also check for NaN and set to 0 in that specific case.

I can make a PR if you think that's a viable solution.

Segfault within coordgen for molecule

This one was reported by @lucasmorin222 in the RDKit tracker (rdkit/rdkit#4845), but I've confirmed that it's a coordgen problem.

I don't have a straight reproducible for coordgen, but this bit of C++ using RDKit+Coordgen results in a segfault:

    auto m1 = "C1C=CC=C2C1=CSC=C3C(=O)OOOC(=O)C(=CC(=O)N3)OC2=O"_smiles;
    CoordGen::addCoords(*m1);

The crash occurs here:
https://github.com/schrodinger/coordgenlibs/blob/master/sketcherMinimizerAtom.cpp#L377
because lastPoppedIndex is 1 and neighs.size() is 1.

I'll do a PR.

Please provide cmake files for build support

RDKit uses coordgenlibs these days, though by default downloads and builds it itself.

Linux distributions like Debian/Ubuntu already ship coorgenlibs, but RDKit cannot find the system-installed version due to find_package(coordgen MODULE) not finding anything as there are no CMake files available and/or being installed.

So please ship cmake files.

Undefined Reference in Libcoordgen

Hello, I received the below error in the libcoordgen.so.1 file when attempting to compile Rdkit from scratch (both recent versions 2019_3 and 2020_3) and using both v1.2.4 of maeparser and v1.4.2 of coordgenlibs. I would also receive an error when using the earlier 2019_1 rdkit version in python with from rdkit import Chem Rolling back to maeparser v1.2.3 appeared to fix the issue within libcoordgen. Just rolling back coordgenlibs, did not fix the issue however.

undefined reference to schrodinger::mae::Block::getIndexedBlock(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)'`

Just for completeness I am running Arch Linux and am willing to provide any more information upon request.

1.3.1 fails to configure with maeparser-1.2.1

-- Found Boost: /usr/local/include (found version "1.71.0") found components:  iostreams regex
CMake Error at CMakeLists.txt:25 (find_package):
  By not providing "Findmaeparser.cmake" in CMAKE_MODULE_PATH this project
  has asked CMake to find a package configuration file provided by
  "maeparser", but CMake did not find one.

  Could not find a package configuration file provided by "maeparser" with
  any of the following names:

    maeparserConfig.cmake
    maeparser-config.cmake

  Add the installation prefix of "maeparser" to CMAKE_PREFIX_PATH or set
  "maeparser_DIR" to a directory containing one of the above files.  If
  "maeparser" provides a separate development package or SDK, be sure it has
  been installed.

FreeBSD 12

How do we properly convey chirality & stereochemistry?

Hello!

I am using coordgenlibs in order to draw a known 3D structure in 2D. Prior to converting to 2D, I establish the R/S and Z/E markers on the molecule. However, it is unclear how to pass this information on to coordgen. I have tried two approaches. First, the obvious, which is setting, for chiral atoms, hasStereochemistrySet = true and isR = true/false; and for stereo bonds, isZEActive/isZ. When this didn't do as I expected, I tried using the lower-level routines setStereoChemistry(my chirality info)/setAbsoluteStereoChemsitryFromChiralityInfo() and corresponding for bonds. The latter reasoning being that perhaps just saying something is R/S/Z/E isn't enough given that we would have to have a matching CIP rule system. At any rate, neither of these methods did what I expected.

As an example, I'm having trouble with this molecule:
VS248

which can be visualized in 3D here:
https://chemapps.stolaf.edu/jmol/jsmol/cip.htm?load=https://cipvalidationsuite.github.io/ValidationSuite/mol3d/VS248.sdf

When I convert this to 2D using coordgenlibs, it expects a dash, not a wedge, to be present in the C4-C6 bond, in order to preserve the S chirality. The reason this happens is that it switches the C1 and C2 ring atoms, which have a different CIP priority order. It is not clear to me how to properly convey this information so that it draws the atoms in the same relative positions.

I am probably not explaining this very well, but essentially I am looking for some instruction on how one is supposed to pass on the chirality information of a molecule, eg if you were reading from full smiles or a 3D coordinate structure. Thanks for any help you can give me!

Failed to build test_coordgen on static mode

How to reproduce:

  1. Build static maeparser, and install on ../libmaeparser-1.2.4-220427
  2. Clone current repository.
  3. Create some build directory and chdir into it.
  4. Run following command to configure and build:
    cmake \ -DCMAKE_INSTALL_PREFIX=../coordgenlibs-3.0.0-220427 \ -DCOORDGEN_BUILD_SHARED_LIBS=OFF \ -Dmaeparser_DIR=../libmaeparser-1.2.4-220427 \ ../coordgenlibs
    cmake --build . --config Release -j

Expected behavior:

  • The build process should be complete without any errors.

Actual result:

How to fix:

  • Apply following patch. It appends missing Boost::iostreams and libz dependency on building test_coordgen. Thanks to github's file extension check.
    add-missing-deps.patch.txt

Bad coordinates for some very ring-y structures

This issue: rdkit/rdkit#3491 reports that coordgen gives pretty bad coordinates (lots of clashes or very long bonds) for a couple of molecules.

from rdkit import Chem
from rdkit.Chem import rdDepictor
from rdkit.Chem.Draw import IPythonConsole
# following SMILES seems good without SetPreferCoordGen option.
smi = 'C12CC3CC(CC3C1)C2'
ring = Chem.MolFromSmiles(smi)
rdDepictor.SetPreferCoordGen(False)
ring

ring = Chem.MolFromSmiles(smi)
rdDepictor.SetPreferCoordGen(False)
ring

looks like:
bad1

Another example:

 from rdkit.Chem import rdDepictor
 from rdkit.Chem import rdCoordGen
 
def get_image(smiles):
 mol = Chem.MolFromSmiles(smiles, sanitize=True)
 rdDepictor.SetPreferCoordGen(True)
 rdCoordGen.AddCoords(mol)
 rdDepictor.Compute2DCoords(mol)
 return mol

molec = 'C1=CC=C(N(C2=CC=CC=C2)C2=CC3=C4B(C5=CC=CC=C5N3C3=CC=CC=C3)C3=C(C=C5C(=C3)B3C6=C(C=CC=C6)N(C6=CC=CC=C6)C6=CC(N(C7=CC=CC=C7)C7=CC=CC=C7)=CC(=C36)N5C3=CC=CC=C3)N(C3=CC=CC=C3)C4=C2)C=C1'
m = get_image(molec)
m

bad2

This is tracked in schrodinger's internal bug tracker as https://jira.schrodinger.com/browse/CRDGEN-271

errors using v3.0.0 with the RDKit master

I just tried building the RDKit master against v3.0.0 and things don't look good.

Everything compiles without complaint, but when running the RDKit tests I encounter problems.

Here's what I get for a standard release build:

(base) glandrum@Badger:/scratch/RDKit_git/build$ ./External/CoordGen/testCoordGen 
[10:04:36] -------------------------------------
[10:04:36] test2: using templates
*** stack smashing detected ***: terminated
Aborted (core dumped)

That's an awesome runtime error (and one I hadn't seen before), but it's probably not intended behavior. ;-)

When built in debug mode that particular test passes, but then I get a seg fault in the test which attempts to use the minimizeOnly mode (the seg fault itself is at this line: https://github.com/rdkit/rdkit/blob/master/External/CoordGen/CoordGen.h#L226). I guess it's probably expected that we'd need to update this on the RDKit side, but it doesn't seem like I should be able to trigger a seg fault like this.

Really slow performance with some macrocycles

We found an issue when using coordgen with rdkit.
When activating coordgen, it is extremely slow to work with such chiral macrocycles.
Removing the chirality from the atoms makes it fast again.

(roughly 100 times slower for the given molecule).

from rdkit.Chem import rdDepictor
from rdkit import Chem

### This is slow
rdDepictor.SetPreferCoordGen(True)
mol = Chem.MolToMolBlock(Chem.MolFromSmiles("C[C@@H]1CCCCCCCCC(=O)OCCN[C@H](C)CCCCCCCCC(=O)OCCN[C@H](C)CCCCCCCCC(=O)OCCN1"))

### This is fast
rdDepictor.SetPreferCoordGen(False)
mol = Chem.MolToMolBlock(Chem.MolFromSmiles("C[C@@H]1CCCCCCCCC(=O)OCCN[C@H](C)CCCCCCCCC(=O)OCCN[C@H](C)CCCCCCCCC(=O)OCCN1"))

This is a crossposted issue with rdkit rdkit/rdkit#5813

sketcherMinimizer::clear() doesn't completely reset the object

Some of the vectors of pointers which are members of the sketcherMinimizer class that get populated either by the initialize() method, or during coordinate generation do not get emptied by the clear() method. The objects that these pointers reference do get deleted during the cleanup, but the pointers still exist, and are therefore in an invalid state.

This is not caught by the current (mem) tests because the "SampleTest" test case that is in place in this repository only works on a single molecule, so that the sketcherMinimizer does not get reused and that the invalid pointers are never hit.

This can be fixed, apparently, by adding the following at the end of the clear() method:

    _atoms.clear();
    _bonds.clear();
    _residueInteractions.clear();
    _independentFragments.clear();

    m_proximityRelations.clear();

I'm not sure, though, if clearing these is intentionally omitted, or whether doing it would break any other functionality. Also, I don't know if the other members, m_fragmentBuilder and m_minimizer, also require clearing.

Distorted depiction

I found a combination of ring systems that yields a distorted depiction:

from rdkit import Chem
from rdkit.Chem import rdDepictor

rdDepictor.SetPreferCoordGen(True)
Chem.MolFromSmiles("CC1C2CCC1CC(c1cccc3cc(-c4ccc5cccc(S)c5c4)sc13)C2")

image

Interestingly, removing either the methyl or the thiol groups yields a non-distorted depiction.

Fix strategy for searching conformations in bridged ring systems

In #98, we disabled CoordgenFlipRingDOF. CoordgenFlipRingDOF was intended to swap between structures like the ones here below, in case for instance there were substituents on the nitrogen.

121490593-76022080-c9d5-11eb-9acc-56247ff57654

But the way it was implemented didn't work. We should reactivate this DOF and make sure that it works.

Coordgen is slower than RDKit's native 2d coordinate generation

Coordgen is slower than RDKit's native 2d coordinate generation. Average speeds are about 100x slower, and in the worse cases, coordgen can take multiple seconds.

The two tools don't do the same things, and I think that coordgen results are much better, so the comparison is not totally fair. I do think that that coordgen should target being able to consistently produce coordinates in less than 0.1s, and have averages closer to 0.001s. This will allow us to discuss making coordgen the default in RDKit, which would be cool.

I'm going to link to the internal Schrödinger bug tracker, and our internal display for performance testing below, sorry...

At the time I post this, our automated performance testing says that:

2d coordinate generator Average speed (s) Slowest (s) Count > 0.1s Count > 1s
RDKit native 0.00035 0.04 0 0
coordgen 0.028 3.9 17 235

License?

Found the repo - looks interesting for a few reasons.. is there a license for the code?

rdCoordGen.AddCoords returning empty conformer for large system

Originally reported here

I do not have a standalone example for this failure, but the coordgen call made by RDKit in this case is returning an empty conformer.

mol = MolFromSmiles('OC[C@H]1O[C@@H](n2cnc3c(=O)[nH]c(N)nc23)C[C@@H]1OP(=S)(O)OC[C@H]1O[C@@H](n2ccc(N)nc2=O)C[C@@H]1OP(=S)(O)OC[C@H]1O[C@@H](n2cnc3c(=O)[nH]c(N)nc23)C[C@@H]1OP(=S)(O)OC[C@H]1O[C@@H](n2cc(C)c(=O)[nH]c2=O)C[C@@H]1OP(=S)(O)OC[C@H]1O[C@@H](n2cc(C)c(=O)[nH]c2=O)C[C@@H]1OP(=S)(O)OC[C@H]1O[C@@H](n2cc(C)c(=O)[nH]c2=O)C[C@@H]1OP(=S)(O)OC[C@H]1O[C@@H](n2cnc3c(=O)[nH]c(N)nc23)C[C@@H]1OP(=S)(O)OC[C@H]1O[C@@H](n2ccc(N)nc2=O)C[C@@H]1OP(=S)(O)OC[C@H]1O[C@@H](n2cc(C)c(=O)[nH]c2=O)C[C@@H]1OP(=S)(O)OC[C@H]1O[C@@H](n2ccc(N)nc2=O)C[C@@H]1OP(=S)(O)OC[C@H]1O[C@@H](n2cc(C)c(=O)[nH]c2=O)C[C@@H]1OP(=S)(O)OC[C@H]1O[C@@H](n2cc(C)c(=O)[nH]c2=O)C[C@@H]1OP(=S)(O)OC[C@H]1O[C@@H](n2ccc(N)nc2=O)C[C@@H]1OP(=S)(O)OC[C@H]1O[C@@H](n2cc(C)c(=O)[nH]c2=O)C[C@@H]1OP(=S)(O)OC[C@H]1O[C@@H](n2cc(C)c(=O)[nH]c2=O)C[C@@H]1OP(=S)(O)OC[C@H]1O[C@@H](n2ccc(N)nc2=O)C[C@@H]1OP(=S)(O)OC[C@H]1O[C@@H](n2cc(C)c(=O)[nH]c2=O)C[C@@H]1OP(=S)(O)OC[C@H]1O[C@@H](n2cc(C)c(=O)[nH]c2=O)C[C@@H]1OP(=S)(O)OC[C@H]1O[C@@H](n2cnc3c(=O)[nH]c(N)nc23)C[C@@H]1OP(=S)(O)OC[C@H]1O[C@@H](n2ccc(N)nc2=O)C[C@@H]1OP(=S)(O)OC[C@H]1O[C@@H](n2cnc3c(=O)[nH]c(N)nc23)C[C@@H]1O')
rdCoordGen.AddCoords(mol)

for x in range(5):
    pos = mol.GetConformer().GetAtomPosition(x)
    print(pos.x, pos.y, pos.z)

0.0 0.0 0.0
0.0 0.0 0.0
0.0 0.0 0.0
0.0 0.0 0.0
0.0 0.0 0.0

Obviously this molecule is large and difficult to lay out in 2D, but I would have expected AddCoords to indicate failure somehow.

>>>from rdkit import rdBase
>>>rdBase.rdkitVersion

 "2021.03.1"

Norbornane not rendering with a template

It looks like templates either aren't being used with the version of coordgen that the RDKit is using (v1.3.2) or norbornane isn't in the template file (which seems unlikely):
image

Are we doing something wrong here or is there a coordgenlibs problem?

Some coordgen templates don't match themselves

There are some coordgen templates that don't match themselves! If I import the coordgen templates.mae file into Maestro and display the structures in the 2D viewer, the 2D view clearly doesn't match the input template.

This affects templates (0 indexed):

 [1, 8, 19, 20, 22, 43, 53, 65, 66, 67]

Here's an example. White is the coordinates generated by coordgen, black is the template structure:

coordgen_bad_template

Furthermore, some of the templates match other templates instead of themselves! This means that that some templates will never be used, and so only part of the template is actually honored. This affects templates (0 indexed):

[18, 27]

Poor result for constrained coord generation in rapamycin derivative.

Hi,
I am calling CoordGen via RDKit, and have had a problem with constrained generation of coords for a rapamycin analogue using rapamycin as the template. The discussion is here: rdkit/rdkit#4994 (reply in thread). It was suggested that I file a bug report here. I hope the cross-link is a suitable way of doing it. I used the SMARTS string [#6]1(-[#6]2(-[#6](-[#6]-[#6]-[#6](-[#8]-2)-[#6]-[#6](-[#6](-[#6])=[#6]-[#6]=[#6]-[#6]=[#6]-[#6](-[#6])-[#6]-[#6](-[#6](-[#6](-[#6](-[#6](=[#6]-[#6](-[#6](-[#6]-[#6](-[#8]-[#6](-[#6]2-[#7](-[#6]-1=[#8])-[#6]-[#6]-[#6]-[#6]-2)=[#8])-[#6](-[#6])-[#6]-[#6]1-[#6]-[#6]-[#6](-[#6](-[#6]-1)-[#8]-[#6])-[#8])=[#8])-[#6])-[#6])-[#8])-[#8]-[#6])=[#8])-[#6])-[#8]-[#6])-[#6])-[#8])=[#8] as the reference pattern, which is that RDKit returns for the MCS for the two structures.
It's worth saying, I think, that the CoordGen algorithm lays out macrocycles like this way better than any other toolkit I've seen.

Error in GLIBC

Hi, my system is CentOS7. when I install the coordgen, there is an error as follows:

make -j install

[ 85%] Building CXX object example_dir/CMakeFiles/example.dir/example.cpp.o
[ 90%] Linking CXX executable example
/NAS/lh/software/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: /NAS/lh/software/miniconda3/lib/libstdc++.so: undefined reference to `aligned_alloc@GLIBC_2.16'
/NAS/lh/software/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: /NAS/lh/software/miniconda3/lib/libstdc++.so: undefined reference to `clock_gettime@GLIBC_2.17'
collect2: error: ld returned 1 exit status
make[2]: *** [example_dir/example] Error 1
make[1]: *** [example_dir/CMakeFiles/example.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 95%] Linking CXX executable test_smilesparser
/NAS/lh/software/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: CMakeFiles/test_smilesparser.dir/test_smilesparser.cpp.o: in function `boost::unit_test::make_test_case(boost::function<void ()> const&, boost::unit_test::basic_cstring<char const>, boost::unit_test::basic_cstring<char const>, unsigned long)':
test_smilesparser.cpp:(.text._ZN5boost9unit_test14make_test_caseERKNS_8functionIFvvEEENS0_13basic_cstringIKcEES8_m[_ZN5boost9unit_test14make_test_caseERKNS_8functionIFvvEEENS0_13basic_cstringIKcEES8_m]+0x38): undefined reference to `boost::unit_test::ut_detail::normalize_test_case_name[abi:cxx11](boost::unit_test::basic_cstring<char const>)'
/NAS/lh/software/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: /usr/local/boost/lib/libboost_unit_test_framework.so.1.79.0: undefined reference to `memcpy@GLIBC_2.14'
/NAS/lh/software/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: /NAS/lh/software/miniconda3/lib/libstdc++.so: undefined reference to `aligned_alloc@GLIBC_2.16'
/NAS/lh/software/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: /NAS/lh/software/miniconda3/lib/libstdc++.so: undefined reference to `clock_gettime@GLIBC_2.17'
collect2: error: ld returned 1 exit status
make[2]: *** [test/test_smilesparser] Error 1
make[1]: *** [test/CMakeFiles/test_smilesparser.dir/all] Error 2
[100%] Linking CXX executable test_coordgen
/NAS/lh/software/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: CMakeFiles/test_coordgen.dir/test_coordgen.cpp.o: in function `boost::unit_test::make_test_case(boost::function<void ()> const&, boost::unit_test::basic_cstring<char const>, boost::unit_test::basic_cstring<char const>, unsigned long)':
test_coordgen.cpp:(.text._ZN5boost9unit_test14make_test_caseERKNS_8functionIFvvEEENS0_13basic_cstringIKcEES8_m[_ZN5boost9unit_test14make_test_caseERKNS_8functionIFvvEEENS0_13basic_cstringIKcEES8_m]+0x38): undefined reference to `boost::unit_test::ut_detail::normalize_test_case_name[abi:cxx11](boost::unit_test::basic_cstring<char const>)'
/NAS/lh/software/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: CMakeFiles/test_coordgen.dir/test_coordgen.cpp.o: in function `mol_from_mae_block(schrodinger::mae::Block&)':
test_coordgen.cpp:(.text._Z18mol_from_mae_blockRN11schrodinger3mae5BlockE+0x84): undefined reference to `schrodinger::mae::Block::getIndexedBlock(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/NAS/lh/software/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: test_coordgen.cpp:(.text._Z18mol_from_mae_blockRN11schrodinger3mae5BlockE+0x600): undefined reference to `schrodinger::mae::Block::getIndexedBlock(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/NAS/lh/software/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: CMakeFiles/test_coordgen.dir/test_coordgen.cpp.o: in function `ClearWedgesTest::test_method()':
test_coordgen.cpp:(.text._ZN15ClearWedgesTest11test_methodEv+0xdd): undefined reference to `schrodinger::mae::Reader::Reader(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long)'
/NAS/lh/software/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: test_coordgen.cpp:(.text._ZN15ClearWedgesTest11test_methodEv+0x10b): undefined reference to `schrodinger::mae::Reader::next(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/NAS/lh/software/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: CMakeFiles/test_coordgen.dir/test_coordgen.cpp.o: in function `testMinimizedRingsShape::test_method()':
test_coordgen.cpp:(.text._ZN23testMinimizedRingsShape11test_methodEv+0xdd): undefined reference to `schrodinger::mae::Reader::Reader(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long)'
/NAS/lh/software/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: test_coordgen.cpp:(.text._ZN23testMinimizedRingsShape11test_methodEv+0x10b): undefined reference to `schrodinger::mae::Reader::next(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/NAS/lh/software/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: CMakeFiles/test_coordgen.dir/test_coordgen.cpp.o: in function `testGetDoubleBondConstraints::test_method()':
test_coordgen.cpp:(.text._ZN28testGetDoubleBondConstraints11test_methodEv+0x103): undefined reference to `schrodinger::mae::Reader::Reader(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long)'
/NAS/lh/software/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: test_coordgen.cpp:(.text._ZN28testGetDoubleBondConstraints11test_methodEv+0x131): undefined reference to `schrodinger::mae::Reader::next(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/NAS/lh/software/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: CMakeFiles/test_coordgen.dir/test_coordgen.cpp.o: in function `SampleTest::test_method()':
test_coordgen.cpp:(.text._ZN10SampleTest11test_methodEv+0xe0): undefined reference to `schrodinger::mae::Reader::Reader(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long)'
/NAS/lh/software/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: test_coordgen.cpp:(.text._ZN10SampleTest11test_methodEv+0x10e): undefined reference to `schrodinger::mae::Reader::next(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/NAS/lh/software/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: CMakeFiles/test_coordgen.dir/test_coordgen.cpp.o: in function `DisableMetalZOBs::test_method()':
test_coordgen.cpp:(.text._ZN16DisableMetalZOBs11test_methodEv+0xe0): undefined reference to `schrodinger::mae::Reader::Reader(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long)'
/NAS/lh/software/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: test_coordgen.cpp:(.text._ZN16DisableMetalZOBs11test_methodEv+0x10e): undefined reference to `schrodinger::mae::Reader::next(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/NAS/lh/software/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: CMakeFiles/test_coordgen.dir/test_coordgen.cpp.o: in function `terminalMetalZOBs::test_method()':
test_coordgen.cpp:(.text._ZN17terminalMetalZOBs11test_methodEv+0xe0): undefined reference to `schrodinger::mae::Reader::Reader(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long)'
/NAS/lh/software/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: test_coordgen.cpp:(.text._ZN17terminalMetalZOBs11test_methodEv+0x10e): undefined reference to `schrodinger::mae::Reader::next(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/NAS/lh/software/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: CMakeFiles/test_coordgen.dir/test_coordgen.cpp.o: in function `TemplateTest::test_method()':
test_coordgen.cpp:(.text._ZN12TemplateTest11test_methodEv+0x1ca): undefined reference to `schrodinger::mae::Reader::Reader(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long)'
/NAS/lh/software/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: test_coordgen.cpp:(.text._ZN12TemplateTest11test_methodEv+0x2ac): undefined reference to `schrodinger::mae::Reader::next(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/NAS/lh/software/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: /usr/local/boost/lib/libboost_unit_test_framework.so.1.79.0: undefined reference to `memcpy@GLIBC_2.14'
/NAS/lh/software/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: /NAS/lh/software/miniconda3/lib/libstdc++.so: undefined reference to `aligned_alloc@GLIBC_2.16'
/NAS/lh/software/miniconda3/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.3.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld: /NAS/lh/software/miniconda3/lib/libstdc++.so: undefined reference to `clock_gettime@GLIBC_2.17'
collect2: error: ld returned 1 exit status
make[2]: *** [test/test_coordgen] Error 1
make[1]: *** [test/CMakeFiles/test_coordgen.dir/all] Error 2
make: *** [all] Error 2

It seems my glibc is too old. I can't change the version without authorization. Can conda solve this problem here?
Thanks!

Is there any way to leverage 3D coordinates?

Hello again,
I realize that you aren't in active development of this library so I'm mainly asking to see if there is a way in the current system to take advantage of known 3D coordinates. I see in the code that they can be used as a fallback for when things fail, but I'm not seeing anything for using them to initialize a starting position for the 2D generation. As I noted in another thread, I'm debating moving from my in-house library which uses a very different method of "flattening" the 3D structure rather than generating it from scratch via connectivity info (which I assume is how coordgen works). My method is slower, but in some cases gives superior results. For example, if we look at:
208
The "flatten" method gives:
flatten
which is pretty straightfoward from the picture, since the molecule is almost planar already. But coordgen doesn't know this, and gives:
coordgen208

I did see some code that attempts to penalize bond crossings and such but I was not able to tweak it to get a superior picture. I get worse results if I give more complicated molecules, but my "flatten" method often gets those wrong too, and takes much longer. Other toolkits, eg JMol, SmilesDrawer, and especially CDKDepict do very well with this molecule and similar, but they are implemented in other languages.

Some problems identified while doing template-guided coordinate generation

The attached zip file contains a set of SDFs where I noticed either problems caused by using a template when generating coordinates or the coordinates not honoring the template. In each SDF the first molecule is the template (with the coordinates I used). The other molecules have the coordgen-coordinates created using template alignment

These were all generated using the RDKit's coordgen integration and coordgen v1.3.2

The molecules are all from ChEMBL.

Here's an example where using the template has somehow resulted in bad coordinates for a couple of molecules (this is doc16404):
image

And here's an example where it looks like rotatable bonds in the template are being perturbed to remove clashes (this is doc66014)
image

cg_problems.zip

feature request: export version to header

Something like:

// coordgen/CoordgenConfig.hpp
#define COORDGEN_MAJOR 3
#define COORDGEN_MINOR 0
#define COORDGEN_PATCH 2
#define COORDGEN_VERSION "3.0.2"

which enables

#include <iostream>
#include <coordgen/CoordgenConfig.hpp>

int main() {
  std::cout << COORDGEN_VERSION << std::endl;
}

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.