意见征求：给CP2K准备依赖工具链的toolchain脚本在后续开发中是否值得保留？

Uus/pMeC6H4-/キ

众所周知，安装第一性原理软件CP2K前需要准备好编译器、MPI、数学库等若干第三方工具库作为依赖；在既往版本的CP2K目录下tools/toolchain文件夹中有install_requirements.sh和install_cp2k_toolchain.sh等一系列bash脚本，可以下载解压源码现场编译，或根据系统的环境变量与路径寻找已有程序。自上个月2026.1版发布以来，这些toolchain系列脚本持续收到更新，特别是废弃GNU Make全面转向CMake编译后自动生成编译选项的generate_cmake_options.sh（参见利用cmake编译和安装CP2K一帖），以及刚刚开发分支接收的install_cp2k_toolchain.sh里扩写丰富的帮助信息。

最近开发者有意图推动的另一项重大改变，即移除toolchain脚本而改用一个第三方包管理器Spack（https://spack.io/）来配置环境、编译CP2K。这种新工作流需要python>=3.9创建虚拟环境并pip安装boto3==1.38.11 google-cloud-storage==3.1.0，此外还有podman包管理器，可以用CP2K目录下make_cp2k.sh这个bash脚本来处理，目前也在不断完善。开发者表示，传统的toolchain难以适应现代GPU机器上依赖复杂的ELPA、SIRIUS等工具库的构建与运行，而Spack社群不但能及时提供新版工具库，而且也可以促进新功能往CP2K的集成。

鉴于该计划影响深远，有必要发帖与论坛里广大CP2K用户讨论下。大家对现行toolchain系列脚本有何看法与建议，它们是否值得开发者保留并维护？未来更新CP2K时，是否愿意采用更先进但也稍微复杂的Spack + python3 + podman流程来准备工具链？无论是个人/课题组独占服务器还是大型公用HPC超算（特别是有节点硬件差别、离线安装需求等情况的话），都请留下宝贵意见，让开源免费的CP2K更加强大且易用。

更多讨论见github官方仓库的Issue #4843，如果不便访问或不确信观点合理性，也可以在此帖回复再统一整理反馈过去。

UW_0728.

Diotima 发表于 2026-3-18 21:55
我觉得迁移到spack也不是坏事，但是我有几个想法：
首先考虑到Google cloud storage的依赖……安装过程中 ...

其实根本不需要Google cloud storage，那个只是开发者自己运行GitHub仓库上的CP2K CI才会用到，用户这边完全用不到；make_cp2k.sh需要的前提依赖只是编译器（GCC）、CMake和Python（及Python的一些组件）

离线安装的问题，上一个关于SIRIUS回复里面也有提到。一方面是流程、步骤的问题，得复制到特定的目录或者在Spack的配置文件中手动指定源码目录才能生效。另一方面就是因为有了Spack这一途径，一些因为依赖复杂而使得toolchain不便加入的可选依赖项可以被加到里面，因为Spack会自动处理和下载这些依赖；如果想要实现离线安装那些东西，那么相应的所需依赖多源码包也得准备好，这就导致在Spack框架下想实现离线安装需要准备的源码包数目可能比toolchain所需的要多很多（最典型的就是SIRIUS令人生畏的嵌套依赖，一环套一环）；而且随着依赖版本的变化，不少地方也可能会随之需要更多的调整。总的来讲，比toolchain脚本实现离线安装麻烦多了。

顺带一提，Spack自己也是直接从软件官方仓库现场拉取源代码的，没有自己独立的仓库和镜像。

Diotima

我觉得迁移到spack也不是坏事，但是我有几个想法：
首先考虑到Google cloud storage的依赖……安装过程中要是真的要调用Google API该咋办？固然我可以想办法，但是很多时候对于大型公用集群，我们不能做一些含有风险的操作的。

能不能找找看有无离线安装的其他方式，或者提供一个离线包的仓库这样的，可以社区共同维护，只要方便拉取就好了。

reid

UW_0728. 发表于 2026-3-18 20:42
对角化方法应该都能无痛输出空轨道信息吧，我不太了解Davidson算法及其使用，不清楚这方面是不是还有问题

对角化不收敛，且没有收敛的迹象

UW_0728.

reid 发表于 2026-3-18 20:19
请问使用Davidson方法时，如何使输出的molden文件含有空轨道信息，谢谢

对角化方法应该都能无痛输出空轨道信息吧，我不太了解Davidson算法及其使用，不清楚这方面是不是还有问题

reid

UW_0728. 发表于 2026-3-9 15:56
目前我感觉值得开发者看看的有两个问题，也有用户在issue/discussion提过了：
1. DIIS对角化貌似与高级 ...

请问使用Davidson方法时，如何使输出的molden文件含有空轨道信息，谢谢

UW_0728.

注1：上面没提 sirius 是因为其有另一套依赖且比较复杂，将其处理逻辑从 toolchain 中分离来单独处理也是一种可能。

我简单看了一下SIRIUS的依赖链（主要与https://github.com/cp2k/cp2k/pull/4277相关的，这里实现的SIRIUS DFT-D3/D4等扩展功能因为需要更多额外的依赖而没被集成到toolchain中，目前只能从Spack装）：除了toolchain已有的，至少还需要sdft-d3、nlcglib两个直接依赖才能让toolchain安装版SIRIUS实现那个PR所能做的功能。

sdftd3可以随tblite提供，单独写一个toolchain脚本也很简单（复用tblite的即可）。问题在于nlcglib：一方面，这个库会衍生出至少两个依赖：一个是fmt-devel，可以从dnf下载（这还需要往install_requirements里面加，但不能保证所有人都关注install_requirements的要求；实际上，之前libint的版本变更就已经不太友好了，新增的那两个依赖在libint彻底转为CMake之前一个是随库一起安装、一个是没有要求）；另一个是kokkos，Rocky的仓库里没有，必须单独写脚本，而且nlcglib对kokkos版本的要求很严苛（根据我的测试，nlcglib 1.3.0搭配kokkos 4.6.01可以，用较新的kokkos会导致nlcglib编译不过去）。另一方面，nlcglib的仓库主页的README只说明了从Spack安装这一种方法，没有提供任何其他安装说明，因此源代码编译好了SIRIUS这边能不能正确链接上还是个问题。

即使依赖库解决了，还有一座大山，是SIRIUS安装脚本自身，那绝对是令人生畏的：一大堆require_env，一大摞子需要手动指定的优化选项和CMAKE_PREFIX_PATH,还有针对GPU的选项。要把新加的依赖正确设置好变量，还要加到SIRIUS安装脚本里面，看着就令人头疼……如果实在想要在CP2K里实现它所能完整实现的SIRIUS功能，可能Spack是唯一的出路了。

[多唠几句……]

诚然，SIRIUS对大多数CP2K用户用处并不大，它的平面波计算功能貌似也没有QE、VASP等强；此外，现有SIRIUS的基础功能应该对多数对使用SIRIUS有刚需的够用了。问题在于，照CP2K目前的发展模式，以后一定会有更多、更复杂的依赖被集成到CP2K中……而目前仅就SIRIUS模块的问题已经无法通过toolchain完美解决了……

我现在愈发认同开发者M. Krack教授在issue讨论中的一句话了：“The time spent by developers on the CP2K build system is lost for the CP2K development itself.” 其实对用户也一样，对于CP2K这个一度被号称最难安装的计算化学程序之一的程序，用户在编译安装它的过程中不断遇到莫名其妙的错误、不断找原因、继续试错，在这上面所浪费的时间对于自己推进研究和课题而言极有可能也是一种损失（多亏了卢老师的大量博文，否则CP2K光安装这一道就可以劝退六七成的人，也势必不会有今天这么流行）。顺带一提，CP2K之所以改成了CMake，就是为了规避这种完全定制化的方案所带来的额外维护成本，毕竟这个程序虽然规模不小但开发维护人员却相当有限。

此外，替换为Spack这个计划据我所知去年年底就有了，而且目标就是在今年内完成；如果不是近期用户对toolchain的大量介入和更新，开发者现在根本不会额外考虑保留toolchain的问题，2027.1就会完全删除toolchain（因此我也很高兴这些PR能够引起开发者的注意）。其实开发团队里还有第三个声音，就是希望用户完全通过Spack下载和安装CP2K，而不是自行手动从源代码编译。（Spack的安装本质上也是下载源代码然后编译，只是这些过程都由自带的Python脚本自动化处理了）

关于新的安装方式，目前开发分支里Spack那条途径的`make_cp2k.sh`已经相当完善（基本就是成品）了，至少在线安装（包括选择性启用和禁用）依赖和编译CP2K这条链上，一气呵成，很是省心；不过在我看来唯一也是致命的痛点就是离线安装的问题，这同时也是帖子里不少人所担心的。关于这个，Spack有官方说明，但显然比toolchain麻烦得多，不仅是操作流程麻烦，而且因为依赖关系复杂，你需要准备的离线包的数量也很可能要比toolchain需要的多得多。

还有一个关键（万恶之源），就是CP2K手册之简陋，2026.1更新后手册完全没有跟进上相应的变化就是一个很恶心的例子，都得用户自己查、自己试。这次关于新安装途径的说明在手册上和源代码包的说明里到目前为止已经做了一定程度的跟进，但显然还有不少需要扩充的。

reid

其实吧，只要把所有依赖放入build，然后还是用toolchain就很好，简简单单几行命令就行了，越简单越好。不要去弄乱七八糟的安装，因为有些超算或公共服务器不让随便安装程序。 好好开发一下对角化的收敛性，因为算PDOS时经常碰上咋都不收敛的情况

Uus/pMeC6H4-/キ

在完全保留和完全废除之间还有一条路，就是只维护一个 debloat 的 toolchain。假如 toolchain 只保留少数几个常用库的从头编译安装选项，比如（仅作为提案参考，不是最终确定的列表）

cmake, openmpi, openblas, fftw, libxc, libint, cosma, libxsmm, scalapack, elpa, plumed, deepmd-kit, spglib, libvori, dftd4/tblite, trexio, dbcsr,

其他的库不再随 toolchain 安装而是仅通过 toolchain 寻找环境变量和路径里的做链接，那大家愿意接受吗？

注1：上面没提 sirius 是因为其有另一套依赖且比较复杂，将其处理逻辑从 toolchain 中分离来单独处理也是一种可能。
注2：目前相比安装单独的 dftd4 更推荐安装集成了 dftd4 和 GFN2-xtb 等的 tblite ，利用我在另一个帖子讲的办法离线安装 tblite-0.5.0.tar.xz 是很顺利的。
注3：是否仍让 toolchain 支持部分程序的 GPU 适配安装，也是有待讨论的话题。

UW_0728.

reid 发表于 2026-3-7 00:58
我也觉得toolchain挺好用的。建议开发者提升一下对角化SCF的收敛性

目前我感觉值得开发者看看的有两个问题，也有用户在issue/discussion提过了：
1. DIIS对角化貌似与高级的电子密度混合方法不兼容（只能用DIRECT_P_MIXING）
2. Block-Davidson方法不支持k点（这个方法对于过渡金属为主的的体系或磁性体系可能更好）

reid

我也觉得toolchain挺好用的。建议开发者提升一下对角化SCF的收敛性

Stardust0831

abin 发表于 2026-3-5 20:02
是呀，只要没有采用加密形式写死的在线操作，
基本都可以通过手动下载来代替……这不就脱离了傻瓜式一件脚 ...

我的策略是直接srun到计算节点安装。
我这边比较幸运，校园网就能直接连github了，暂时没有遇到这种网络环境的苦恼

abin

是呀，只要没有采用加密形式写死的在线操作，
基本都可以通过手动下载来代替……这不就脱离了傻瓜式一件脚本自动处理的范畴了吗？

还会遇到更揪心的问题……
用户登录访问的机器，处理器指令集，与计算节点不同……
某些模块，指令集敏感的，会导致二进制运行失败……

当然，多数情形是，用户登录节点，处理器规格低，计算节点指令集较高……
自动编译后，基于低端处理器的指令集，可能未必发挥节点的理论性能，白话文就是跑得慢……

付费平台，当然乐见用户如此操作……

spack当然可以提供镜像甚至是二进制缓存……
网络正常的时候，使用二进制缓存，安装基础模块的cp2k还是挺快的……

我在用的集群，有两百多个包，是spack 在三天内部署的。

如果涉及到源码编译，涉及到访问GitHub ，基本是死翘翘的……业务前一分钟好用，后一分钟就各种保存了……
当然了，机器搬到香港，运行一切正常的……

只是鄙人的使用体验，不代表所有网络环境下都是如此。

Stardust0831

abin 发表于 2026-3-4 14:37
spack是挺好的方式。

But I believe that spack is a nice tool/approach for English speakers.

我去确认了一下，spack也是支持使用本地的tarball来离线安装，见手册：

abin

spack是挺好的方式。

But I believe that spack is a nice tool/approach for English speakers.

在某些地方，我们使用的HPC平台，不太可能允许用户联网，也可能具备稳定的网络环境，能否稳定访问github都是一个问题。

对于很多高校课题组的HPC平台，基本上是不能联网的（处于管理规定和安全规则）。

考虑到这种现实，能100%离线的安装模式，才是最佳最可靠的解决方案。
任何依赖网络进行的安装方式，在特定区域，都是一个美好的愿景。

鄙人愚见。