在 Slurm 中运行依赖 PETSc/petsc4py 的 Python 脚本时，常因节点间环境差异导致 liblapack.so.3 等共享库找不到；根本原因在于交互式会话所在节点预装了系统级 LAPACK，而计算节点需显式加载对应模块。
在 slurm 中运行依赖 petsc/petsc4py 的 python 脚本时，常因节点间环境差异导致 `liblapack.so.3` 等共享库找不到；根本原因在于交互式会话所在节点预装了系统级 lapack，而计算节点需显式加载对应模块。
当您在本地 shell 中成功导入 petsc4py，却在 srun 执行时遇到如下错误：
ImportError: liblapack.so.3: cannot open shared object file: No such file or directory
这并非 Python 或 petsc4py 安装问题，而是运行时动态链接器无法定位底层线性代数库（如 LAPACK）。Slurm 作业通常调度到专用计算节点，这些节点往往不预装系统级科学计算库（如 /usr/lib64/liblapack.so.3），而依赖模块系统（如 Lmod）按需加载。
✅ 正确解决方案：显式加载 lapack 模块
您已在脚本中加载了 openblas/latest，但 PETSc 编译时可能链接的是 lapack（而非仅 OpenBLAS），尤其当使用系统或模块提供的 PETSc 时。因此，必须补全 lapack 模块：
#!/bin/bash
#SBATCH --job-name=petsc4py_import_test
#SBATCH --ntasks=2
#SBATCH --cpus-per-task=8
#SBATCH --time=00:30:00
#SBATCH --output=output.log
#SBATCH --error=error.log
#SBATCH --nodes=1
source $HOME/.bash_profile
module purge
# 关键修正：添加 lapack/latest（顺序建议放在 openblas 之后，避免符号冲突）
module load python/3.10.0 openmpi gcc openblas/latest lapack/latest slurm
source $HOME/my_env/bin/activate
# 推荐：显式导出关键库路径（增强健壮性）
export LD_LIBRARY_PATH="${LAPACK_ROOT}/lib:${OPENBLAS_ROOT}/lib:${LD_LIBRARY_PATH}"
srun --export=ALL --mpi=pmix_v3 python3 petsc4py_test.py
? 验证模块是否提供所需库：可在登录节点执行
module show lapack/latest，检查输出中是否包含liblapack.so*的路径；也可运行module load lapack/latest && find $LAPACK_ROOT -name "liblapack.so*"快速确认。
⚠️ 注意事项与最佳实践
-
不要依赖
--export=ALL解决所有环境问题：该参数仅传递当前 shell 的环境变量，但模块加载产生的LD_LIBRARY_PATH、PETSC_DIR等变量需在srun前已生效（即module load必须在srun之前）。 -
避免模块加载顺序冲突：若同时加载多个 BLAS/LAPACK 相关模块（如
openblas,lapack,scalapack），建议按依赖关系排序，并优先使用同一供应商的配套模块（例如 Intel MKL 提供的统一 BLAS+LAPACK，或 OpenBLAS + Reference LAPACK）。 -
调试技巧：在作业脚本开头添加诊断命令，快速定位缺失库：
srun --export=ALL bash -c 'echo "LD_LIBRARY_PATH: $LD_LIBRARY_PATH"; ldconfig -p | grep lapack; python3 -c "from petsc4py import PETSc; print(PETSc.Sys.getVersion())"'
-
长期建议：若频繁使用 petsc4py，可考虑用
conda或spack构建完全自包含的环境，规避模块系统碎片化问题。
通过显式加载 lapack 模块并合理管理 LD_LIBRARY_PATH，即可确保 PETSc 及其 Python 封装在 Slurm 分布式环境中稳定链接和运行。
