search

gnina / gnina

A deep learning framework for molecular docking
Apache License 2.0
591 stars 142 forks source link

GNINA generating incorrect bond orders #241

Open Tonylac77 opened 8 months ago

Tonylac77 commented 8 months ago

Issue summary

I've been using GNINA and for some compounds in my test set, the bond orders are generated incorrectly, leading to errors when parsing the SDF output using PandasTools. I've attached the input file and protein file, as well as sample results for reference. Compound FCG16141527 is an example of this issue. issue.zip I have been using this particular test library for a while and have never run into an issue until now.

Steps to reproduce

I am using the prebuilt executable (latest version)

The compounds were prepared using GypsumDL (the test library file provided is already prepared).

Commandline: gnina --receptor /home/tony/DockM8/testing_single_docking/protein_protoss.pdb --ligand /home/tony/DockM8/testing_single_docking/protein_protoss/split_final_library/split_10.sdf --out /home/tony/DockM8/testing_single_docking/protein_protoss/smina/split_10_smina.sdf --center_x 16.7 --center_y -2.69 --center_z 17.61 --size_x 16.0 --size_y 16.0 --size_z 16.0 --exhaustiveness 8 --cpu 1 --num_modes 10 --cnn_scoring none --no_gpu

Your system configuration

Operating system: Windows Subsystem for Linux (Ubuntu 22) Compiler: provided binary CUDA version (if applicable): x CUDNN version (if applicable): x Python version: 3.10

dkoes commented 8 months ago

Dang. This is a problem with openbabel. The version included with the pre-built executable is too old (my mistake, but to be fair the 3.1.1 release thinks it is the 3.1.0 release while newer versions advertise as 3.1.1). Here is a colab illustrating the issue: https://colab.research.google.com/drive/1J6Rim1byhtArGMkxcZm7b1Xx4e0_czHv?usp=sharing

The immediate workaround until I can update the release binary is to set BABEL_DATADIR to point the location of a newer (unreleased) openbabel data directory, as shown in the colab.

Tonylac77 commented 8 months ago

Thanks for the quick answer, installing openbabel from source in WSL2 seems to work for now (without specifying BABEL_DATADIR), although I would like to avoid requiring the user of my package to do this. Will you close the issue when the pre-built executable is updated?

dkoes commented 8 months ago

I've made a 1.1 release with the right version of openbabel. The colab notebook above has been updated and you can see the problem if fixed. Please close if the problem is resolved on your end.