在Ubuntu 22.04上从源码编译安装gnina 1.1：一个生物信息学新手的踩坑与填坑全记录

在Ubuntu 22.04上从源码编译安装gnina 1.1：一个生物信息学新手的踩坑与填坑全记录

作为一个刚踏入计算化学领域的科研民工，第一次听说gnina这个结合了传统分子对接算法与卷积神经网络打分函数的工具时，内心既兴奋又忐忑。兴奋的是它能将深度学习技术引入分子对接领域，忐忑的是作为一个Linux命令行操作还不熟练的新手，要完成从源码编译安装这个复杂过程，简直像在迷宫中摸索。经过三天两夜的折腾，终于成功在Ubuntu 22.04上完成了gnina 1.1的安装，期间踩过的坑、流过的泪，现在都化作了这篇详实的记录，希望能为同样挣扎在安装路上的同行们点亮一盏小灯。

1. 环境准备：那些容易被忽视的细节

1.1 系统基础环境检查

在开始之前，我犯的第一个错误就是没有全面检查系统环境。gnina的编译依赖特定版本的gcc、CUDA和Python，而Ubuntu 22.04默认安装的gcc版本是11.3.0，这与gnina的要求并不完全匹配。以下是我最终确认可用的环境配置：

# 检查gcc版本 gcc --version # gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0 # 检查Python版本 python3 --version # Python 3.10.6 # 检查CUDA版本 nvcc --version # nvcc: NVIDIA (R) Cuda compiler version 11.8.89

注意：如果你的CUDA版本低于11.0，建议先升级CUDA，否则后续编译会遇到无法解决的错误。

1.2 依赖库安装的陷阱

按照官方文档，我首先安装了基础依赖库：

sudo apt-get install build-essential libboost-all-dev libeigen3-dev \ libgoogle-glog-dev libprotobuf-dev protobuf-compiler libhdf5-dev \ libatlas-base-dev

看似简单的命令，却隐藏着一个大坑：libboost的版本问题。Ubuntu 22.04默认安装的是libboost 1.74，而gnina需要至少1.75版本。我不得不手动编译安装更高版本的boost：

wget https://boostorg.jfrog.io/artifactory/main/release/1.81.0/source/boost_1_81_0.tar.gz tar -xzvf boost_1_81_0.tar.gz cd boost_1_81_0 ./bootstrap.sh --prefix=$HOME/app/boost ./b2 install

2. OpenBabel安装：Python绑定的噩梦

2.1 编译选项的抉择

OpenBabel是gnina的重要依赖，但它的安装过程堪称新手杀手。官方文档建议的编译选项并不完全适用于所有环境。经过多次尝试，我发现以下配置组合最为可靠：

git clone https://github.com/openbabel/openbabel.git cd openbabel mkdir build cd build cmake .. \ -DCMAKE_INSTALL_PREFIX=$HOME/app/openbabel3 \ -DWITH_MAEPARSER=OFF \ -DWITH_COORDGEN=OFF \ -DPYTHON_BINDINGS=ON \ -DRUN_SWIG=ON \ -DPYTHON_EXECUTABLE=$(which python3)

关键点在于明确指定PYTHON_EXECUTABLE路径，否则cmake可能会找到错误的Python解释器。

2.2 Python环境变量的正确设置

即使编译成功，Python导入OpenBabel时仍可能报错。这是因为环境变量设置不当。正确的.bashrc配置应该是：

# OpenBabel3 export PATH=$HOME/app/openbabel3/bin:$PATH export LD_LIBRARY_PATH=$HOME/app/openbabel3/lib:$LD_LIBRARY_PATH export PYTHONPATH=$HOME/app/openbabel3/lib/python3.10/site-packages:$PYTHONPATH

特别注意PYTHONPATH中的python3.10需要与你的Python版本号一致。我最初忽略了这一点，导致即使安装成功也无法在Python中导入OpenBabel。

3. libmolgrid编译：内存不足的挑战

3.1 并行编译导致的内存溢出

libmolgrid的编译过程对内存要求极高。使用make -j8（8线程并行编译）时，我的16GB内存机器频繁出现OOM（内存不足）错误。解决方案是：

1. 减少并行线程数：make -j4或更低
2. 增加swap空间：

sudo fallocate -l 8G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile

3.2 头文件路径的精确指定

libmolgrid需要知道OpenBabel的头文件位置，但自动检测经常失败。必须明确指定：

cmake .. \ -DCMAKE_INSTALL_PREFIX=$HOME/app/libmolgrid \ -DOPENBABEL3_INCLUDE_DIR=$HOME/app/openbabel3/include/openbabel3 \ -DOPENBABEL3_LIBRARIES=$HOME/app/openbabel3/lib/libopenbabel.so

注意路径中的openbabel3子目录，这是新手容易忽略的细节。

4. gnina最终编译：胜利前的最后障碍

4.1 CMake参数的精简与优化

经过前几个组件的安装，gnina本体的编译相对顺利，但仍有几个关键点需要注意：

cmake .. \ -DCMAKE_INSTALL_PREFIX=$HOME/app/gnina \ -DLIBMOLGRID_INCLUDE_DIR=$HOME/app/libmolgrid/include \ -DLIBMOLGRID_LIBRARY=$HOME/app/libmolgrid/lib/libmolgrid.so \ -DOPENBABEL3_INCLUDE_DIR=$HOME/app/openbabel3/include/openbabel3 \ -DOPENBABEL3_LIBRARIES=$HOME/app/openbabel3/lib/libopenbabel.so \ -DBoost_INCLUDE_DIR=$HOME/app/boost/include

特别提醒：如果你手动安装了boost，必须通过-DBoost_INCLUDE_DIR指定其路径，否则会使用系统自带的旧版本。

4.2 测试安装是否成功

编译完成后，不要急于庆祝，先运行一个简单测试：

$HOME/app/gnina/bin/gnina --help

如果能看到帮助信息，恭喜你，最艰难的部分已经过去。但为了确保所有功能正常，特别是CNN评分部分，建议下载测试用例：

wget https://github.com/gnina/gnina/raw/master/test/data/1iep_ligand.sdf wget https://github.com/gnina/gnina/raw/master/test/data/1iep_receptor.pdb $HOME/app/gnina/bin/gnina -r 1iep_receptor.pdb -l 1iep_ligand.sdf --autobox_ligand 1iep_ligand.sdf

如果程序能正常运行并生成输出文件1iep_ligand_out.sdf，说明安装完全成功。

5. 环境变量与日常使用技巧

5.1 持久化环境配置

为了方便日常使用，将以下内容添加到~/.bashrc：

# gnina环境 export PATH=$HOME/app/gnina/bin:$PATH export LD_LIBRARY_PATH=$HOME/app/gnina/lib:$LD_LIBRARY_PATH export LD_LIBRARY_PATH=$HOME/app/libmolgrid/lib:$LD_LIBRARY_PATH export LD_LIBRARY_PATH=$HOME/app/openbabel3/lib:$LD_LIBRARY_PATH

然后执行source ~/.bashrc使配置生效。

5.2 常见问题速查表

6. 性能优化与进阶配置

6.1 多GPU支持

如果你的工作站配备多块GPU，可以通过以下参数充分利用硬件资源：

gnina -r receptor.pdb -l ligand.sdf --gpu 0,1

这将同时使用第一和第二块GPU进行计算。

6.2 自定义CNN模型

gnina允许使用自定义训练的CNN模型。只需在运行时指定模型路径：

gnina -r receptor.pdb -l ligand.sdf --cnn_model custom_model.model

自定义模型需要按照gnina的格式要求进行训练，这为特定研究方向的优化提供了可能。

经过这一番折腾，我深刻体会到在Linux环境下从源码编译复杂科学软件的艰辛，但也收获了宝贵的系统调试经验。现在回想起来，那些报错信息不再可怕，而是解决问题的线索。最重要的是，当看到gnina成功运行并输出第一个对接结果时，所有的努力都变得值得。