求助：CP2K+OpenMPI通信器泄漏问题：运行NEB后总是出现MPI_ABORT

UW_0728.

lightman 发表于 2026-4-19 21:36
是的，问题已经解决了，重新安装采用MPICH库编译就行了。

其实，MPICH也有一定概率触发MPI finalize failure，不过那个不是CP2K层面的，而是MPICH程序层面的，这也就意味着只有CP2K完全结束进程时才可能触发，此时你该算的都已经算完，因此不会对CP2K运行产生什么实质性影响。

顺带一提，OpenMPI默认的绑核策略（--bind-to core）会导致用MPI和OpenMP混合并行时CP2K的进程被强制绑定在前几个线程上（包括开启超线程的情况），使得运行速度大幅拖慢（有人可能认为这是CP2K的问题，其实并不是）。遇到这个问题，解决办法是mpirun时加上“--bind-to none”强制取消绑核（也可以用“--bind-to numa”或“--bind-to node”达到相同目的），或者改用MPICH（默认设置就是“--bind-to none”）。如果你的任务频繁使用混合并行，个人认为后者更省心，而且CP2K自己的toolchain配置默认的选择就是MPICH（想安装OpenMPI必须指定--with-openmpi；除非检测到了系统已有的MPI），因此很多其他通信问题在MPICH并行版本的CP2K上触发概率都应该会降低（不过在运行性能上没有任何差别）。

lightman

UW_0728. 发表于 2026-4-20 04:06
其实，MPICH也有一定概率触发MPI finalize failure，不过那个不是CP2K层面的，而是MPICH程序层面的，这也 ...

谢谢，受教啦！给你一个大大滴赞👍

LittlePupil

UW_0728. 发表于 2026-4-20 04:06
其实，MPICH也有一定概率触发MPI finalize failure，不过那个不是CP2K层面的，而是MPICH程序层面的，这也 ...

曾经看到过IntelMPI是MPICH套壳的说法，请问IntelMPI相比OpenMPI是否有上述好处？

另外，如果使用Intel工具链编译，是否有必要额外编译MPICH？

UW_0728.

LittlePupil 发表于 2026-4-20 23:45
曾经看到过IntelMPI是MPICH套壳的说法，请问IntelMPI相比OpenMPI是否有上述好处？

另外，如果使用Inte ...

是，Intel MPI就是MPICH套壳，最多就是针对Intel机器做了些优化

我觉得应该没必要

我不喜欢Intel全家桶（MKL除外），所以可能也给不出什么好的针对性的说法和建议

s8ga

UW_0728. 发表于 2026-4-21 05:21
是，Intel MPI就是MPICH套壳，最多就是针对Intel机器做了些优化

我觉得应该没必要

说到 MKL, 请问现在的 cp2k 2025.2+ 往后的版本
可以使用GNU 编译器 + openmpi + MKL (作为 blas + lapack + scalapack) 这个选择吗

在cp2k dashboard 里面
cp2k ci pipline 的 intel oneapi build 里面没开 mpi / 也没使用 GNU 编译器

LittlePupil

UW_0728. 发表于 2026-4-21 05:21
是，Intel MPI就是MPICH套壳，最多就是针对Intel机器做了些优化

我觉得应该没必要

谢谢回复。

单论由其支持不如GNU编译器广泛及一些标准与后者有微妙差别导致的一些库的编译需要费些功夫甚至根本无法实现而言，Intel全家桶确实不招人喜欢，奈何在有些机器上用Intel工具链编译的CP2K就是比用GNU编译器编译的效率有明显提升。

UW_0728.

s8ga 发表于 2026-4-21 23:23
说到 MKL, 请问现在的 cp2k 2025.2+ 往后的版本
可以使用GNU 编译器 + openmpi + MKL (作为 blas + lapa ...

使用CMake完全可以，跟OpenBLAS等标准库的表现毫无区别；使用传统的Arch files+make我不敢保证不会出问题，有编译或者运行崩溃的风险（好在2026.1开始移除了这一定制化、脆弱的构建系统）。

注意截至目前的发行版CP2K（2026.1）使用的COSMA版本有bug，会无法正确检测MKL导致编译不过去，遇到这种情况加一个“--with-cosma=no”，或者直接拉取开发分支编译（or等待2026.2版本；目前更新的COSMA解决了这一问题）

UW_0728.

LittlePupil 发表于 2026-4-21 23:32
单论由其支持不如GNU编译器广泛及一些标准与后者有微妙差别导致的一些库的编译需要费些功夫甚至根本无法 ...

Intel全家桶（oneAPI）编译的CP2K有问题（或者直接编译不过去），千万别用。主要原因在于，CP2K的源代码利用了大量现代Fortran功能和特性，而现流行的Fortran编译器里几乎只有GCC gfortran对此有最完整的支持（GCC也是CP2K测试最多使用的，甚至包括Fedora Rawhide里未发布的GCC 16.0.1也在Spack构建的测试队列中，有什么问题能够立即关注和修复、或者跟相关依赖包or编译器的开发方联系）。Dashboard里面那几个是绿的一方面是巧合（CP2K方面没问题+oneAPI版本恰好没问题），另一方面是开发者们为了让其保持绿灯特意针对Intel编译器关掉了所有依赖libint等个别库的测试（而这些测试实际上要么崩溃要么跑出来错误结果）

LittlePupil

UW_0728. 发表于 2026-4-22 02:31
Intel全家桶（oneAPI）编译的CP2K有问题（或者直接编译不过去），千万别用。主要原因在于，CP2K的源代码 ...

谢谢忠告。

至少对于2024.1和2025.1两个版本，实践中oneAPI编出来的版本的“make test”结果确实惨不忍睹，但是我的个人算例（GEO_OPT+STRESS_TENSOR）和之前用GNU+OMPI编出来的2024.1版本的结果是对得上的。