main.typ

@@ -27,7 +27,7 @@
 
 - 桌面：用于日常工作，2018年起主力使用Linux，Deepin #sym.arrow Arch #sym.arrow Gentoo #sym.arrow NixOS (2023-05-28)
 - 服务器（VPS）：用于运行个人网站/服务，差不多时间，OpenWRT #sym.arrow Ubuntu #sym.arrow Arch #sym.arrow Gentoo #sym.arrow NixOS
-  - xmurp-ua: OpenWRT上用来绕过学校多设备检测的内核模块。
+  - xmurp-ua 是我写的，用来绕过一些大学中，宿舍不许多设备共享网络的限制。
 - 科学计算：2020年硕士入组开始接触，Gentoo + Ubuntu #sym.arrow NixOS (2023-09)
 
 == 科研方向
@@ -36,14 +36,17 @@
 - 我个人主要做第一性原理计算，兼职管理组里服务器和超算环境。
   - 第一性原理：从最基础的物理原理（量子力学）出发，原则上不引入经验值，计算材料的结构、物理性质、特定条件下的变化，等。
 
-= 科学计算在实践中面临的困难，与基于Nix的解决方案
+= 科学计算在实践中面临的困难
 
 == 科学计算特点
 
-- 相比于个人电脑的桌面环境或个人服务器，科学计算的环境有*两个特殊需求*：
+更专业的介绍见明天的报告（\@VickieGPT），我主要从个人经验、具体实践角度出发。
+
+- 相比于爱好者折腾/软件开发的环境，科学计算的环境有*两个特别需求*：
   - 计算量大、经费有限，需要尽可能#text(red)[*高性能*]。
   - 使用者非CS专业或爱好者，缺少相关技能，需要#text(green)[*易于使用和维护*]。
-- 矛盾：#text(red)[*高性能*] 导致需要特殊的硬/软件配置，进一步导致难以实现 #text(green)[*易于使用和维护*]。
+
+矛盾：#text(red)[*高性能*] #xarrow(sym: sym.arrow.long, [导致]) 需要特殊的硬/软件配置 #xarrow(sym: sym.arrow.long, [导致]) 难以实现 #text(green)[*易于使用和维护*]。
 
 == 科学计算现状
 
@@ -53,9 +56,10 @@
 
 #set text(18pt)
 
-- *复古*的包管理：手动收集依赖，手动修改Makefile指定编译器/参数/库路径。
+- *手工*的包管理：手动收集依赖，手动修改Makefile指定编译器/参数/库路径。
+- *老旧*的基础环境：十几年前的内核/用户态程序。
 - *随意*的编程习惯：无视标准、能用就行，C/C++不分，Fortran只有特定编译器能编译。
-- *闭源*的编译器：Intel (OneAPI)，Nvidia (HPC SDK)。
+- *闭源*的编译器：Intel (OneAPI)，Nvidia (HPC SDK)，不方便二次打包。
 - *混乱*的用户权限：多人共用一个账户，一人负责配置环境、多人使用。
 
 #text(15pt, gray)[（\*仅身边统计学，没有diss别的组的意思）]
@@ -69,7 +73,9 @@
 
 #figure(image("更多的.png", width: 90%))
 
-如果能够一次编程、到处部署，该多好！
+如果能够利用 Nix 的*可复现性*，实现*一次编程、到处部署*，该多好！
+
+= 使用Nix搭建科学计算环境
 
 == Nix / NixOS的优势
 
@@ -80,31 +86,58 @@
   - SLURM、NFS 等都有现成模块。
   - 配置文件可跨服务/软件、跨用户、跨机器联动，不需要担心配置修改不同步。
 
-== 我们的配置
+Nix 的优势：将 *编译/配置过程* 抽象成 *代码（可版本管理）*，从而重复使用，用机器的自动化运作代替大部分的人力劳动。
 
-- 在小组内、有完整权限的小集群上，使用 NixOS：
+== 理想 vs 现实
+
+- 理想：
+  - *软件开发者*使用 Nix，我们一键安装/配置；
+  - *论文作者*使用 Nix，我们一键复现，略作修改继续研究；
+  - *超算管理员*使用 Nix，可供他人参考学习并部署自己的集群，出问题也可一键回滚。
+- 现实：
+  - 在现实中没有遇到除我以外的科研人员使用Nix。
+  - 网上有一些。Barcelona Supercomputing Center（巴塞罗那，西班牙）开源了 bscpkgs，其中包含 Intel 闭源编译器。
+
+== 配置细节
+
+沿用传统的软件/布置方式，但使用Nix来配置。
+
+- 在小组内、有完整权限的小集群上，使用 NixOS。
+- 在没有 root 权限的超算上，使用 Nix 安装一部分小工具（e.g. gnuplot）。
+  - 高性能计算的核心软件（编译器、MPI、VASP 等）使用传统方式安装，下一次更新时再考虑使用 Nix。
+
+=== 编译器、MPI
+
+- Intel 编译器（OneAPI）：
+  - 必需，因为对一些软件有优化，fortran 编译器比 gfortran 更宽容。
+  - 在 bscpkgs 打包基础上略作修改（ifort #sym.arrow ifx，icc #sym.arrow icx，icpc #sym.arrow icpx）。
+- Nvidia 编译器（HPC SDK）：
+  - 必需，提供 nvfortran、QD 库等。
+  - 自行打包（`nvhpcPackages.stdenv`）。
+- OpenMPI：
+  - nixpkgs 中的打包需要略作修改才能与闭源编译器兼容。（还没有提pr）
+  - NVIDIA HPC SDK 中的 OpenMPI 缺少 slurm（srun）支持，需要使用 Nvidia 修改过的源代码、再自行编译。
+- 提供 overlay 及示例：`github:CHN-beta/nix-hpc-test`。
+- 仍有需要改进的地方（详见下文）。
+
+=== NixOS上的其它软件和服务
+
+- 文件系统：
   - 使用 NFS 在多节点间共享 `/home`；下层使用 Btrfs 透明压缩/RAID1。
-  - 队列系统使用 SLURM。MPI 尽量使用 OpenMPI、尽量用 `srun` 启动，以正确绑定 MPI进程/OpenMP线程到CPU核心。
-  - 打包 Nvidia HPC SDK，Intel OneAPI 编译器取自 bscpkgs 并略作修改。
-  - 针对特定 CPU 优化（`hostPlatform.gcc.arch`）。nixpkgs 半年更新一次，期间 cherry-pick 个别提交。
-- 在没有 root 权限的集群上：
-  - 使用特别的 store path（例如，`~/.nix/store`），在 NixOS 上编译好再上传。
+  - home-manager 和 impermanence 涉及到的一些文件需要单独处理（详见下文）。
+- 队列系统：
+  - 使用 SLURM，多节点共用一个配置文件，避免配置不同步。
+  - MPI 尽量使用 OpenMPI、尽量用 srun 启动。Intel MPI在少数情况下有些问题。
+  - 提供易用的 TUI 界面代替 sbatch，减少用户犯错的可能。
+- native 优化：
+  - 针对硬件优化（设置 `hostPlatform.gcc.arch`、`oneapiArch`、`nvhpcArch`）。
+  - nixpkgs 半年更新一次，期间仅 cherry-pick 个别提交。平衡“新”、“稳定”与编译整个系统需要的代价。
 
-= 开放性问题与展望
+=== 超算上使用 Nix
 
-== 闭源编译器和 stdenv
-
-- 闭源编译器是必需的，但在 nixpkgs 中没有打包。现有的打包能工作，但质量还不足以合并到 nixpkgs 中。
-  - Nvidia HPC SDK：cc wrapper 中有许多传递给 gcc 的参数 nvfortran 不识别，报警告；与现有 CUDA 兼容性不清楚。
-  - Intel OneAPI：bscpkgs 里只有老版本；简单替换源无法更新到新版本。
-  - OpenMPI：nixpkgs 中的打包需要略作修改才能与闭源编译器兼容。（还没有提pr）
-- Call for help：我的能力有限，需要更了解 stdenv / CUDA 的同学的帮忙。
-
-== 无root权限安装nix
-
-- 尝试过 nix-portable，bwrap 模式在老内核上不支持，proot 严重影响性能。最后决定修改store路径。
-- 不使用profile，通过 symlink join 得到一个 package，与其它机器的配置写在一个 flake 里。
-- 在编译机上需要建立同样的目录作为store路径。若使用`real`参数将store路径指向`/nix/store`，会导致编译机的nix数据库损坏。
+- 没有 root 权限，没有预装 Nix。没有 user namespace 支持。proot 影响性能。
+- 设置 store 为家目录下路径。另外的 NixOS 上建立相同的目录，编译好再上传。
+  - 不能设置 `real` 参数指向 `/nix/store`，否则会破坏编译机的 Nix 数据库。
 
 ```
 # this will break the build machine's nix database
@@ -113,10 +146,58 @@ sudo nix build --store 'local?store=/nix/store&real=/nix/store' .#jykang
 sudo nix build --store 'local?store=/data/gpfs01/jykang/.nix/store&state=/data/gpfs01/jykang/.nix/state&log=/data/gpfs01/jykang/.nix/log' .#jykang
 ```
 
+= 一些开放性问题
+
+== 闭源编译器和 stdenv
+
+- 闭源编译器是必需的，但在 nixpkgs 中没有打包。现有的打包能工作，但质量还不足以合并到 nixpkgs 中。
+  - 闭源编译器依赖 gcc：
+    - 在非 FHS 环境下，需要用参数/环境变量指定 gcc 路径。
+    - stdenv 中不含 gfortran；gfortran 中的 gcc 和 stdenv 中的 gcc 又不太一样。
+  - 闭源编译器不认识一些默认 cc wrapper 里提供的参数（e.g. random seed)。还需要对照文档调整。
+  - bscpkgs 中 Intel OneAPI 为老版本；简单替换源无法更新到新版本，我尝试打新版本也没有成功。
+- #text(red)[Call for help]：我的能力有限，很需要了解 stdenv 的同学的帮忙。
+
 == impermanence / home-manager 与共享文件系统
 
-
-
-== FHSStdenv（构建时FHS环境）
+- 以 `.bashrc` 为例：不同节点的 `.bashrc` 不同，后启动节点上的 home-manager 会覆盖前一个节点的设置。
+  - 解决方法：`.bashrc` 等文件改为 bind mount；`.config` 等目录在非登陆节点上挂载自临时子卷（重启后丢弃）。
+  - home-manager 没有这个选项，需要手动写 `systemd.mounts`。
+- impermanence / home-manager 有时不会正确设置父目录的父目录的所有者，导致新增用户后需要手动调整几个目录的所有者。
+
+== 构建时FHS环境（FHSStdenv）
+
+- 如果一些软件运行时需要 FHS，那么我们能否在*构建时*就提供这个环境，
+  以快速（但低质量地）打包那些需要使用上游提供的脚本/二进制程序进行安装的软件？
+- 这不美观，但很有用！
+- 这个功能现在已经可以实现，但是需要手动写所有命令，不能复用现有的 stdenv 中 setup hook / xxxPhase。
+  能否编写类似于 `stdenv` 的 `FHSStdenv`？
+
+=== 一个例子（曾经的 NVIDIA HPC SDK 打包）
+
+```
+let
+  builder = buildFHSEnv { targetPkgs = _: [ coreutils ]; extraBwrapArgs = [ "--bind" "$out" "$out" ]; };
+  buildScript = writeShellScript "build.sh" ''xxxxx'';
+in stdenvNoCC.mkDerivation
+{
+  pname = "nvhpc";
+  installPhase =
+  ''
+    mkdir -p $out
+    ${builder}/bin/builder ${buildScript}
+  '';
+}
+```
+= 总结
+
+== 总结
+
+我认为 Nix 在科学计算中有很大的潜力，但：
+- 使用不够广泛；我也不知道怎么办。
+  - 明天上午《如何在公司里把 Nix 安利给同事》\@Noa Virellia
+- 缺少一些必要的功能。如果有人帮助我的话，一年足够把障碍扫清。
+
+== 私货！