批量分子动力学退火脚本实战：从LAMMPS模板到Shell调度

做了这么多年分子动力学模拟，我越来越觉得退火（annealing）脚本就是个看似简单、实际特别考验功底的东西。你单独跑一条温度循环，怎么折腾都行；但一旦要把几十个初始构型、好几组温度区间、不同升降温速率全部批量跑完，脚本设计得好不好，直接决定你是“挂机等结果”还是“每天手动改文件改到怀疑人生”。今天这篇就专门聊批量MD退火脚本，从物理原理到LAMMPS实际配置，再到Shell批量调度和结果汇总，一次讲透。

批量退火这个需求，通常在材料体系的结构搜索、无定形样品平衡、聚合物链松弛、界面吸附构型优化等场景下出现。核心想法很简单：把体系加热到高温让它越过势垒，再缓慢降温到目标温度，让结构落入更稳定的局域极小值。但如果你的研究对象有几十个候选构型，或者要扫一排温度区间，那手写一个个输入文件再逐个运行，不仅枯燥，而且极易出错。写一套能自动生成任务、批量提交、自动收敛判定的脚本，才是正经做法。

这篇文章适合正在做分子动力学模拟的研究生、工程师，也适合刚接触LAMMPS但想规范自己工作流的同学。下面我会先拆解退火模拟的物理逻辑，再给出可复用的LAMMPS退火脚本模板，然后重点讲批量化的目录结构、参数扫描和Shell调度思路，最后把我在实际运行里踩过的坑和排查方法一并列出来，方便你对照检查。

1. 内容整体设计与思路拆解

1.1 退火在MD里到底解决了什么问题

分子动力学里，体系经常会卡在亚稳态。尤其是有机分子、聚合物、表面吸附体系，初始构型稍微不合理，平衡半天结构也“拧”不过来。退火的核心思路是借助热涨落让体系翻越能垒。具体做法是先把温度升到比较高的值，让原子动能足够大，体系能摆脱局域极小值的束缚；然后再缓慢降低温度，让体系沿着势能面逐渐“滑”到更深、更稳定的能量低谷。这个过程对应实验里的“退火”工艺，只不过在MD里我们能在纳秒尺度内完成。

理解这一点对脚本设计很重要。因为升温端的温度上限不是随便定的，它受限于你用的力场。比如CVFF、COMPASS这类经验力场，在600 K以上某些二面角参数会变得不太合理，结构可能直接“散架”。而像ReaxFF这类反应力场虽然能容忍更高温度，但计算成本也高得多。所以标题里的“批量退火”实际上是两件事的组合：一是把退火循环本身设计合理，二是把不同条件的组合批量跑出来对比，找到最优处理路径。

1.2 单次退火和批量退火的本质差异

很多人觉得批量退火无非是复制粘贴再改改参数，其实没那么简单。单次退火你只需要关注这一条轨迹的能量、温度是否按预期变化；但批量退火是一个完整的“实验设计”问题。比如你要对10个不同初始构型分别做5组退火方案，总的就有50个独立任务，每个任务还要考虑随机种子、初始速度分配、压力耦合差异，结果天然带有统计涨落。脚本设计的目标就是用统一流程把这些涨落控制住，让所有任务在相同逻辑框架下运行，避免人为改动带来的不公平对比。

批量脚本还有一个隐性需求：可重复性和可追溯性。你跑完一批任务，过两周要写论文，得能快速说清楚每个任务用了什么参数、跑了几轮退火循环、最终能量多少。如果脚本没有自动记录参数和结果，后期整理数据会非常痛苦。所以从设计思路上，批量退火脚本从一开始就要包含“目录结构规范 + 模板文件 + 参数注入 + 日志输出 + 结果汇总”这几层结构，而不是简单地把多个in文件丢进同一个文件夹里。

2. 核心细节解析与实操要点

2.1 温度循环的参数怎么定

退火脚本里最关键的是一组温度-时间曲线。我常用的方案是线性分段循环：从300 K升温到500 K，再降到200 K，再回到300 K，这样算一个循环。升温速率不要设置得太激进，一般建议每步温度变化不超过1 K，也就是如果时间步长是1 fs，升温速率设为0.001 K/步到0.005 K/步比较稳妥。换算一下，从300 K升到500 K，以0.002 K/步计算，需要100000步，也就是100 ps。一次完整的升温-降温循环大概300 ps左右。

为什么要控制升温速率？因为退火的本质是“准静态”过程。如果升温太快，体系来不及重新分布构型，高温段就白白浪费了，降温时又会掉回原来的亚稳态。反之，如果升温太慢，计算成本太高。我个人的经验是，批量扫描时先用粗速率跑一轮，比如0.01 K/步，看看能量曲线是否出现明显平台，再针对感兴趣的温度区间加密。

温度循环的另一个关键参数是驻留时间。在最高温和最低温各保持多久也有讲究，最高温处需要让体系充分“熔化”重排，我通常驻留50 ps以上；最低温处则让结构逐渐弛豫，驻留时间可以减半。这个设计可以放在循环里自动判断，比如用run命令的stop参数控制。

2.2 NVT还是NPT，退火时用哪个系综

退火过程里系综的选择直接影响结构弛豫效果。我建议升温段和高温驻留段用NVT，固定体积，只让温度变化；降温段如果模拟的是液相或无定形体系，可以切到NPT，让体积和密度跟着温度走。如果全程用NPT，温度剧烈变化时压强耦合容易出现振荡，尤其在升温初期体系还没平衡好的时候，经常出现压强数值爆炸，导致模拟失败。

以LAMMPS为例，具体做法是用fix nvt跑升温段和高温段，用fix npt跑降温段。要注意的是切换系综时要重新设置时间积分器，不能在一个run命令里换。标准写法是在升温结束后先unfix原来的温度耦合，再定义新的fix npt。还有一个容易踩的坑是降温段NPT的压强设置。如果是三维周期性体系，各向同性压强调控比较稳妥；如果是表面或界面体系，最好用各向异性升温，固定垂直于界面的方向，让另外两个方向自由弛豫。

2.3 力场和步长也得提前校对

批量退火前，最好在单体系上小规模验证力场在高温段的稳定性。我实测过有些力场在400 K以内表现良好，到了500 K分子开始“飞”出盒子，原因往往是范德华参数截断设置不合理或者静电力处理方式不适合高温高动能状态。长程静电力如果是用PPPM，切换精度稍低一些会加速计算，但退火中原子移动剧烈，力计算误差太大会导致能量漂移，建议real-space cutoff和kspace精度保持和正式平衡一致。

时间步长在高温段也需要注意。常规MD用1 fs没问题，但升温到高温后原子运动加剧，如果出现能量溢出，首先把步长降到0.5 fs试试。批量脚本里可以考虑按温度区间动态调整步长，不过这种方法会增加调度的复杂度，我一般只在单点问题排查时使用，批量跑还是统一用固定步长更省心。

3. 实操过程与核心环节实现

3.1 先搭好目录结构，批量任务才有章法

批量跑退火，第一步不是写脚本，而是设计目录。我的标准目录结构如下，每个任务独占一个子目录，模板文件放在项目根目录，生成脚本负责把模板“渲染”到各个子目录里。

bash复制project_root/
├── templates/
│   ├── in.anneal.template
│   └── data.structure     # 初始构型文件
├── tasks/
│   ├── config_001/
│   ├── config_002/
│   └── config_003/
├── generate_jobs.sh       # 生成任务目录和输入文件
├── run_all.sh             # 批量提交脚本
└── results_summary.sh     # 结果汇总脚本

每个task目录里再按固定结构存放输入文件和输出文件。我喜欢把in文件固定命名为in.anneal，data文件也统一命名，这样后续批量处理脚本只需要固定几个路径就行，不用每次解析文件名。日志和轨迹文件最好单独放子目录，避免一堆输出文件堆在根目录里难以清理。

3.2 LAMMPS退火输入模板怎么设计

下面是一个可实际使用的LAMMPS退火输入模板，我这里用它来跑一个常见的“聚合物/无定形碳/界面体系”三循环退火流程。注意模板里使用了变量占位符，后续用sed或者Python脚本替换这些变量，就能批量生成不同任务。

bash复制# in.anneal.template
variable        T_init          equal ${T_START}
variable        T_high          equal ${T_HIGH}
variable        T_low           equal ${T_LOW}
variable        T_final         equal ${T_FINAL}
variable        dthigh          equal ${T_UP_TIME}
variable        dtlow           equal ${T_DOWN_TIME}
variable        holdhigh        equal ${HOLD_HIGH_TIME}
variable        holdlow         equal ${HOLD_LOW_TIME}
variable        ncycles         equal ${N_CYCLES}
variable        seed            equal ${SEED}

units           real
atom_style      full
boundary        p p p
pair_style      lj/cut/exp 10.0 1.3
bond_style      harmonic
angle_style     harmonic
dihedral_style  opls
improper_style  cvff

read_data       data.structure
replicate       1 1 1

# 力场参数统一设置到参数文件
include         ../templates/params.ff

velocity        all create ${T_init} ${seed} rot yes dist gaussian

neighbor        2.0 bin
neigh_modify    every 1 delay 0 check yes

# 升温段：NVT 到 T_high
fix             fwarm all nvt temp ${T_init} ${T_high} 100.0
thermo          1000
thermo_style    custom step temp press pe ke density
timestep        1.0
run             ${dthigh}
unfix           fwarm

# 高温驻留：NVT
fix             fhold all nvt temp ${T_high} ${T_high} 100.0
run             ${holdhigh}
unfix           fhold

# 降温段：NPT 到 T_low
fix             fcool all npt temp ${T_high} ${T_low} 100.0 iso 1.0 1.0 1000.0
run             ${dtlow}
unfix           fcool

# 低温驻留：NVT
fix             fholdlow all nvt temp ${T_low} ${T_low} 100.0
run             ${holdlow}
unfix           fholdlow

# 升温回到 T_final
fix             fheattwo all nvt temp ${T_low} ${T_final} 100.0
run             ${dthigh}
unfix           fheattwo

# 最终平衡
fix             ffinal all npt temp ${T_final} ${T_final} 100.0 iso 1.0 1.0 1000.0
run             50000
unfix           ffinal

write_data      final.data
write_dump      all custom final.dump id type x y z ix iy iz id type element

这个模板有几个关键点。第一，升温和降温过程都是用fix的t_start和t_stop参数控制温度变化速率，LAMMPS会根据你给的run时长自动做线性插值。第二，驻留段的基本写法是t_start等于t_stop，也就是恒温。第三，降温段我用的是NPT，并且在降温结束后重新用NVT驻留，避免压强耦合在恒温阶段干扰结构。最后，整个流程结束前加了一段50000步的NPT平衡，这一步主要是让结构在目标温度下充分弛豫，为后续的产量模拟做准备。

3.3 批量任务生成脚本怎么写

有了模板，接下来需要一个生成脚本。我通常用Bash加Python混合的方式：Bash负责目录创建和循环控制，Python负责替换占位符和生成汇总表格。如果只想用一个纯Bash脚本，其实sed也可以完成任务。下面这个generate_jobs.sh脚本会遍历一个参数列表文件，为每一行参数组合创建一个任务目录，并生成对应的in.anneal和提交脚本。

bash复制#!/bin/bash
# generate_jobs.sh
# 参数列表格式：config_id T_START T_HIGH T_LOW T_FINAL T_UP_TIME T_DOWN_TIME HOLD_HIGH_TIME HOLD_LOW_TIME N_CYCLES SEED
# 示例：config_001 300 500 200 300 100000 100000 50000 50000 3 12345

PARAM_FILE="param_list.dat"
TEMPLATE_DIR="templates"
TASK_ROOT="tasks"

mkdir -p "${TASK_ROOT}"

while read -r config_id tstart thigh tlow tfinal tup tdown holdhigh holdlow ncycles seed; do
    if [[ $config_id == "#"* || -z $config_id ]]; then
        continue
    fi

    task_dir="${TASK_ROOT}/${config_id}"
    mkdir -p "${task_dir}/logs"
    mkdir -p "${task_dir}/traj"

    cp "${TEMPLATE_DIR}/data.structure" "${task_dir}/data.structure"
    cp "${TEMPLATE_DIR}/params.ff" "${task_dir}/params.ff"

    sed -e "s/\${T_START}/${tstart}/g" \
        -e "s/\${T_HIGH}/${thigh}/g" \
        -e "s/\${T_LOW}/${tlow}/g" \
        -e "s/\${T_FINAL}/${tfinal}/g" \
        -e "s/\${T_UP_TIME}/${tup}/g" \
        -e "s/\${T_DOWN_TIME}/${tdown}/g" \
        -e "s/\${HOLD_HIGH_TIME}/${holdhigh}/g" \
        -e "s/\${HOLD_LOW_TIME}/${holdlow}/g" \
        -e "s/\${N_CYCLES}/${ncycles}/g" \
        -e "s/\${SEED}/${seed}/g" \
        "${TEMPLATE_DIR}/in.anneal.template" > "${task_dir}/in.anneal"

    echo "Generated: ${task_dir}/in.anneal"
done < "${PARAM_FILE}"

看到这里你可能会问：N_CYCLES参数在模板里怎么没用上？确实，上面的模板只跑了一轮升温-降温循环。如果要做多循环退火，我通常用LAMMPS的jump命令或label loop实现。下面这段是典型的多循环写法，适合需要反复“训练”结构的场景：

bash复制# 多循环退火片段
label           loop_start
variable        i loop ${N_CYCLES}

# 升温：T_low -> T_high
fix             fcyc all nvt temp ${T_low} ${T_high} 100.0
run             ${dthigh}
unfix           fcyc

# 高温驻留
fix             fcyc_hold all nvt temp ${T_high} ${T_high} 100.0
run             ${holdhigh}
unfix           fcyc_hold

# 降温：T_high -> T_low
fix             fcyc_cool all npt temp ${T_high} ${T_low} 100.0 iso 1.0 1.0 1000.0
run             ${dtlow}
unfix           fcyc_cool

# 低温驻留
fix             fcyc_low all nvt temp ${T_low} ${T_low} 100.0
run             ${holdlow}
unfix           fcyc_low

next            i
jump            SELF loop_start

注意jump命令使用SELF时会回到当前输入文件开头重新执行，配合next循环变量实现循环。这个方法比在命令行里多次调用run更简洁，也方便在循环里控制中间输出频率。循环体内需要适时写dump或thermo，但要注意别让轨迹文件太大，我一般每5000步写一帧，多循环下来数据量还可控。

3.4 批量提交和运行状态监控

任务生成后，批量提交脚本就简单多了。下面这个run_all.sh遍历所有任务目录，检查in.anneal是否存在，再调用LAMMPS可执行文件运行。我习惯加上日志文件名，后续排查问题直接看log.lammps文件就行。

bash复制#!/bin/bash
# run_all.sh
LAMMPS_EXEC="lmp_mpi"
TASK_ROOT="tasks"
CORES_PER_TASK=4

for task_dir in ${TASK_ROOT}/config_*/; do
    if [ ! -f "${task_dir}/in.anneal" ]; then
        echo "Skip ${task_dir}: no in.anneal"
        continue
    fi

    cd "${task_dir}" || exit 1
    echo "Running ${task_dir} at $(date)"

    mpirun -np ${CORES_PER_TASK} ${LAMMPS_EXEC} -in in.anneal \
        -log log.lammps -screen screen.out &

    cd - > /dev/null 2>&1
done

wait
echo "All tasks completed at $(date)"

这种写法适合单机多核环境。如果是在集群上用Slurm或者PBS调度，思路也差不多，把mpirun换成srun或提交作业脚本即可。真正要注意的是并发数控制：一个节点上同时跑的MPI任务太多，内存和CPU争抢严重，反而拖慢整体速度。我通常先跑两三个任务测试一下单任务的耗时和内存占用，再决定并发上限。上面脚本里用了wait，会让所有任务并行跑完后再退出，如果中途某个任务崩溃，wait并不会报错，所以还要配合结果检查脚本。

3.5 结果自动汇总与有效性判定

批量跑完之后，最烦的是从几十个log文件里提取能量和密度数据。我写了一个results_summary.sh脚本，用grep从log.lammps里抓取thermo输出的最后一帧能量和温度，再汇总到一个CSV文件。如果发现某个任务在高温段温度突变，或者能量不对，就标记为FAILED，方便排查。

bash复制#!/bin/bash
# results_summary.sh
TASK_ROOT="tasks"
OUTPUT_FILE="summary.csv"
echo "task,temp,pe,density,status" > "${OUTPUT_FILE}"

for task_dir in ${TASK_ROOT}/config_*/; do
    logfile="${task_dir}/log.lammps"
    if [ ! -f "${logfile}" ]; then
        echo "${task_dir},NA,NA,NA,NO_LOG" >> "${OUTPUT_FILE}"
        continue
    fi

    temp=$(grep -A 1000000 "Step Temp" "${logfile}" | tail -n 1 | awk '{print $3}')
    pe=$(grep -A 1000000 "Step Temp" "${logfile}" | tail -n 1 | awk '{print $4}')
    density=$(grep -A 1000000 "Step Temp" "${logfile}" | tail -n 1 | awk '{print $6}')
    status="OK"

    if [ -z "$temp" ] || [ -z "$pe" ]; then
        status="FAILED"
    fi

    echo "${task_dir},${temp},${pe},${density},${status}" >> "${OUTPUT_FILE}"
done

cat "${OUTPUT_FILE}"

这里有个小技巧：thermo_style里我固定了输出顺序，第3列是温度，第4列是势能，第6列是密度。后续无论是用Python还是Excel分析，都能保持列顺序一致，不需要在脚本里写死变量名。顺便说一句，如果中途某个任务跑飞了，log的最后一行不一定是Step Temp开头的数据，脚本里判断temp和pe为空就标FAILED，这个办法能快速过滤出问题任务。

不过用grep tail这种办法只是粗略检查，如果需要更精细的能量曲线分析，我建议在LAMMPS里额外用fix print把每5000步的势能写到单独文件，后面用Python做图。这个实操很简单，但批量任务里加上之后，后期画势能-温度曲线能省不少事。

4. 常见问题与排查技巧实录

4.1 高温段能量溢出

批量跑退火最常见的问题是高温段能量溢出，表现为log文件里出现“Step: ... Energy: ... nan”或者原子速度过大导致计算崩溃。原因通常是初始构型在高温下局部原子重叠严重，或者温度上限超过力场适用范围。这种问题在单任务时很容易定位，批量跑时就麻烦在中间某一个任务挂掉，其他任务还在跑，等你发现已经是几个小时后了。我的习惯是在参数列表里把温度上限先做一轮扫描测试，比如300 K、400 K、450 K、500 K分别跑一小段，看哪个温度开始出现能量异常，再设定最终生产任务的上限值。

如果确定是初始构型问题，可以先做一轮能量最小化再开始退火。在in.anneal模板开头加上minimize命令就行，我现在写退火脚本基本都会保留这个步骤，成本很低但能规避大量莫名其妙的nan问题。

4.2 温度没按预期变化

有时候退火跑完了，发现thermo输出的温度全程恒定在300 K附近，完全没升上去。这个情况八成是你把fix nvt的t_start和t_stop写反了，或者run步数太少，升温区间还没覆盖到就让run结束了。排查方式很简单，直接用grep抓log里的Temp列，看前1000步和后1000步的温度变化趋势，如果温度原地踏步，检查t_start/t_stop是否不一致。

还有一种情况是升温速率太慢，比如run步数设置太小，温度确实在变，但曲线还没到设定的最高温度，run就结束了。这种情况模板本身不会报错，但后续降温段的起始温度会和预期不一致。所以我在生成脚本时会在任务目录里额外写一个run_params.json，把每个任务设定的T_HIGH、T_UP_TIME等原始参数记录下来，方便事后核对。

4.3 批量任务里个别任务静默失败

静默失败是最恶心的：任务进程正常退出了，log文件也有，但实际只跑了很少的步数。常见原因是某一步文件读取失败，比如data文件里原子数不匹配，或者params.ff文件路径写错了。LAMMPS遇到这类问题通常会直接报错退出，但有些配置错误不会立即报错，比如pair_coeff设置的范围不对，导致某些原子对没有匹配的LJ参数，跑久了力计算全错但log看起来正常。

解决思路是加一个“最短运行步数”检查。比如每个任务的in.anneal末尾我会用variable write写一个完成标记文件，如果任务正常完成，标记文件里会有最后一步的时间戳。结果汇总脚本里检查这个标记文件是否存在，以及步数是否达到预期值，就能自动判定哪些任务属于静默失败，不用人工翻log。

4.4 并发任务抢占资源导致全盘变慢

最后说一下批量性能调优。很多人喜欢开很大的并发数，比如48核机器直接开24个双核任务，结果所有任务都在抢内存带宽，总吞吐量反而下降。退火任务对CPU算力要求高，对I/O要求相对低，但轨迹文件频繁写入时磁盘也会成为瓶颈。我通常的做法是核数不要超过物理核数的一半，同时把轨迹文件写到一个独立的SSD目录，避免和系统盘混用。

如果单个体系很大，比如几万个原子，更好的方案不是开一堆小并发，而是用MPI并行跑几个任务，每个任务占24核左右。这样热力学数据和轨迹文件的数量都会少一点，后期分析也轻松。

5. 再聊聊脚本扩展方向的实用经验

批量退火脚本跑通之后，你会发现它几乎可以直接迁移到其他MD场景。比如把退火温度循环改成线性降温，就变成“冷冻”模拟；把温度扫描改成压强扫描，就变成等温等压搜索；把多循环退火接到系综采样里，还能做类似并行退火（parallel tempering）的粗粮版本，虽然没有交换步骤严格，但工程上够用。

我个人的实际体会是，脚本本身不复杂，真正值钱的是“每一步都在做什么、为什么这么做”想清楚了。比如为什么高温段用NVT、降温段用NPT，为什么升温速率控制在0.002 K/步以内，为什么模板目录和任务目录要分开。这些决策直接决定了批量结果的可靠性和可解释性。你在跑任务前多花半小时把逻辑理清，后期能省一天。

最后再分享一个小技巧：生成脚本时，可以在每个任务目录放一个README.txt，用固定格式记录参数列表文件的原始行内容。这样哪怕过了两个月，你翻到config_005目录，也能一眼看出这一组任务当初设定了多少温度、多少循环、用的哪个随机种子，不用再猜。这套方法帮我避免了很多次“这个结果到底怎么跑出来的”的尴尬。