4、使用环境模块管理依赖：module load/use 技巧与最佳实践

HPC 集群上装 GROMACS，最头疼的是什么？我猜八成是依赖链。MPI、FFTW、OpenBLAS、CUDA……每个版本都得对上。你手动配过 LD_LIBRARY_PATH 吗？配完一个编译通过，换到另一个节点又崩了。说白了，这是环境管理的灾难。

我今天要讲的就是怎么用 环境模块（Environment Modules） 把这堆乱麻理清楚。我自己在三个超算中心折腾过 GROMACS 部署，最后发现：用 module 锁依赖，省下的时间够你喝好几杯咖啡。

4.1 为什么非用环境模块不可？

先看一个反面教材。假设你要用 Intel MPI + MKL + CUDA 11.8 编译 GROMACS 2024。如果不靠模块，你会写成这样：

export PATH=/opt/intel/mpi/2021.10/bin:$PATH
export LD_LIBRARY_PATH=/opt/intel/mkl/2021.4/lib/intel64:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=/usr/local/cuda-11.8/lib64:$LD_LIBRARY_PATH
export CPATH=/opt/intel/mpi/2021.10/include:$CPATH
……（还有十几行）

手动 export 的问题很明显：不可回滚、不可复用、容易冲突。你切换到另一个项目需要 GNU 工具链时，得小心翼翼地改回去。一不留神就“库污染”了。

环境模块就是来解决这个问题的。它让每一组依赖变成一个可加载的“环境快照”。你只需要：

module purge
module load intel/2021.10
module load impi/2021.10
module load cuda/11.8
module load gromacs/2024-plumed

走人。干净，彼此不干扰。

4.2 Module 的两种核心命令：load 与 use

先明确一个概念：module load 是从系统默认的模块路径加载，而 module use 是你自己添加额外的模块搜索路径。我习惯把团队自建的模块放在一个目录下，然后用 use 临时挂载。

4.2.1 module load —— 日常使用

命令语法简单，但有几个细节你可能会忽略。

# 加载单个模块
module load gcc/11.2.0

# 同时加载多个模块
module load cmake/3.26.3 openmpi/4.1.5 fftw/3.3.10

# 查看当前加载的模块
module list

# 卸载模块
module unload gcc/11.2.0

# 完全清空所有模块
module purge

我遇到过一个问题：有些集群的 module load 顺序很重要。比如你得先加载 MPI 再加载 CUDA，否则 mpiicc 可能找不到 NVCC 的路径。所以我的原则是：加载顺序通常按“基础工具链 → 并行库 → 加速器库 → 应用程序”。

4.2.2 module use —— 自定义模块仓库

你公司内部可能维护了一套优化过的 GROMACS 及其依赖。放在哪里？我建议统一放到 /share/apps/modulefiles/ 下。然后用 module use 挂载：

export MODULEPATH_CUSTOM=/share/apps/modulefiles
module use $MODULEPATH_CUSTOM

如果你想把这条命令固化到每个用户的登录脚本里，可以写到 /etc/profile.d/modules_custom.sh 里。这样所有用户登录后自动就能 module load 你们团队的模块了。

不过要注意：module use 只是临时添加搜索路径。如果用户重新登录，需要重新执行。所以最佳实践是写到 .bashrc 或 .cshrc 里。

4.3 模块文件的编写规范

很多管理员只会用别人写好的模块文件，但不会自己写。其实写一个模块文件非常简单，本质就是个 Tcl 脚本（部分集群也可以用 Lua 格式）。我给你们看一个标准模板：

#%Module1.0
##
## modulefile for GROMACS 2024 with PLUMED
##

proc ModulesHelp { } {
    puts stderr "Loads GROMACS 2024 built with PLUMED, double precision."
}

module-whatis "GROMACS 2024 with PLUMED (double precision)"

# 加载依赖
module load gcc/11.2.0
module load openmpi/4.1.5
module load fftw/3.3.10
module load cuda/11.8

# 设置环境变量
set     root    /share/apps/gromacs/2024-dp
prepend-path    PATH        $root/bin
prepend-path    LD_LIBRARY_PATH  $root/lib64
prepend-path    CPATH       $root/include
prepend-path    PKG_CONFIG_PATH $root/lib64/pkgconfig

# 设置 GROMACS 特定变量
setenv  GMX_GPU_DDR  1
setenv  GMX_MPI  1

注意几点：

• 第一行必须是 #%Module1.0，这是文件头。
• module-whatis 简单描述这个模块是干啥的。
• proc ModulesHelp 显示帮助信息。
• 用 prepend-path 而不是 setenv 来追加路径，避免覆盖已有值。
• 依赖用 module load 写在模块文件内部，这样用户只需 module load gromacs/2024-dp 就能自动拉入 GCC、MPI、FFTW、CUDA。

我曾经踩过一个坑：在模块文件里写死了 setenv LD_LIBRARY_PATH /some/path，结果把系统自带的库路径全冲掉了。后来一律改 prepend-path，再也没出过问题。

4.4 模块的版本管理与别名

你集群上可能有多个 GROMACS 版本：2023、2024、2024-dp、2024-plumed。怎么管理？最简单的办法是在 modulefiles 目录下建子目录，然后用 .version 文件设置默认版本。

/share/apps/modulefiles/gromacs/
├── 2023
├── 2024
├── 2024-dp
├── 2024-plumed
└── .version

.version 文件内容：

#%Module1.0
set ModulesVersion "2024-plumed"

这样用户输入 module load gromacs，会自动加载 gromacs/2024-plumed。如果想加载其他版本，必须显式指定 module load gromacs/2023。

另外，你还可以创建别名模块（symbolic link），比如：

cd /share/apps/modulefiles
ln -s gromacs/2024-plumed gromacs/default

然后用户可以用 module load gromacs/default。不过我个人不太推荐用符号链接，因为 module 加载时显示的版本名还是解析后的真实版本，可能会让用户困惑。用 .version 更规范。

4.5 实战：GROMACS 依赖链的模块化管理

下面我给一个完整的流程。假设你要在集群上部署一套 GROMACS 2024 + PLUMED + CUDA 11.8 + OpenMPI 4.1.5 的组合。

步骤	操作	说明
1	编译基础工具链	GCC 11.2.0，安装到 /share/compilers/gcc/11.2.0
2	编译 MPI	OpenMPI 4.1.5，用 GCC 编译，安装到 /share/libs/openmpi/4.1.5
3	编译 FFTW	FFTW 3.3.10（单/双精度），安装到 /share/libs/fftw/3.3.10
4	安装 CUDA Toolkit	已由系统管理员部署在 /usr/local/cuda-11.8
5	编译 GROMACS	使用上述工具链，cmake 配置带 -DGMX_GPU=CUDA -DGMX_MPI=ON
6	编写模块文件	为每一层依赖编写模块文件，顶层 GROMACS 模块自动加载下层模块
7	测试加载	module purge ; module load gromacs/2024-plumed ; gmx_mpi --version

4.6 避坑指南与最佳实践

避坑1：不要忘记 module purge

我见过有些同事在一个 shell 会话里反复 module load 不同版本的库，最后环境变得跟“炒面”一样。你的习惯应该是：在每次开始新项目前，先执行 module purge，然后重新加载当前项目需要的模块组。

避坑2：共享模块路径的权限

多用户共享的模块目录，建议权限设为 755（目录可读可执行，文件可读），并且由管理员统一管理。我曾经把一个模块文件不小心写成 700 权限，导致其他用户加载时报错“无法读取模块文件”。检查了一个小时才发现是权限问题。

避坑3：module use 的顺序

如果你同时加载了系统默认模块路径和自定义模块路径，系统会按 MODULEPATH 的先后顺序查找。所以如果你希望自定义模块覆盖系统模块，一定要把自定义路径放在前面：

module use /my/modulefiles
# 然后再加载默认系统模块

最佳实践：用脚本一键加载项目环境

我习惯为每个项目编写一个 env.sh 启动脚本：

#!/bin/bash
# 加载 GROMACS 2024 开发环境
module purge
module load gcc/11.2.0
module load openmpi/4.1.5
module load fftw/3.3.10
module load cuda/11.8
module load gromacs/2024-plumed
echo "Ready for GROMACS 2024 with PLUMED"

用户只需 source env.sh，环境就就绪了。干净、可复现。

4.7 module 工作流总览

下面这张图可以帮助你理解整个“依赖→编译→模块化→加载”的流程。