DFTD3 and DFTD4 various changes (conditional compilation, build.rs, usage) · Pull Request !5 · RESTGroup/rest

该 PR 将对 REST 程序的 DFTD3 与 DFTD4 的条件编译、构建过程、使用方式等进行修改。该修改的代码更改量较小，但应视作中等规模重构。

## 对程序的影响

1. 该编译流程更改目前**不是**破坏性的。已经编译成功 REST 的设备上，只需要更新代码，程序依然能编译与运行。尽管 `build.rs` 编译流程有所更改，但我相信目前的 docker 安装脚本仍然可用，且我认为可以有条件地删除一些语句 (特别是涉及 `REST_EXT_INC` 的部分)。
2. 目前 DFTD3 与 DFTD4 的运行有更严格的要求。如果对特定的 DFT-D 版本、特定的泛函，没有对应的参数的话，程序会直接 panic；而不是目前输出错误信息但仍然运行、并将 DFT-D 矫正能量定为 0。

## 动机

该 PR 并非是功能更新，并非是目前紧要必须通过的更新；但对开发者的编译体验相信会有所帮助。

1. (祝震予) 目前编译 REST 过程中，必须要链接 Fortran module (`REST_EXT_INC` 变量指定路径)。这是冗余的。
    - simple-dftd3 与 dftd4 作为暴露 C 接口的库，其使用一般只需要 static (.a) 或 dynamic (.so) library 即可，未必需要 Fortran module 文件；
    - Rust 语言具有标准的 C FFI 接入方式，从语言开发习惯上 FFI 也应倾向于使用 C；
    - Fortran module 文件一般需要自己编译 (至少很少有人公开发布 Fortran module 文件)；但 static (.a) 或 dynamic (.so) library 则通常可以在不同计算设备上迁移。对于 simple-dftd3 与 dftd4，尽管下载到本地编译是标准做法，但这些库也可以轻易地通过 conda 或 mamba 安装。
2. (颜文杰) DFT-D3 与 DFT-D4 编译容易出现很多问题，特别是在旧版本的 GNU toolchain 下 (容易出现编译错误)、具有网络连接困难的情况下 (即使将 simple-dftd3 或 dftd4 的仓库下载到本地，如果不对 CMake 文件作额外配置，mctc-lib 或 multicharge 等库仍然会通过 github 下载)。如果有一种不编译 DFT-D3 或 DFT-D4 的方法 (包括从 conda 获取，或干脆不编译)，会对编译的体验有较大帮助。
3. (王石嵘、颜文杰) 我们在大多数情况下，开发时不需要 DFT-D 的功能；用户也未必总是要使用 DFT-D 功能。能否像其他计算化学程序一样，仅在用户有需求时引入 DFT-D 的编译 (即条件编译)。

## 具体的改变

1. **C-FFI** (REST 外进行的工作)：创建了仓库 [dftd3-rs](https://github.com/restgroup/dftd3-rs) 与 [dftd4-rs](https://github.com/restgroup/dftd4-rs)。这些仓库是基于 DFT-D3 与 DFT-D4 的 C FFI binding 与 Rust 封装。该封装应比较接近 DFT-D4 作者 Sebastian Ehlert 写的 Python 封装库。其库
    - `dftd3` 与 `dftd4` 是具体的 FFI binding 与 Rust 封装；REST 程序需要这些依赖库；
    - `dftd3-src` 与 `dftd4-src` 仅有 `build.rs` 文件，是方便用户安装或指定 dftd3/dftd4 库位置或用于编译的程序；但 REST 不需要这些库，因为 REST 自己已经处理好这些问题了。

考虑到 DFT-D3 与 DFT-D4 接口长期会比较稳定，因此我已经 `dftd3` 与 `dftd4` 已经发布于 crates.io，相关 API 文档也在 docs.rs 上。并且这些库不需要在 rest_workspace 中维护，以避免 workspace 臃肿。

2. **编译流程更改**：在 `build.rs` 中，对于涉及到 DFT-D 的部分，仅保留
    ```rust
    println!("cargo:rustc-link-lib=s-dftd3");
    println!("cargo:rustc-link-lib=dftd4");
    ```
    其余的部分均删去。**这同时意味着不需要现场生成 libdftd3_rest.so, libdftd4_rest.so**。

3. **在 REST 中接入 DFT-D 的程序的修改**：
    - 保留 `dftd3_atm` 与 `dftd4_atm` 函数，功能有少许改变 (见第 4 点)，但调用方式与其目的与原先是一样的。
    - 去除 Fortran 程序 `dftd3_rest.f90` 与 `dftd4_rest.f90`；使用 crate `dftd3` 与 `dftd4` 调用。

4. **功能更改**：
    - 原先是在调用 DFT-D 程序前判断泛函是否存在，以确定是否进一步进行 DFT-D 计算。现在是在 [dftd3_load_param](https://docs.rs/dftd3/latest/dftd3/interface/fn.dftd3_load_param.html) 中直接让 DFT-D3 程序判断泛函是否有对应的色散参数；如果没有找到，程序会直接 panic。

**如果我们不希望程序直接 panic，而需要进行错误处理，请在该 PR 中回复。在 crate `dftd3` 中，所有返回 `Result<..., DFTD3Error>` 的函数都有后缀 `_f`，因此相应地改成 `dftd3_load_param_f` 即可**。

- 现在程序会在更多的情形下 panic。一般来说，panic 的情形是用户可能指定错误的 dftd3 version 等情况；这种情况下如果程序返回 0.0 的色散矫正，我个人认为是不太合适的。

5. **条件编译**：现在增加了 cargo feature `dftd3` 与 `dftd4`，可以控制是否编译相关模块。目前它们是 default features，因此默认情况下是需要编译；但如果不需要 DFT-D，那么通过 `cargo build --no-default-features` 实现。

## 可能相关的开发者

@igor1982 (张颖) 赵懿璘 @canarias (王石嵘) @ulysses-s (颜文杰)

类型	指派人员	状态
审查	bsplu 已审查通过	已完成 (1/1人)
测试	bsplu 已测试通过	已完成 (1/1人)

RESTGroup/rest .gitee-modal { width: 500px !important; }

搜索帮助

RESTGroup/rest