Ubuntu下批量分子对接：Open Babel、Vina与Slurm并行实践

简介围绕 Autodock Vina 批量分子对接的 PDF 文档面向生物计算、药物设计方向的学习者以及需要在集群上开展虚拟筛选的研究人员。内容覆盖 Ubuntu 18.04 下从零搭建对接流程安装 Open Babel、Autodock Vina 与 MGLTools配置环境变量使用 prepare_receptor4.py、prepare_ligand4.py 预处理受体和配体再通过 vina.sh 循环脚本与 conf.txt 参数完成批量对接及 pdbqt 到 sdf 的结果转换。文档还讲解 Slurm 调度器的安装配置包括 munge 服务、slurm-wlm/slurmd/slurmctld 组件、slurm.conf 节点与资源参数以及控制器和节点服务的启动便于把批量任务提交到集群。资源包为 1 个 PDF 文件约 1013KB以步骤化命令和配置片段组织便于复现环境、定位依赖与路径问题。已有 5264 人学习适合希望打通单机对接到集群批量调度链路、补齐安装配置与脚本排错细节的读者参考。1. 从一条 shell 循环说起批量分子对接真正卡住进度的是什么手里有 300 个配体每个都手动敲一遍vina命令一天下来可能只跑完几十个更常见的情况是命令没报错输出文件却互相覆盖最后分不清哪个构象属于哪个分子。批量分子对接真正卡住进度的往往不是 AutoDock Vina 的搜索算法而是预处理格式不统一、任务排队和输出聚合。这套资源把 Ubuntu 18.04 上的 Open Babel、AutoDock Vina、MGLTools 安装、vina.sh循环脚本以及 Slurm 三节点集群的配置串成一条线适合手里有一批 sdf/mol2 配体、想从单机 for 循环过渡到sbatch并行的药物设计或计算化学从业者。下面按装环境、转格式、写脚本、上集群、排错的顺序拆能看到每一步为什么这么做、参数改哪里、失败时先看什么。2. 环境钉死Ubuntu 18.04 上 Open Babel、Vina、MGLTools 的安装顺序与 PATH2.1 依赖项与版本组合为什么这套环境不能随便升级这套流程的底层约束是 MGLTools 1.5.6 依赖 Python 2。Ubuntu 18.04 默认的python还指向 Python 2.7所以python install.py能直接跑换到 20.04 或更新系统python指向 Python 3安装脚本会报语法错误或模块找不到。依赖列表里的python-tk、python-numpy、python-dev、python-pmw都是给 MGLTools 的图形界面和prepare_*脚本用的csh是因为部分脚本的 shebang 写的是 cshlibxt-dev、libglu1-mesa-dev、libxmu-dev、libxi-dev这些图形库则是 MGLTools 运行时需要的。先装依赖再解压软件顺序反了会在install.py阶段报缺库翻日志比重新装一遍更费时间。常见做法是把依赖安装和软件安装分成两段第一段只负责把系统包补齐第二段再处理 Vina 和 MGLTools 的目录。这样出问题时能快速判断是系统包缺失还是软件路径没配对。sudo apt-get update sudo apt-get install -y build-essential libxt-dev libglu1-mesa-dev \ libxmu-dev libxi-dev libpng-dev libjpeg-dev libtiff-dev \ csh python-tk python-numpy python-dev python-pmw-y表示非交互确认适合脚本化反斜杠是换行方便阅读。python-pmw在部分 Ubuntu 18.04 源里可能包名有差异如果这一条报Unable to locate package先用apt-cache search pmw确认实际包名不要直接跳过因为 MGLTools 的部分工具会依赖 PMW。apt-get update如果报 404先检查源列表是否还可用这是系统源的问题不是 Vina 本身的问题。2.2 解压、安装与三段 PATH路径顺序决定命令能不能找到创建统一的工作目录把 Vina 二进制包和 MGLTools 压缩包都放进去。原文里的tar -xvfz在 GNU tar 上参数顺序不对z应该跟在x后面写成tar -xzvf更稳。MGLTools 的install.py会询问安装路径默认当前目录一路回车即可安装用sudo运行对接时用普通用户避免输出文件属主混乱。sudo mkdir -p /home/autodock cd /home/autodock sudo tar -xzvf autodock_vina_1_1_2_linux_x86.tgz sudo tar -xzvf mgltools_x86_64Linux2_1.5.6.tar_.gz cd MGLTools-1.5.6 sudo python install.pytar -xzvf里x是解压、z是 gzip、v显示文件列表、f指定文件名。install.py用sudo执行是为了往/home/autodock下写文件如果目录本身归当前用户所有也可以不加sudo但要保证后续所有节点都能读到这个路径。安装完成后不要急着跑vina先把三段 PATH 配好否则prepare_receptor4.py和prepare_ligand4.py会提示 command not found。export PATH/home/autodock/autodock_vina_1_1_2_linux_x86/bin:$PATH export PATH/home/autodock/mgltools_x86_64Linux2_1.5.6/bin:$PATH export PATH/home/autodock/mgltools_x86_64Linux2_1.5.6/MGLToolsPckgs/AutoDockTools/Utilities24:$PATH第一段给vina可执行文件第二段给 MGLTools 的 Python 包装脚本第三段给prepare_receptor4.py、prepare_ligand4.py这些预处理工具。三段都放在$PATH前面避免系统里已有旧版本抢先。实际使用时可以把这三行写进~/.bashrc也可以直接放在vina.sh顶部走 Slurm 时更推荐放在作业脚本里显式 export因为非交互式 shell 不一定加载~/.bashrc。2.3 验证安装三条命令确认工具链可用装完不要直接上批量脚本先用最小命令确认每个工具都能独立跑起来。vina --version看版本obabel -V看 Open Babel 是否可用which prepare_receptor4.py看预处理脚本路径是否在 PATH 里。再加一条 Python 2 的 numpy 导入确认 MGLTools 依赖没断。vina --version obabel -V which prepare_receptor4.py python -c import numpy; print(numpy.__version__)vina --version正常会输出 1.1.2 这类版本号如果报libboost或libgomp相关错误通常是下载的二进制包架构不对或系统缺运行库先确认是 x86_64 包再补对应库。obabel -V输出 Open Babel 版本which输出脚本绝对路径。最后一条如果报No module named numpy说明python-numpy没装到当前 Python 下回到 2.1 补装不要用 pip 乱装 Python 3 的 numpy 混过去。3. 格式转换链从 pdb/sdf 到 pdbqt预处理脚本的输入输出边界3.1 受体准备prepare_receptor4.py 之前先看残基组成AutoDock Vina 读的是 pdbqt不是原始 pdb。受体要先去水、去共晶配体、补氢、合并非极性氢这些动作由prepare_receptor4.py完成。原脚本里写的是prepare_receptor4.py -r pro.pdb -e -o receptor.pdbqt-r指定输入受体-o指定输出-e按原脚本保留。实际跑之前先看一眼 pdb 里有哪些残基避免把不该留的杂原子带进去。cut -c18-20 pro.pdb | sort -uPDB 格式里第 18 到 20 列是残基名这条命令能把文件里出现过的残基类型列出来。看到HOH是水看到三位字母的配体代码可能是共晶小分子看到金属离子要不要保留取决于对接位点是否依赖它。常见做法是先用 PyMOL 或文本处理把水和无关杂原子删掉再跑prepare_receptor4.py。如果脚本报ERROR: Non-standard residue说明有它不认识的残基可以用-U跳过检查但不建议一上来就-U因为跳过检查后生成的 pdbqt 可能缺原子后面对接结果不可信。cd /home/autodock prepare_receptor4.py -r pro.pdb -e -o receptor.pdbqt-e的行为在不同 MGLTools 版本里可能略有差异原脚本保留就照原样保留如果输出 pdbqt 的原子数和输入 pdb 差得离谱先去掉-e再跑一次对比。受体准备只需要做一次批量循环里不要重复执行否则每个配体都重新处理一遍受体时间全浪费在重复劳动上。3.2 配体批量拆分obabel -m 生成多文件配体通常是 sdf 或 mol2 集合。先用 Open Babel 把 sdf 转成 mol2再用-m按分子拆成多个文件。原脚本里obabel -isd testset.sdf -omol2 -O testset.mol2是整包转换接着obabel ../testset.mol2 -O vs.mol2 -m才是拆分生成vs1.mol2、vs2.mol2这样的文件。-i指定输入格式-o指定输出格式-O指定输出文件名-m表示按分子拆分。cd /home/autodock obabel -isd testset.sdf -omol2 -O testset.mol2 mkdir -p mols cd mols obabel ../testset.mol2 -O vs.mol2 -m ls vs*.mol2 | head-isd里的s是 sdf 格式d表示输入文件-omol2里的m是 mol2。-O vs.mol2 -m会生成带编号的文件序号从 1 开始。如果 sdf 里有空记录或重复分子拆分数量可能和预期对不上先统计一下obabel -isd testset.sdf -onul 21 | tail -n 5-onul表示不输出结构只让 Open Babel 读一遍输出里会给出分子数。这个数字和ls vs*.mol2 | wc -l对不上就说明中间有分子转换失败先处理源文件不要带着坏数据进循环。3.3 prepare_ligand4.py输出名不要写死成 ligand.pdbqt原脚本在循环里写prepare_ligand4.py -l $mol2 -o ligand.pdbqt每次循环都覆盖同一个ligand.pdbqt。单次跑没问题批量跑时如果某一步失败后面很难追溯是哪个配体出的错。更稳的写法是用配体文件名做输出名${mol2%.mol2}去掉后缀生成vs1.pdbqt、vs2.pdbqt。cd /home/autodock/mols for mol2 in vs*.mol2; do base${mol2%.mol2} prepare_ligand4.py -l $mol2 -o ${base}.pdbqt || echo $mol2 prepare failed ../prepare_fail.log done-l是输入配体-o是输出 pdbqt。||后面的echo只在失败时执行把失败文件名追加到日志。prepare_ligand4.py常见报错是ERROR: Could not find atom type多半是 mol2 里的原子类型或电荷不标准用 Open Babel 重新输出一次 mol2 通常能解决如果还不行再考虑-U跳过检查但跳过之后一定要检查生成的 pdbqt 行数只有几行的文件基本是空壳不能直接拿去对接。4. vina.sh 拆解conf.txt 搜索盒、exhaustiveness 与循环里的输出覆盖4.1 conf.txt 参数搜索盒定在哪里exhaustiveness 开多大vina的核心参数都在conf.txt里。受体和配体路径、搜索盒中心、搜索盒边长、搜索彻底程度、输出构象数、能量窗口、CPU 数这些参数决定了跑得快不快、结果稳不稳。参数作用常用起点receptor受体 pdbqt 路径../receptor.pdbqtligand配体 pdbqt 路径循环里用命令行覆盖center_x/y/z搜索盒中心坐标由共晶配体或口袋残基确定size_x/y/z搜索盒边长单位 Å2030exhaustiveness搜索彻底程度832num_modes每个配体输出构象数9energy_range输出构象的能量窗口34cpu线程数1 或按核数搜索盒中心不能拍脑袋填。有共晶配体就用共晶配体的坐标平均值没有的话在 PyMOL 里选中口袋残基取它们的几何中心。盒子太小配体可能有一部分在盒子外Vina 会直接报错或给出不合理的构象盒子太大搜索空间膨胀exhaustiveness不变的情况下命中率下降。常见做法是先把盒子设到 2225 Å跑几个阳性配体看结果是否落在口袋附近再微调。exhaustiveness是批量对接里最影响时间的参数。默认 8 能跑出大致排序但做虚拟筛选时8 可能不够稳定调到 32 单配体时间会明显上升。我一般先用 8 跑全量做粗筛挑出排名靠前的一批再用 32 复跑不要一上来就全量 32。num_modes默认 9输出构象多不代表都对后续分析主要看第一条 best mode。cpu在单机批量脚本里写 1是为了和 Slurm 的--cpus-per-task1对齐一个配体占一核多个任务并行如果单机跑可以把cpu调到物理核数但 Vina 的多线程加速不是线性的批量场景下多任务并行通常更划算。4.2 循环逻辑先准备受体一次再逐个配体跑原vina.sh的逻辑是设 PATH清空并重建mols目录准备受体sdf 转 mol2拆分配体进入mols循环每个 mol2 准备配体、跑 vina、转 sdf、追加到output.sdf最后删除中间文件。这个流程本身能跑通但有几个地方需要盯住。#!/bin/bash export PATH/home/autodock/autodock_vina_1_1_2_linux_x86/bin:$PATH export PATH/home/autodock/mgltools_x86_64Linux2_1.5.6/bin:$PATH export PATH/home/autodock/mgltools_x86_64Linux2_1.5.6/MGLToolsPckgs/AutoDockTools/Utilities24:$PATH cd /home/autodock || exit 1 if [ -d mols ]; then rm -rf mols; fi mkdir mols prepare_receptor4.py -r pro.pdb -e -o receptor.pdbqt || exit 1 obabel -isd testset.sdf -omol2 -O testset.mol2 || exit 1 cd mols || exit 1 obabel ../testset.mol2 -O vs.mol2 -m || exit 1 for mol2 in vs*.mol2; do base${mol2%.mol2} prepare_ligand4.py -l $mol2 -o ${base}.pdbqt || { echo $mol2 prepare failed ../fail.log; continue; } vina --config ../conf.txt --ligand ${base}.pdbqt --cpu 1 \ --out ../results/${base}_out.pdbqt --log ../logs/${base}.log \ || { echo $mol2 vina failed ../fail.log; continue; } obabel -ipdbqt ../results/${base}_out.pdbqt -osd -O ../results/${base}.sdf cat ../results/${base}.sdf ../results/output.sdf donecd /home/autodock || exit 1保证目录切换失败时脚本不会在错误目录里继续跑。prepare_receptor4.py和obabel后面加|| exit 1是因为受体没准备好后面所有配体都白跑。循环里用--ligand ${base}.pdbqt覆盖conf.txt里的配体路径这样每个配体用自己的 pdbqt不会互相覆盖。--out和--log都带上base跑完能直接对应到配体名。失败时写fail.log并continue不让一个坏分子中断整批任务。原脚本里--out out.pdbqt每次覆盖、--log log.txt每次覆盖后删除跑完只剩一个output.sdf想查某个配体的打分细节已经没日志了。批量对接最怕这种黑匣子输出名带上配体名是最低成本的后悔药。4.3 CPU 与并行度单机循环和集群作业不是一回事单机跑vina.sh时--cpu 1加上 for 循环本质是串行一次只处理一个配体。机器有 8 核也只有一核在干活。想把单机吃满可以把配体列表切成 8 份起 8 个进程每个进程处理一份每份里仍然--cpu 1。这种写法比让单个 Vina 开 8 线程更稳因为 Vina 的多线程在部分版本上加速比有限而且日志和输出文件更容易管理。上 Slurm 之后并行单位从进程变成作业。一个sbatch脚本里如果还是 for 循环那这个作业仍然只在一个节点上串行跑要跨节点得用作业数组或者把配体列表切分后提交多个作业。#SBATCH --cpus-per-task1要和vina --cpu 1对上申请了 4 核却只让 Vina 用 1 核调度器会认为这个作业占着资源不干活集群利用率很难看。5. Slurm 集群避坑munge 认证、三节点 slurm.conf 与 sbatch 的五个翻车现场5.1 munge 与 slurm-wlm 的安装顺序认证没通后面全白搭Slurm 节点之间靠 munge 做身份认证munge 没起来slurmctld和slurmd之间的通信会直接失败。先装 munge 和依赖再装 Slurm 的包。原作业里还装了mariadb-server和libmysqlclient-dev这是给 accounting 用的单机测试可以不上但如果 slurm.conf 里开了 accounting 相关配置数据库没起来会拖慢作业提交。sudo apt-get update sudo apt-get install -y make hwloc libhwloc-dev libmunge-dev libmunge2 munge \ mariadb-server libmysqlclient-dev sudo systemctl enable munge sudo systemctl start munge sudo systemctl status mungesystemctl status munge看到active (running)才算过。如果启动失败先看/etc/munge/munge.key的权限正常应该是munge:munge、400。key 缺失或权限不对用包自带的create-munge-key重新生成再重启 munge。三台节点的 key 必须一致不一致的表现是节点能启动但互相认不到。接着装 Slurm 的三个组件sudo apt p a hrefhttps://download.csdn.net/download/weixin_35984438/88255408 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p