LAMMPS MPI负载均衡：balance与fix balance

密度不均匀的体系中，几个MPI进程可能拥有很多原子，其他进程却几乎没有工作。本例把256个Lennard-Jones粒子放在长盒子的一端，用4个MPI进程比较一次性的balance与按步检查的fix balance。目标是看清谁负责哪些原子，再确认重分区没有改变结构和物理量。

1. 先看结果，再完整复跑#

下载四进程实操包，解压到新目录：

python3 -m zipfile -e lammps-MPI-load-balance-wave300-*.zip .
cd lammps-MPI-load-balance-wave300
bash preview.sh
sbatch run.slurm
squeue -u "$USER"

预览只重画参考图。提交后run.sh按顺序执行两个真实LAMMPS输入、提取全部256个原子的坐标/力/进程归属、用OVITO着色渲染，最后绘图。输出目录受保护，复跑请重新解压，避免混入上一次结果。

模板申请4个MPI进程、每进程1线程，调用lammps/30Sep2026-p100-gpu中的普通CPU样式；1块GPU随模板分配，本例没有启用GPU势函数。LAMMPS30Sep2026采用GNU13.3/OpenMPI5.0.10构建。这里比较分区正确性，不把几秒的小模型当成加速比测试。

2. 输入模型是什么#

长盒子实际为32×8×8，粒子只在x约0–7的一端。输入使用units lj：长度、能量、力都为LJ约化单位，不对应指定真实材料的Å或eV。lattice fcc 0.5设置局部晶格密度；全盒平均数密度是256/(32×8×8)=0.125，两者不能混为一谈。

cat inputs/command-balance/in.lammps
cat inputs/fix-balance/in.lammps

command-balance/in.lammps完整输入：

units lj
atom_style atomic
atom_modify map array sort 0 0.0
boundary p p p
processors 4 1 1
lattice fcc 0.5
region box block 0 16 0 4 0 4 units lattice
create_box 1 box
region occupied block 0 3.999999 0 3.999999 0 3.999999 units lattice
create_atoms 1 region occupied
mass 1 1.0
pair_style lj/cut 2.5
pair_coeff 1 1 1.0 1.0
neighbor 0.3 bin
neigh_modify every 1 delay 0 check yes
comm_style brick
comm_modify cutoff 3.0
thermo 1
thermo_style custom step atoms pe
thermo_modify norm no flush yes
run 0
write_dump all custom before.dump id type x y z fx fy fz proc modify sort id format float %.16g
variable ep equal pe
print "TOTAL_ENERGY $(v_ep:%.16g)" file energy.dat screen no
balance 1.0 shift x 50 1.05 out balance-bounds.dat
run 0
write_dump all custom after.dump id type x y z fx fy fz proc modify sort id format float %.16g
print "TOTAL_ENERGY $(v_ep:%.16g)" append energy.dat screen no

processors 4 1 1让4个进程初始沿x分区。粒子刚好集中在首个子域，所以起初实际原子数是256／0／0／0。write_dump输出的proc是LAMMPS当时真正的进程归属；图中不是人为按位置染色。

3. balance：立即调整一次#

balance 1.0 shift x 50 1.05 out balance-bounds.dat

第一个阈值用于判断是否需要调整；shift x沿x移动子域边界，最多50次迭代，以1.05作为目标不平衡参照。它不会把原子坐标搬成均匀分布，而是改变进程子域的范围。out保存边界信息。

真实结果：

初始最大/平均为256/64=4，调整后64/64=1。原子数均衡只是负载的一种代理；复杂多体势、邻居数差异和通信开销仍可能导致实际耗时不均。

4. fix balance：运行中周期检查#

第二个输入与前一个相同，只把balance及后续run 0替换为：

fix rebalance all balance 1 1.05 shift x 50 1.05 out balance-bounds.dat
run 1

1表示每一步检查。生产MD可根据密度变化速度增大间隔；调整过于频繁也会增加通信和迁移开销。不要把本例的每步调整直接当作通用最佳设置。

本例没有时间积分器，run 1只触发一次调度与重分区，位置保持不动。日志中的“没有时间积分fix”提示符合这一设计；它不是一条可直接用于采样温度/扩散的MD轨迹。真正的MD需按物理目标配置NVE/NVT/NPT等积分器。

5. 怎么知道物理结果没有变#

cat results/DATA.json
head native-results/command-balance/before.dump
head native-results/command-balance/after.dump
cat native-results/command-balance/energy.dat

提取程序按id对齐原子，比较全部坐标和三分量力，并独立按周期最小镜像计算LJ两体能量和力。两种方法坐标不变，原生能量均约−706.5004286694，调前调后最大力分量差约2.66×10⁻¹⁵约化单位。并行求和顺序会带来最后几位浮点差异，不能要求任意平台的文本字节完全相同。

右侧图按相同x层平均Fx，前后曲线重合只是可视化概览；脚本同时比较全部256×3个力分量，不仅比较图上的平均值。

6. OVITO终端着色与无界面渲染#

自动脚本已经完成此步。如果自己重新渲染，先确保目标输出目录不存在：

module purge
module load ovito/3.16.1
export QT_QPA_PLATFORM=ovitoheadless
export OVITO_GUI_MODE=0
export VK_DRIVER_FILES=/usr/share/vulkan/icd.d/lvp_icd.json
ovitos render.py --data native-results --output my-ovito-images

这里使用已配置的OVITO3.16.1和已有Lavapipe软件驱动，以Tachyon在CPU渲染，不需要图形桌面。若机器上驱动清单名为lvp_icd.x86_64.json，使用实际存在的文件；自动run.sh会检查这两个名字。

render.py通过import_file(..., sort_particles=True)读原始dump，读取Particle Identifier、Position、Force和proc，将进程0–3映射为四种颜色，保留完整盒子。四张单独PNG及读取结果在ovito-images/。

重新汇总自己的数据：

module purge
module load pymatgen/2026.9.24
python plot.py --data results --images my-ovito-images --output my-plots

7. 得到什么，什么时候使用#

native-results/保存两个输入的真实日志、能量、dump与子域边界；results/保存完整NPZ、JSON及CSV；ovito-images/保存四张原生结构渲染；plots/保存两张汇总图。

适合先检查负载均衡的情况包括气液共存、界面、局部团簇、冲击和大空洞等明显密度不均模型。先看实际每进程工作量，再比较包含通信与调整开销的运行时间。密度均匀的小晶体未必受益；使用GPU、KOKKOS或RCB分区时，还需核对相应构建、通信样式和支持范围。

继续看OpenMP与独立分区、原生Python与C接口和MDI外部联用。