Linux下ORCA与xtb联用安装配置与构象筛选实践

标题里的OCRA是个常见的笔误圈内都写作 ORCA——量子化学里那套 ADF 之外最常被计算化学工作者搬上集群的从头算/DFT 程序。而 xtb 是另一条线上的东西GFN 系列半经验紧束缚方法速度比 DFT 快两三个数量级。这两个程序单拎出来装都不算难真正让人卡住的是联用——很多人第一次听到这个词以为是两个程序之间有某种插件式的接口装上就能互相调用。实际情况没那么玄乎绝大部分所谓联用是让 xtb 在前段把几百上千个候选构象筛成十几个再交给 ORCA 做高精度优化和能量计算。这篇就把 Linux 下 ORCA 的完整安装流程、xtb 的两条安装路线、以及两者在脚本层面怎么串起来一次性讲清楚顺便把我在配置过程中踩过的坑按排查顺序列一遍。1. 先搞清楚 ORCA 和 xtb 在计算流程里各自站哪一环1.1 两个程序的能力边界ORCA 的定位是通用的量子化学程序能做 HF、DFT、MP2、CCSD(T)、多参考方法也能做 TD-DFT、NMR 化学位移、EPR 参数、溶剂化模型CPCM/SMD、ONIOM 分层计算。它的强项是功能覆盖广、对学术用户免费、输入语法相对友好而且对中低配硬件的适配做得不错一台 16 核的机器跑个几十原子的体系做 B3LYP/def2-TZVP 优化是完全可行的。xtb 的定位完全不同。它是 Stefan Grimme 组开发的一套半经验紧束缚方法实现核心是 GFN0/GFN1/GFN2-xTB 这几个哈密顿量。它不追求精度天花板追求的是在可接受的精度下把速度拉到极限。一个 100 原子的有机分子GFN2-xTB 做几何优化单核可能几秒到几十秒就出结果同样的体系上 B3LYP/def2-SVP十几个核跑几个小时都算正常。这个速度差就是联用的全部动机。需要先建立的一个认知是xtb 的几何构型质量并不差。对于构象搜索这种要从山一样的局部极小里挑出真正重要的那几个的任务GFN2-xTB 给出的构象排序和相对能量和 DFT 的结果在定性上高度一致只有在能量差小于 1 kcal/mol 的近似简并体系上才会出现排序颠倒。所以合理的做法是xtb 负责把搜索空间砍掉 95%ORCA 负责在剩下的 5% 里给出可以写进论文的数字。1.2 联用到底联的是什么这句话得说透否则后面配置环境变量会觉得莫名其妙。两个程序之间并没有共享内存、共享基组库、共享积分引擎之类的机制。它们之间传递的东西只有三样几何构型。最常见的是 xyz 格式的笛卡尔坐标也可以是 ORCA 的.inp里嵌的坐标块、.xyz文件、甚至 Gaussian 风格的输入。这是最核心的交换格式。能量和梯度。xtb 算出的相对能量用于排序筛选某些场景下也会把 xtb 的解析梯度交给 ORCA 做 ONIOM 的低层。进程调度。谁先跑、谁后跑、跑完怎么判断该停还是该继续这部分靠 shell 脚本或者 Python driver 来管。所以联用配置这个词本质上等于三件事两个程序都能在命令行直接调用PATH 配好、两边用同一套坐标文件路径和格式统一、以及脚本里能把上一步的输出正确喂给下一步。听起来简单但每一环都有翻车的点后面第 5 章会逐个拆。1.3 机器和系统需要满足什么条件在动手之前先花两分钟确认硬件。第一个命令是看 CPU 指令集grep -m1 -o avx2 /proc/cpuinfo能打印出avx2说明 CPU 支持 AVX2 向量指令。新版 ORCA 的官方二进制包对指令集有要求如果这行什么都不输出意味着你的机器可能是比较老的至强 E5 v1/v2 或者早期桌面平台那就需要在下载页挑兼容性更好的那份包或者退回到 ORCA 5.0.x。虚拟机里跑的用户尤其要注意VMware 和 VirtualBox 默认的 CPU 直通模式有时会把 AVX2 藏起来需要在虚拟机设置里显式打开启用 AVX2之类的选项。第二个命令是看核数和内存nproc free -g注意nproc给的是逻辑核数含超线程。做 DFT 的时候超线程带来的收益通常只有 10% 到 20%但会明显增加每个核的内存占用所以我的习惯是并行核数按物理核数来定。内存这一项ORCA 的内存是按每个 MPI 进程分配的用%maxcore关键字控制单位是 MB。核数乘上 maxcore 的总和不能超过物理内存还要给系统留出至少 8 GB 的余量。判别方法很简单nproc除以 2 大致就是物理核数前提是 BIOS 里开了超线程。2. Linux 下把 ORCA 装到能跑通第一个算例2.1 选包版本、指令集、MPI 三个变量ORCA 的安装包文件名长这样orca_6_0_0_linux_x86-64_shared_openmpi411.tar.xz拆开看命名规则是[程序名]_[主版本]_[次版本]_[平台]_[编译方式]_openmpi[MPI版本]。同一版本号下面通常挂着好几份包区别在于平台架构有的是通用指令集有的是针对新 CPU 做了 AVX2/AVX-512 优化后者性能更好但对硬件更挑剔。选择逻辑是先在支持 AVX2 的机器上试优化版跑不起来再退通用版。ORCA 的下载需要到官方论坛注册账号并同意许可条款学术用途免费商业用途需要另外申请。这一步没法绕过也不建议用什么镜像站——来源不明的二进制包在计算化学里是很危险的你永远不知道它有没有被改动过而计算结果的正确性完全依赖于程序本身。下载完之后顺手核对一下文件大小和官方页面标注的数值是否一致。2.2 目录规划与解压我强烈建议把所有第三方计算程序统一放在/opt下面而不是散落在$HOME里。原因有两个一是多人共用的机器上每人都装一份太浪费二是备份和迁移的时候/opt一个目录打包走环境变量改个前缀就行。sudo mkdir -p /opt/qchem sudo chown -R $USER:$USER /opt/qchem cd /opt/qchem wget 下载得到的包地址 -O orca.tar.xz tar -xJf orca.tar.xz ls解压出来是一个形如orca_6_0_0_linux_x86-64_shared_openmpi411的目录为了后续引用方便重命名成一个短名字mv orca_6_0_0_linux_x86-64_shared_openmpi411 orcatar加-xJf中J表示 xz 压缩格式。这里有个小细节如果解压过程中出现文件名乱码或者报编码相关的警告多半是下载时用了浏览器插件自动改名或者本地 locale 设置有问题。处理办法是先把LANG临时设成C.UTF-8再解压或者用tar -tvJf先看一眼包里的文件名是否正常。另外安装路径里不要放中文也不要有空格某些工具链对这两样东西的处理并不稳健。进入目录看一眼内容cd /opt/qchem/orca ls | head -30应该能看到orca主程序、一堆orca_*开头的工具orca_2mkl、orca_plot、orca_vib、orca_anmr等以及lib目录。2.3 环境变量一次性配好ORCA 需要四个环境变量。把它们写进~/.bashrc或者/etc/profile.d/orca.sh后者适合多人共用机器export ORCA_DIR/opt/qchem/orca export PATH$ORCA_DIR:$PATH export LD_LIBRARY_PATH$ORCA_DIR/lib:$LD_LIBRARY_PATH export OMP_NUM_THREADS1逐个说为什么PATH里加$ORCA_DIR本身而不是$ORCA_DIR/bin是因为 ORCA 的可执行文件就直接躺在解压目录的根下没有 bin 子目录。这是很多人第一次配 ORCA 会踩的坑——习惯性地写$ORCA_DIR/bin结果orca命令找不到。LD_LIBRARY_PATH指向lib是因为官方包里的数学库BLAS、LAPACK和 MPI 库是随包分发的不指向这里的话运行时会报找不到libopen-pal.so或者libmpi.so之类的错误。最后那条OMP_NUM_THREADS1是最容易被忽略、但影响最大的一条。ORCA 是 MPI 加 OpenMP 的混合并行程序%pal nprocs N控制 MPI 进程数每个进程还会再开 OpenMP 线程。如果系统里已经设了OMP_NUM_THREADS16很多超算平台默认这么设而你的输入里又写了%pal nprocs 16 end结果就是 16×16256 个线程抢 16 个核性能断崖式下跌甚至直接卡死。所以跑 ORCA 之前把 OpenMP 线程压到 1把并行度全交给 MPI 管理。如果你需要用 root 用户在容器或虚拟机里跑 ORCA教学环境里很常见OpenMPI 会因为安全策略拒绝启动需要额外两条export OMPI_ALLOW_RUN_AS_ROOT1 export OMPI_ALLOW_RUN_AS_ROOT_CONFIRM1改完~/.bashrc之后source ~/.bashrc然后验证which orca orca第二行直接敲orca不带任何参数正常情况下会打印一大段横幅里面有版本号、编译日期、支持的并行特性。这就是最快速的版本检查方式——ORCA 没有--version这个选项很多人试半天试不出来其实空跑一次就够了。2.4 第一个算例与并行自检建个工作目录写一个水分子的单点能输入water.inp! B3LYP def2-SVP TightSCF %pal nprocs 4 end %maxcore 2000 * xyz 0 1 O 0.0000 0.0000 0.1173 H 0.0000 0.7572 -0.4692 H 0.0000 -0.7572 -0.4692 *几个语法要点!开头的行是简单关键词行%开头的是块状关键词以end结尾。坐标块用*xyz 电荷 自旋多重度起头再用单独一行*收尾。自旋多重度对闭壳层单重态写 1。运行orca water.inp water.out注意 ORCA 的输出重定向是手动的程序自己不会把.out文件名自动对应到输入名这点和 Gaussian 的习惯不同。跑完之后grep FINAL SINGLE POINT ENERGY water.out能打印出能量说明安装是通的。同时看一眼输出里的并行信息确认实际使用的 MPI 进程数是不是你指定的那个值。如果只用了 1 个进程说明%pal没生效回头检查输入文件里%pal块的位置——它必须出现在坐标块之前。顺带把几个常用工具也验证一下工具用途验证命令orca_2mklgbw 与 mkl 格式互转orca_2mkl -horca_plot绘制轨道、密度orca_plot -horca_vib振动分析与热化学需有.hess文件orca_anmrNMR 屏蔽张量处理orca_anmr -h3. xtb 与 CREST 的安装二进制一路和 conda 一路3.1 二进制包解压与 XTBPATHxtb 的安装比 ORCA 简单从 GitHub Releases 页面下载对应平台的压缩包文件名类似xtb-6.6.1-linux-x86_64.tar.xz解压后是一个自带bin、lib、include、share的完整目录树cd /opt/qchem wget xtb release 地址 tar -xJf xtb.tar.xz mv xtb-6.6.1-linux-x86_64 xtb然后配环境变量这里有一个 ORCA 没有的特殊变量export XTBPATH/opt/qchem/xtb/share/xtb export PATH/opt/qchem/xtb/bin:$PATH export OMP_NUM_THREADS$(nproc)XTBPATH是 xtb 找参数文件的路径。GFN 系列方法的元素参数、D4 色散校正参数、溶剂化模型的参数都放在share/xtb下面的.param文件里。如果这个变量没设对xtb 会在启动时报错说找不到某元素的参数文件或者在遇到特殊元素时静默失败——后一种情况更讨厌因为你可能跑完一整轮才发现某些元素用的是默认兜底参数。这是二进制安装路线最大的一个坑conda 安装则不会有这个问题。OMP_NUM_THREADS这里给满核数是合理的因为 xtb 只有 OpenMP 并行没有 MPI。这就引出了下面的重点。3.2 conda-forge 路线如果机器上已经有 conda 或 mamba安装只需要一行conda create -n qchem -c conda-forge xtb crest conda activate qchemconda-forge 上的 xtb 是官方维护者打包的参数文件路径通过 conda 的激活脚本自动注入XTBPATH不用手动设。CREST 是 xtb 作者的构象搜索工具也在同一个 channel 里一起装掉。这条路线的好处是干净、可复现、不会和系统库冲突缺点是二进制包为了兼容性做了保守编译性能可能比官方优化的二进制包低一些我实测大概差 10% 到 30%取决于方法。选择建议如果是做一次性任务或者教学演示conda 路线省事如果是长期跑构象搜索这种吃机时的活儿用官方二进制包性能差值是实打实的。3.3 线程模型完全不同环境变量要分开管这一点必须单独拎出来讲因为它是 ORCA 和 xtb 联用中最容易出性能事故的地方。两个程序对并行的理解和控制方式完全相反项目ORCAxtb / CREST并行方式MPI OpenMP 混合纯 OpenMP并行度控制输入的%pal nprocs N环境变量OMP_NUM_THREADS推荐 OMP_NUM_THREADS1物理核数超订风险高MPI×OMP 相乘低OMP 超订由系统调度缓解所以在一个串联脚本里必须在切换程序的时候显式修改OMP_NUM_THREADS# xtb 阶段 export OMP_NUM_THREADS32 xtb conf.xyz --gfn 2 --opt tight xtb.log # ORCA 阶段 export OMP_NUM_THREADS1 orca dft.inp dft.out如果偷懒全程用同一个值ORCA 那边就会超订16 核的机器能跑出 4 核的速度。3.4 验证xtb 的验证很简单造一个水分子坐标文件water.xyz3 water O 0.0000 0.0000 0.1173 H 0.0000 0.7572 -0.4692 H 0.0000 -0.7572 -0.4692第一行是原子数第二行是注释行可以是任意字符串之后是坐标。运行一个 GFN2 的单点加优化xtb water.xyz --gfn 2 --opt xtb_test.log正常结束的话当前目录会多出xtbopt.xyz优化后的构型、xtbrestart重启文件、charges原子电荷等文件。打开xtb_test.log末尾应该能看到总能量和收敛信息。CREST 的验证用同一个文件crest water.xyz --gfn2 --chrg 0 --uhf 0 crest_test.log--uhf是未成对电子数闭壳层写 0。CREST 默认会做构象搜索对水这种只有一种构象的分子会很快退出。对于真实体系CREST 的 METADYN 或 iMTD-GC 算法会生成大量构象这一步是整个流程里最耗时但也最值得投入的部分。4. 三种联用姿势的取舍与实操4.1 脚本级串联最通用也最可控这是我最推荐的方案也是适用面最广的用 shell 脚本或者 Python 脚本做调度器把 xtb/CREST 的输出直接喂给 ORCA。它不依赖任何程序的内部接口因此不会因为版本升级而失效也最容易在集群的作业调度系统里复现。流程是三步CREST 用 GFN2-xTB 做构象搜索输出一批优化过的构象按能量排序。从crest_conformers.xyz里切出前 N 个经验值能量窗口 3 kcal/mol 以内或者上限 20 个。对每个构象生成一个 ORCA 输入批量提交最后汇总能量。关键的技术细节在于 ORCA 输入文件的批量生成。下面这段 Python 直接读 xyz、写 ORCA 输入import sys, os def split_xyz(path): mols [] with open(path) as f: lines f.readlines() i 0 while i len(lines): n int(lines[i].strip()) block lines[i:i n 2] mols.append(block) i n 2 return mols src sys.argv[1] mols split_xyz(src) for idx, mol in enumerate(mols, 1): n int(mol[0].strip()) xyzpath fconf_{idx:03d}.xyz with open(xyzpath, w) as f: f.writelines(mol) inp f! B3LYP def2-TZVP def2/J RIJCOSX Opt TightSCF %pal nprocs 16 end %maxcore 3000 * xyzfile 0 1 {xyzpath} with open(fconf_{idx:03d}.inp, w) as f: f.write(inp)有两个细节值得留意一是 ORCA 输入文件必须以换行符结尾否则程序会读到文件末尾直接报格式错误二是如果输入文件是从 Windows 传过来的CRLF 换行会让 ORCA 的解析器把\r当成非法字符dos2unix一下就好。这两条我在第 5 章还会再展开。* xyzfile后面跟的是电荷、自旋多重度和坐标文件名路径可以是相对的——ORCA 会在当前工作目录下找。4.2 CREST 自带的 ORCA 接口CREST 较新的版本内置了与 ORCA 的对接通道在配置里指定 ORCA 的可执行路径、并行核数、以及用于高层计算的方法关键词CREST 会自动写出 ORCA 输入、调用它、读回优化后的几何结构然后继续下一轮构象比较或 refinement。这个功能的价值在于把高精度构象精修这一步自动化了。手工做的话你得先跑完 CREST再写脚本切构象再批量提交 ORCA再收集结果再判断哪些构象要舍弃——循环往复好几轮。用接口的话一条命令就能把整个流程串起来。需要提醒的是不同 CREST 版本里与 ORCA 相关的选项名称有变化命令行参数和.crest配置文件的写法也不完全一致。稳妥的做法是先跑crest --help把输出重定向到文件里慢慢搜与 ORCA 相关的关键词确认自己的版本支持哪些参数、参数名是什么。这个习惯比抄网上的命令靠谱得多——计算程序版本迭代快两年前的教程放到今天大概率对不上。另外一个实践中的注意点走 CREST 的内部接口时ORCA 的输出会被 CREST 截取和解析中间文件可能被清理掉。如果你需要保留每一步的 ORCA 输出用于事后检查反而更适合用 4.1 的手工串联方式。自动化程度和可追溯性在这里是鱼和熊掌。4.3 ORCA 输入里直接调用半经验方法ORCA 本身对半经验方法一直有支持NDDO 系列MNDO、AM1、PM3 等是内置的。至于 GFN 系列的紧束缚方法部分较新的 ORCA 版本把类似 xtb 的哈密顿量以关键词形式接了进来这条路走通的话就不需要外部程序了。判断你的版本支不支持最直接的方法是试写一个只含! XTB的输入故意跑一个水分子单点看输出里是正常算出能量还是报未知关键词。ORCA 对不认识的简单关键词会在输出里明确报错这个自检成本很低。需要说明的是走 ORCA 内置半经验路线和调用外部 xtb 得到的结果不会完全一致——同名的哈密顿量在不同实现里的细节处理色散校正、溶剂化、积分格点可能有差异。如果你的工作是方法学对比研究不同实现之间的差异本身就是一个需要交代的点如果只是做构象预筛这点差异对最终排序的影响可以忽略。4.4 一份可以直接抄的串联脚本把前面几节的内容整合成一个完整的 bash 脚本输入一个含多个构象的 xyz 文件输出排好序的 DFT 能量表#!/usr/bin/env bash set -euo pipefail XYZ$1 BASE${XYZ%.xyz} NPROC_ORCA16 NPROC_XTB$(nproc) TOP20 mkdir -p ${BASE}_work cd ${BASE}_work # 1. xtb 快速预优化所有构象 export OMP_NUM_THREADS${NPROC_XTB} xtb ../${XYZ} --gfn 2 --opt normal --namespace pre pre_xtb.log # 2. CREST 构象采样 crest ../${XYZ} --gfn2 --chrg 0 --uhf 0 crest.log # 3. 取能量窗口内的前 N 个构象 python3 ../pick_conformers.py crest_conformers.xyz ${TOP} # 4. ORCA 高精度优化 export OMP_NUM_THREADS1 for f in conf_*.inp; do orca $f ${f%.inp}.out while [ $(jobs -r | wc -l) -ge 2 ]; do sleep 5; done done wait # 5. 汇总能量 grep -H FINAL SINGLE POINT ENERGY conf_*.out | sed s/.*ENERGY // summary.txt sort -k2 -n summary.txt | head -${TOP}这里用了一个简单的并发控制同时最多跑两个 ORCA 任务每个占 16 核正好吃满 32 核的机器。如果你的机器核数不够要么把%pal nprocs调小要么把并发数降到 1。千万不要同时开 8 个 ORCA 任务、每个申请 16 核那会让内存爆掉进程被 OOM killer 干掉跑了几小时的结果全丢。5. 联用配置里最常翻车的几个点按排查顺序来5.1 路径、权限与 locale第一类问题几乎都出在路径上。表现是command not found或者运行到一半报找不到某个库文件。排查顺序是这样的先which orca和which xtb确认能找到可执行文件再用ldd $(which orca) | grep not found看动态链接库有没有缺失。如果ldd输出里有not found说明LD_LIBRARY_PATH没覆盖到或者包本身不完整重新下载核对大小。ldd输出里出现libmpi.so相关条目时还要注意版本冲突如果系统里装了发行版自带的 OpenMPI而 ORCA 包自带另一份LD_LIBRARY_PATH的先后顺序决定了谁被优先加载。顺序错了会报 MPI 版本不匹配之类的错误症状是程序启动瞬间就退出。解决办法是把 ORCA 的lib目录放在LD_LIBRARY_PATH最前面。权限问题常见于多人共用的服务器/opt/qchem/orca目录属主是 AB 用户运行时因为读不到lib下的文件而失败。统一chmod -R arX一下就好。至于 locale主要影响 xtb 和 CREST 读坐标文件时的浮点数解析。某些 locale 下小数点会被解析成逗号分隔符症状是程序报坐标格式错误。临时export LC_ALLC可以快速验证是不是这个原因。5.2 换行符和输入文件结尾前面提过这里补齐排查链路。症状是 ORCA 启动后立刻报输入解析错误类似unexpected character或者直接提示某个位置的字符非法。第一步看文件是不是 CRLF 换行file conf_001.inp输出里带CRLF就是问题所在。第二步转换dos2unix conf_001.inp或者批量find . -name *.inp -exec dos2unix {} \;第三步确认文件末尾有换行。用tail -c 1 file | xxd看最后一个字节是不是0a。很多编辑器在生成文件时会丢掉末尾换行特别是通过字符串拼接写文件的时候。这套问题在 Windows 上写输入、Linux 上跑的场景里出现频率极高。我现在养成的习惯是所有输入文件生成后统一过一遍dos2unix脚本里加一行几乎零成本。5.3 线程超订性能突然变差的头号嫌疑症状很好识别程序能跑完结果也对但耗时比预期长好几倍top里能看到大量进程在 R 和 S 状态之间跳来跳去CPU 使用率超过 100% 乘以核数。排查手段ps -ef | grep -c orca top -H -p $(pgrep -f orca | head -1)看单进程的线程数top -H会展开线程。如果 ORCA 的 MPI 进程数是 16、每个进程又有 16 个线程那就是超订。修复方式前面说过了跑 ORCA 前export OMP_NUM_THREADS1。更彻底的做法是在脚本里用env显式传递给子进程env OMP_NUM_THREADS1 orca input.inp input.out这样即便父 shell 里设了别的值也不受影响我最推荐这种做法因为它把配置和程序绑定在一起不依赖外部环境。反过来说xtb 那边如果OMP_NUM_THREADS被误设成 1会慢得离谱。两个程序的变量方向是完全相反的记住这个对照关系能省很多事。5.4 内存与磁盘被低估的两个瓶颈内存的坑在于%maxcore的理解。这个值的单位是 MB含义是每个 MPI 进程可用的内存。所以实际峰值内存约为nprocs × maxcore再加上一些共享的开销。一台 128 GB 内存的机器跑 32 进程%maxcore最多给到 3500 MB 左右再多就危险了。磁盘的坑更隐蔽。ORCA 的中间文件.gbw、.scfp、.scfr、.densities、tmp*体积可能是最终输出的几十倍。一个大体系做 CCSD(T)中间文件轻松上 TB。所以在%maxcore调完之后还要看一眼工作目录所在分区剩多少空间df -h .低于 100 GB 的时候就要警惕了特别是批量跑构象的时候每个构象都要留一套中间文件。我的做法是在脚本里加一条清理逻辑每个构象的 ORCA 任务成功结束后只保留.out和.xyz其余中间文件删掉磁盘压力立刻下来。5.5 电荷、自旋、单位三者必须前后一致这是逻辑层面的坑程序不会报错但结果全错。电荷方面xtb 的--chrg、CREST 的--chrg、ORCA 输入的* xyz 电荷 自旋三处必须完全一致。尤其是做离子体系或者金属配合物的时候一个手误就会让整个计算失去意义。自旋方面xtb 的--uhf是未成对电子数不是自旋多重度ORCA 写的是自旋多重度两者差 1。开壳层体系要特别注意一个三重态自由基ORCA 写 3xtb 写--uhf 2。写反了程序照样能跑出数但那是完全不同的电子态。单位方面xtb 默认输出的是 Hartree和 ORCA 一致这点还好。但 xtb 输出的相对能量有时候会带上 D4 色散校正的贡献而 ORCA 侧如果没开色散校正两者对比就会出现系统偏差。做构象排序的时候要么两边都开色散要么两边都不开保持逻辑一致。我的建议是在生成输入的时候把这些元信息电荷、自旋、方法、是否开色散集中写在一个配置字典里脚本从这个字典里取值避免同一信息在多个地方手写。5.6 临时目录与并行任务冲突批量提交的时候如果所有任务都在同一个目录下跑ORCA 的中间文件会互相覆盖症状是随机某个任务报文件被占用或者输出莫名其妙地中断。解决办法是给每个任务一个独立的工作目录for i in $(seq 1 ${TOP}); do mkdir -p job_${i} cd job_${i} cp ../conf_$(printf %03d $i).inp . orca conf_$(printf %03d $i).inp out.log cd .. done另外 ORCA 支持通过%base之类的块指定临时目录如果你的工作分区是网络文件系统NFS把临时目录指到本地 SSD 会快很多。NFS 上的小文件随机读写性能很差而 ORCA 恰好非常依赖这种访问模式。6. 一个小案例从零跑通构象筛选 DFT 单点6.1 输入准备假设我们要处理的是正丁烷的某个衍生物先用任何建模工具生成一个粗糙的起始结构start.xyz确认文件格式正确第一行原子数、第二行注释、之后是元素符号加三个浮点坐标。6.2 xtb 预优化export OMP_NUM_THREADS$(nproc) xtb start.xyz --gfn 2 --opt tight --chrg 0 --uhf 0 --namespace pre pre.log--opt tight比默认的 normal 收敛标准更严对于后续要接 DFT 的任务值得多花这点时间。跑完得到pre.xtbopt.xyz这是个几何质量已经不错的构型如果只需要粗略比较直接拿这个结果也能用。6.3 CREST 收敛构象crest pre.xtbopt.xyz --gfn2 --chrg 0 --uhf 0 --gfn2//gfn2 --ewin 6.0 crest.log--ewin设置能量窗口单位 kcal/mol。设 6.0 意味着把所有能量在该窗口内的构象都保留下来这个值越小任务越快但可能漏掉重要构象。对于柔性链状分子我通常用 6.0对于有多个氢键构型的体系会放宽到 10.0。跑完之后的核心产物是crest_conformers.xyz里面是所有唯一化之后的构象按能量升序排列。6.4 ORCA 精修与能量提取用 4.1 里的 Python 脚本切出前 20 个构象生成 ORCA 输入批量提交。这里的泛函选择上给个小建议纯做构象能量的相对排序r2SCAN-3c这种复合方法是性价比之王它把泛函、基组、色散校正打包好了一个关键词搞定比手工组合快得多精度也够用。输入写成! r2SCAN-3c Opt TightSCF %pal nprocs 16 end %maxcore 3000 * xyzfile 0 1 conf_001.xyz跑完之后用一条命令汇总for f in conf_*.out; do e$(grep FINAL SINGLE POINT ENERGY $f | tail -1 | awk {print $NF}) echo -e ${f%.out}\t$e done | sort -k2 -n energies.txt输出的就是按能量升序排好的构象列表第一列是构象编号第二列是 Hartree 为单位的绝对能量。6.5 结果核对最后一定要做一步交叉核对把 ORCA 排出来的前三名的相对能量和 CREST 用 GFN2 排出来的顺序对比一下。如果顺序一致说明你的筛选流程是可靠的如果出现了明显颠倒那就值得深究——有可能是有构象被 xtb 低估了也有可能某一帧 ORCA 优化到了不同的局部极小。这个核对步骤看起来多余但它是唯一能让你对整条流程建立信心的方式。我见过太多次xtb 说这是最低能量构象DFT 一算发现是个次稳定结构的情况根源往往是 xtb 阶段的几何优化标准太松或者色散校正的开/关在两个程序间不一致。最后分享一个我自己在用的习惯把 ORCA 和 xtb 的版本号、编译选项、以及每次运行的关键环境变量OMP_NUM_THREADS、LD_LIBRARY_PATH都写进一个大目录下的environment.log。半年后回头看某个数据能立刻知道当时用的是什么配置。计算化学里换个版本结果不一样是常态留痕比什么都重要。