ORCA 5.0.4 中结合xtb计算NEB会调用数值频率计算

921927965

各位老师好，最近想使用ORCA中的NEB模块结合xtb中的GFN2-xTB方法对批量的反应物-产物对进行反应路径的搜索，但是在计算过程中发现ORCA的计算效率并不高。经过观察计算过程发现ORCA在计算NEB时会调用orca_numfreq模块计算数值频率，但是NEB方法理论上是不需要频率信息的，想了解下orca做数值频率计算的原因是什么？是否由于做了数值频率计算，导致计算效率较低？希望有老师能为学生解惑。

输入文件内容如下：

orca调用numfreq

wzkchem5

921927965 发表于 2024-3-7 12:14
原来是这个原因，现在明白了，感谢老师的耐心解答！

另外，我刚和ORCA团队负责NEB的人确认过了，新版ORCA的NEB已经基本上解决了这个问题，对于你这个例子相比ORCA 5.0.4有40倍的加速，也就是不比ASH慢太多。所以ORCA 6推出以后，这个问题会有很大改善。这个问题主要是因为xtb和ORCA的接口的overhead，因此DFT的NEB计算不会因为这个问题而多花时间。
新版ORCA其他的涉及大规模调用xtb的计算（例如xtb数值频率）也有不小的加速

921927965

wzkchem5 发表于 2024-3-7 17:58
由输出文件可以看出，ORCA和ASH调用xtb的次数估计是差不多的，因为NEB迭代次数差不多。
所以ORCA计算慢 ...

原来是这个原因，现在明白了，感谢老师的耐心解答！

wzkchem5

921927965 发表于 2024-3-7 09:41
老师好，我这边是使用python的ash包（https://github.com/RagnarB83/ash）进行的neb计算，选择这个包的原 ...

由输出文件可以看出，ORCA和ASH调用xtb的次数估计是差不多的，因为NEB迭代次数差不多。
所以ORCA计算慢应该是因为ORCA调用xtb有额外的overhead。ORCA不管做什么计算，基本都会产生gbw文件，我刚才试了一下用GFN2-xTB算水分子，产生的gbw文件有1.5MB大。而产生gbw文件的内容（例如ORCA的各种默认计算设置，包括当前计算会用到的和不会用到的）本身也要花一点时间。可想而知把这些事情重复做几百遍，肯定会花不少时间的。
本质上讲，ORCA的程序逻辑是围绕DFT计算来设计的，或者说ORCA假设计算时间起码也是分钟级的，所以耗时1秒左右的冗余操作就没有太花精力去优化。对于大批量调用xtb等极其便宜的方法算小分子的应用场景，直接调用xtb比通过ORCA这层壳子去调用xtb确实会更快。

921927965

wzkchem5 发表于 2024-3-6 23:08
orca_numfreq虽然名字里带numfreq，但其功能并不止计算数值频率。
数值频率和NEB都需要并行计算若干个结构 ...

老师好，我这边是使用python的ash包（https://github.com/RagnarB83/ash）进行的neb计算，选择这个包的原因是因为它同样实现了 10.1021/acs.jctc.1c00462 中提到的 energy-weighted springs，但在计算中发现同样使用单核计算，ASH的计算速度是比ORCA快很多的，我这边选择了一个反应，复现了这个结果，python安装和ORCA调用的xTB均为6.5.1版本。
slurm作业提交脚本如下：

ASH运行时间：

ORCA运行时间：

所有输入输出文件已经打包在附件中上传，感谢老师解答！

wzkchem5

orca_numfreq虽然名字里带numfreq，但其功能并不止计算数值频率。
数值频率和NEB都需要并行计算若干个结构的能量和梯度，因此程序就调用orca_numfreq去计算NEB需要的各个image的能量和梯度了，而没有另写一套专门用于NEB的代码。
另外，对于比较好收敛的过渡态，NEB本来就是不如OptTS等传统方法快的，NEB的主要优点第一在于获得反应路径（而非只有过渡态），第二是对于OptTS难收敛的体系可以比较好收敛。所以如果你认为计算效率不高是根据你做OptTS计算的经验得来的结论，那么这不是ORCA的问题，而是NEB的问题。如果你的结论是和其他支持NEB的程序比较而来的，那可以讨论一下ORCA慢的原因，或许我们ORCA这边也可以改进。