先不要急着执行 cmake

LAMMPS 的 GPU 加速问题通常不出在某一条编译命令,而是出在版本组合没有先定下来:驱动能支持的 CUDA 上限、Toolkit 实际版本、GCC 版本、MPI 实现、LAMMPS 日期版本、以及到底使用 GPU package 还是 KOKKOS package。

如果这些信息没有记录,后面即使编译通过,也很难判断运行时到底在用 CPU、GPU package 还是 KOKKOS 后端。

基础信息采集

建议先把下面几组命令输出保存到同一个记录文件里:

hostnamectl
uname -a
lscpu | sed -n '1,25p'
nvidia-smi
nvcc --version
gcc --version
which mpicxx
mpicxx --version

如果系统使用 Environment Modules 或 Lmod,还要记录:

module list
module avail cuda
module avail mpi

选择 GPU package 还是 KOKKOS

GPU package 和 KOKKOS package 都可以让 LAMMPS 使用 NVIDIA GPU,但适用习惯不同。

GPU package 更像传统加速包,常见运行方式会配合 -sf gpupackage gpu 等参数。它适合已有输入文件围绕 GPU package 写好的场景。

KOKKOS 是更通用的性能可移植层,常见运行方式会配合 -k on g N-sf kkkokkos 相关参数。新项目如果希望以后兼顾不同硬件后端,通常更值得优先评估 KOKKOS。

不建议在不理解输入文件和势函数支持情况时简单追求“两个都开”。很多实际问题不是 LAMMPS 没有编译出 GPU,而是所用 pair style、fix 或 package 本身不支持对应后端。

CMake 配置示例

下面只是示例,不应直接复制到所有机器。Kokkos_ARCH_* 必须根据 GPU 架构调整。

cmake ../cmake \
  -D CMAKE_BUILD_TYPE=Release \
  -D BUILD_MPI=on \
  -D BUILD_OMP=on \
  -D PKG_KOKKOS=on \
  -D Kokkos_ENABLE_CUDA=on \
  -D Kokkos_ENABLE_OPENMP=on \
  -D Kokkos_ARCH_AMPERE80=on

cmake --build . -j "$(nproc)"

如果使用传统 GPU package,配置方向会不同:

cmake ../cmake \
  -D CMAKE_BUILD_TYPE=Release \
  -D BUILD_MPI=on \
  -D PKG_GPU=on \
  -D GPU_API=cuda \
  -D GPU_ARCH=sm_80

验收不要只看 lmp 是否存在

至少做三层检查:

./lmp -h | grep -E 'KOKKOS|GPU|Installed packages'
ldd ./lmp | grep -E 'mpi|cuda|kokkos'
mpirun -np 2 ./lmp -in ../examples/melt/in.melt

KOKKOS 路径建议再跑一次显式参数:

mpirun -np 2 ./lmp -k on g 1 -sf kk -in ../examples/melt/in.melt

验收记录里应保留 LAMMPS 版本、CMakeCache、最终可执行文件路径、测试输入文件、运行命令和输出日志。否则后续升级驱动、切换 MPI 或迁移服务器时很难复现。

常见误区

  • 只记录 nvidia-smi,不记录 nvcc --version。驱动版本和 Toolkit 版本不是一回事。
  • 编译时使用一个 MPI,运行时加载另一个 MPI,最后表现为 libmpi.so 或 ABI 问题。
  • 看到 GPU 利用率低就判断编译失败。小体系、I/O、邻居列表和 CPU/GPU 分工都会影响利用率。
  • 盲目启用所有 package。LAMMPS package 越多,外部依赖和冲突面越大。