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数值频率）也有不小的加速

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

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

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确实会更快。

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