# gnina: docking small molecules with a convolutional neural network scorer

> gnina extends the smina and AutoDock Vina docking lineage with a 3D convolutional neural network that scores and optimizes ligand poses, and it ships as a pre-built binary, a Docker image or a source build on Ubuntu. The cost of adopting it is a GPU, a large dependency set and a model you are expected to validate yourself.

**gnina/gnina** — A deep learning framework for molecular docking

- Repository: https://github.com/gnina/gnina
- Stars: 1,019 · Forks: 216
- Language: C++
- License: Apache-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/gnina-gnina

## gnina is a fork of smina, which is a fork of AutoDock Vina

The lineage matters more than the feature list here. gnina is described as a fork of smina, which is itself a fork of AutoDock Vina, and it adds convolutional neural network scoring and optimization to that inherited docking machinery. That means the search algorithm, the scoring function options and the general command line shape are not new inventions in this project, they are inherited and extended, which lowers the barrier for people who already speak that dialect. It also means gnina is a fork, and forks carry a specific risk: divergence between the fork and its upstream over time, plus the obligation to track security and dependency fixes in the parent project yourself. The project positions itself for molecular docking with integrated support for scoring and optimizing ligands using convolutional neural networks, and its topic tags place it in cheminformatics, computational chemistry, molecular modeling and drug discovery. The primary language is C++, and the build is a CMake project with a src tree, headers, cmake modules, examples, scripts, a test directory and an Eigen submodule, so it is a substantial compiled code base rather than a wrapper script.

## The CNN works on the 3D grid of the receptor, not on a ligand descriptor

The scoring mechanism is the reason this project exists, and it differs from ordinary cheminformatics descriptors in an important way. The method work behind it is described in a paper titled Protein-Ligand Scoring with Convolutional Neural Networks, and the dataset work in Three-Dimensional Convolutional Neural Networks and a Cross-Docked Data Set for Structure-Based Drug Design. The project also documents ligand pose optimization with atomic grid-based convolutional neural networks, and visualizing convolutional neural network protein-ligand scoring. Taken together, these describe an approach where the ligand and the protein binding site are rasterized onto a three dimensional grid and the network scores the pose from that grid, rather than describing the ligand only by a flat vector of physicochemical properties. The practical consequence for a user is that the model consumes geometry, so changes to the receptor structure or to the ligand atom types change what the network sees. The project also documents a cross-docked data set, which exists to make models generalize across protein environments, and the CACHE Challenge entry titled Docking with GNINA Is All You Need, which reports the method in a community challenge setting rather than only in its own benchmarks.

## A pre-built binary or a Docker image, and CUDA 12.0 as the floor

Installation is where a project like this usually turns people away, and gnina is unusually direct about it. The recommendation is to use the pre-built binary from the releases page unless you have significant experience building software on Linux, in which case building from source might result in an executable more optimized for your system. The pre-built binary can also be used in WSL. There is also a pre-built Docker image, with Dockerfiles in the docker directory of the repository, which is the cleanest route if you want an isolated environment with the CUDA runtime and the chemistry stack already wired together. The Ubuntu source-build instructions require CUDA 12.0 or newer and nvcc on PATH; the WSL2 example installs CUDA 12.4 and cuDNN 9.0. This build requirement is distinct from runtime acceleration: the documented --no_gpu option disables GPU use. The dependency list for Ubuntu 22.04 is long and reveals the shape of the program, since it pulls in Boost, Eigen, glog, protobuf, HDF5, ATLAS, RDKit, NumPy, pip, pytest and jsoncpp. RDKit and OpenBabel both appear, which is a sign that chemical file format handling and descriptor work sit on either side of the docking core.

## Building on Ubuntu 22.04, including the OpenBabel step

The documented Linux build is a sequence of three parts: system packages, then OpenBabel, then gnina itself. The package line below is the exact set the project lists for Ubuntu 22.04. Run it and you get the compiler toolchain plus the chemistry and serialization libraries the build expects.

```bash
apt-get  install build-essential git cmake wget libboost-all-dev libeigen3-dev libgoogle-glog-dev libprotobuf-dev protobuf-compiler libhdf5-dev libatlas-base-dev python3-dev librdkit-dev python3-numpy python3-pip python3-pytest libjsoncpp-dev
```

OpenBabel comes next, and the project attaches a specific warning to it: there are errors in bond order determination in version 3.1.1 and older, so the build pulls the repository rather than a distribution package.

```bash
git clone https://github.com/dkoes/openbabel.git
cd openbabel
mkdir build
cd build
cmake -DWITH_MAEPARSER=OFF -DWITH_COORDGEN=OFF -DPYTHON_BINDINGS=ON -DRUN_SWIG=ON ..
make
make install
```

The gnina build itself is a clone, a build directory, CMake, make and install.

```bash
git clone https://github.com/gnina/gnina.git
cd gnina
mkdir build
cd build
cmake ..  # -DUSE_SYSTEM_NVTX=1 may be needed with pytorch 2.7.0 and CUDA 12.9
make
make install
```

That trailing comment in the CMake line is worth pausing on, because it tells you the project tracks a specific pairing between PyTorch, CUDA and NVTX and that the configuration is not entirely automatic. For a cluster with mixed GPUs the documentation points at an additional CMake configure flag for that case.

## The WSL2 path installs CUDA and cuDNN by hand

If you are on Windows, the project does not leave you guessing. There is a dedicated section for WSL2 Ubuntu 22.04, linked from an issue in the repository, and it starts by removing the distro CUDA toolkit so that the installer does not conflict with it, then downloads and runs the CUDA 12.4 installer, then installs cuDNN 9.0 from a local deb repository. These lines are the first part of that sequence.

```bash
sudo apt-get remove nvidia-cuda-toolkit
wget https://developer.download.nvidia.com/compute/cuda/12.4.0/local_installers/cuda_12.4.0_550.54.14_linux.run
chmod 700 cuda_12.4.0_550.54.14_linux.run
sudo sh cuda_12.4.0_550.54.14_linux.run
wget https://developer.download.nvidia.com/compute/cudnn/9.0.0/local_installers/cudnn-local-repo-ubuntu2204-9.0.0_1.0-1_amd64.deb
sudo dpkg -i cudnn-local-repo-ubuntu2204-9.0.0_1.0-1_amd64.deb
```

The rest of that block copies the cuDNN keyring into place, updates the package index, installs the cudnn-cuda-12 package, repeats the apt-get line, and then builds OpenBabel and gnina with make -j8 followed by sudo make install. The WSL route is more manual than the Docker image, and it is worth asking whether a colleague's GPU driver is even supported on that combination before committing a day to it. Note also that the project states it hosts a Slack team and an example Colab notebook showing how to use gnina, which is the fastest way to see the tool work before you install anything locally.

## Where gnina is the wrong choice

There are several clear boundaries. First, hardware: CNN scoring can be computationally expensive, but gnina documents --no_gpu to disable GPU acceleration. Check that the selected binary and its dependencies run on the target system, and benchmark CPU performance for the intended workload. Second, the model is a moving target for you even if the code is stable. The project documents multiple papers, from the 2017 methods paper through GNINA 1.0 in 2021 and GNINA 1.3 in 2025, and the model and code have moved with them, so any result you report is tied to a particular build and a particular model, and that pairing is something you must record. Third, the source build assumes a Linux toolchain and the docs are written for Ubuntu 22.04, WSL2 Ubuntu 22.04 and Docker on Linux; there is no native macOS or Windows build described. Fourth, the flagship use is ligand scoring and pose optimization, not pipeline management, and the project does not describe an experiment tracker, a batch scheduling system or a results database. If your need is a general virtual screening campaign, the tooling around gnina is your problem to solve, not the project's.

## Citations, examples and how to judge the output

The project takes its academic reporting seriously, and that is a genuine asset when you need to defend a result internally. The primary application citation is GNINA 1.3: the next increment in molecular docking with deep learning, published in J. Cheminformatics in 2025, with the previous primary application citation being GNINA 1.0: Molecular docking with deep learning from 2021, a methods citation for protein-ligand scoring with convolutional neural networks from 2017, a virtual screening citation for Virtual Screening with Gnina 1.0 in Molecules, an example application for the CACHE Challenge entry, and a dataset citation for the cross-docked data set. The repository root also holds a CITATION.cff file, and an examples directory containing a kitchensink.score file, which is the kind of example a new user should read first to see what a score output looks like. What the project does not provide is a quick reference for interpreting a score value, so a sensible first step is to take a ligand whose pose you trust, rescore it, and check that the network gives it a competitive value before trusting the network to reorder a set of candidates it has never seen.

## Conclusion

gnina is worth adopting for structure-based drug discovery teams that already work with smina or AutoDock Vina, want a CNN-based rescoring and pose minimization step, and can validate its results for their research. GPU acceleration can improve performance, but the documented --no_gpu flag disables it. For reproducible work, record the exact executable and model, review the referenced model documentation and validate poses against suitable experimental data. Before you commit, verify that a pre-built binary runs on your driver and CUDA combination, confirm which CNN model your build ships with, and reproduce a known ligand from your own set to check that the scores move in the direction you expect.

## FAQ

### What is gnina and what is it forked from?

gnina is a molecular docking program with integrated support for scoring and optimizing ligands using convolutional neural networks. It is a fork of smina, which is a fork of AutoDock Vina.

### Do I need a GPU to run gnina?

No. The documented --no_gpu option disables GPU acceleration. The Ubuntu source-build instructions separately call for CUDA 12.0 or newer and nvcc, so check the dependencies of your chosen binary or build; CPU execution may be slower.

### Can I run gnina without building it from source?

Yes. The project recommends the pre-built binary from the releases page unless you have significant experience building software on Linux, and that binary can be used in WSL. A pre-built Docker image is also published.

### What license is gnina released under?

The repository is listed under the Apache-2.0 license, and the root directory also contains LICENSE.APACHE and LICENSE.GNU files.

## Sources

- [gnina/gnina on GitHub](https://github.com/gnina/gnina)
- [Issues](https://github.com/gnina/gnina/issues)
- [License: Apache-2.0](https://github.com/gnina/gnina/blob/master/LICENSE)
- [README](https://github.com/gnina/gnina/blob/master/README.md)
- [Releases](https://github.com/gnina/gnina/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gnina-gnina