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

reid

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

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

Diotima

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

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

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自己也是直接从软件官方仓库现场拉取源代码的，没有自己独立的仓库和镜像。

Uus/pMeC6H4-/キ

UW_0728. 发表于 2026-3-18 06:06
我简单看了一下SIRIUS的依赖链（主要与https://github.com/cp2k/cp2k/pull/4277相关的，这里实现的SIRI ...

SIRIUS的开发者在https://github.com/cp2k/cp2k/pull/5098表达了坚决支持Spack等包管理器、反对进一步维护扩展toolchain这种shell脚本实现的观点。

本来SIRIUS就不是刚需且实现功能的依赖链复杂，再捆绑包管理器（此处不针对Spack，不考虑从头开始离线安装到底难不难）作为管理依赖的额外依赖，我觉得可以用courageous来形容 ("Courageous" means "this will lose you users and citations")。

J.Liu

应当保留，且非常实用。如有可能，多种安装方式最优。