做分子动力学模拟的人十有八九都要和LAMMPS打交道。不管你是做材料、化学、生物还是流体只要想在原子尺度上观察一个体系随时间的变化LAMMPS基本是绕不开的选择。但这个开源软件的入门曲线实在不算平缓尤其是第一次面对in文件时不少人会觉得自己看的是天书units、atom_style、pair_coeff、fix nvt这些命令到底在干什么为什么别人给的in文件能直接跑自己照着写就报错这篇文章我想把我自己从“照着网上教程抄in文件”到“能独立写一个完整模拟流程”这段经历整理出来说说in文件到底是怎么组织起来的从初始化、建模型、设力场到提交运行、调参排错整个流程里哪些环节最容易卡住又有哪些经验可以让你少走弯路。不管你是刚装好LAMMPS还没跑通第一个例子还是已经能跑简单体系但总觉得哪里不对劲这篇文章都值得读一读。说到底in文件不是魔法它就是一份把分子动力学模拟步骤写清楚的操作单。把它拆开看你会发现每一条命令都有它的位置和理由。1. 先要把in文件看透它才是整个模拟的引擎1.1 in文件里藏着一条完整的“模拟流水线”很多人第一次打开in文件时会被里面密密麻麻的命令吓到。其实你把它当成一条流水线来看就清楚多了。模拟一个体系最基本的动作是固定的先告诉LAMMPS“我们用什么单位制、什么原子模型、什么边界条件”然后建立模拟盒子、往里面放原子接着定义原子之间的相互作用力再给原子赋初始速度最后设置输出和运行步数。这一套流程下来就构成了一个最典型的in文件。我贴一个最简版本你对照着看# 初始化 units metal atom_style atomic boundary p p p # 建模 lattice fcc 4.05 region box block 0 10 0 10 0 10 create_box 1 box create_atoms 1 box mass 1 26.98 # 力场 pair_style lj/cut 4.5 pair_coeff 1 1 0.392 2.95 # 设置 neighbor 0.3 bin velocity all create 300 12345 # 输出 thermo 100 dump d1 all custom 1000 dump.atom id type x y z restart 5000 restart.lmp # 运行 timestep 0.001 fix 1 all nvt temp 300 300 0.1 run 10000这个文件大约20行但一个完整的分子动力学模拟该有的环节全都在里面了。注意看命令出现的顺序这个顺序几乎是固定的先定义环境再建体系然后定义相互作用接着初始化速度最后才是输出和运行。你不能把pair_style放到create_box前面也不能在还没定义原子类型的时候就去写pair_coeff因为LAMMPS是逐行解释执行的前面的命令没执行后面的命令就没有可操作的对象。这里我想多说一句很多新手喜欢从网上下载现成的in文件也不管里面命令顺序直接替换几个参数就提交。这种做法偶尔能跑通但只要体系一变报错就会来得莫名其妙。老老实实理解这条流水线的顺序后面排错会轻松很多。1.2 为什么必须用in文件而不是直接在命令行敲LAMMPS其实支持交互式执行你可以一条条在终端里输入命令它也会执行。那为什么几乎所有人都会选择写in文件我自己的体会是分子动力学模拟本质上是一个反复调试的过程同一个小体系可能要试不同的温度、不同的压强、不同的时间步长如果用交互式输入每次改一个参数都得重新敲一堆命令既容易出错也没法留档。in文件解决的是“可复现”的问题。你今天用这个in文件跑出了一组结果半年后想复盘打开in文件就能看明白当初是怎么设置的同事想复现你的数据你把in文件发过去他在自己的机器上跑一遍只要版本和力场一致结果就应该对得上。这比任何口头描述都可靠。所以从第一天开始就养成“一切操作都写进in文件”的习惯对做计算的人来说是受益终身的事情。还有一个很实际的好处in文件里可以写变量可以写循环。比如你要扫一组温度300K、350K、400K不需要写三个in文件用一个变量加一次循环就能搞定。这种时候in文件的脚本化优势就更明显了。2. 从零写一个最小可跑的in文件2.1 第一行别乱来units和atom_style决定全局我能理解看到“units metal”这种命令时一脸懵的感觉。units就是告诉LAMMPS后面文件里出现的所有数字分别用什么单位来解释。金属体系常用metal单位制它定义了长度单位是埃、能量单位是电子伏特、温度单位是开尔文。如果你换成units real那长度仍然是埃但能量单位变成了千卡每摩尔。这个区别很关键因为同样的数字在不同单位制下代表完全不同的物理量。我见过一个特别典型的错误从网上下载一个in文件它在最开头写了units real而你自己的文件里却是units metal你也没注意直接把pair_coeff参数复制过来。表面上看命令一模一样实际上能量差了好几个数量级跑出来的结果一看就离谱。所以拿到任何in文件或者data文件第一件事就是确认单位制是否一致这一点怎么强调都不过分。接下来是atom_style它决定了每个原子要记录哪些属性。atomic是最基本的每个原子只记录序号、坐标、速度如果模拟带电体系要用charge如果体系里有分子键要用molecular或full。我个人的建议是在开始写in文件之前就先把体系类型想清楚不要跑到中途发现需要电荷了再回头改那基本等于重建模型。单位制长度能量适用场景metal埃电子伏特金属、合金、LJ粒子real埃千卡每摩尔有机物、生物分子lj无量纲无量纲纯LJ约化单位2.2 建模部分create_atoms和read_data两条路怎么选建模是in文件里最容易让人犹豫的部分。第一种方式是用lattice加region加create_atoms直接在LAMMPS内部生成周期性晶格。比如你想模拟一块面心立方铝4.05埃的晶格常数就可以用lattice fcc 4.05然后region box block 0 10 0 10 0 10创建一个10×10×10个晶胞的盒子再用create_atoms 1 box把这批原子生成出来。这个过程适合比较规整的晶体、简单液体盒子这类体系优点是快、参数直观不需要外部工具。第二种方式是用read_data从外部文件读入原子坐标。复杂体系比如蛋白质周围环绕着水分子或者一个纳米压痕的模型几乎不可能靠几行命令在LAMMPS里生成这时候就需要借助其他工具准备data文件。你需要先用建模软件生成结构再转换成LAMMPS能识别的data格式。我常用的路径是借助Moltemplate、topotools或者VMD的topotools插件来转格式。这两种方式没有绝对的好坏只有合不合适。我的习惯是纯晶体、纯LJ流体这种简单体系直接用create_atoms参数好控制改起来也快但凡体系里出现两种以上的分子种类、有复杂的拓扑结构就直接走read_data省得在建模命令里写一堆容易出错的东西。注意read_data文件里也有units信息它必须和in文件开头的units一致。2.3 力场参数不是随便填的pair_style和pair_coeff必须匹配建模完成之后下一步是定义原子间的相互作用。pair_style负责定义“用什么形式的势函数”pair_coeff负责给这个势函数提供具体参数。很多新手报错就是因为这两个命令不匹配。你选了pair_style lj/cut后面却想给EAM嵌原子势的参数那LAMMPS当然不认识。我以最常见的LJ势为例pair_style lj/cut 4.5意思是采用Lennard-Jones势截断半径4.5埃pair_coeff 1 1 0.392 2.95意思是第1类原子与第1类原子之间的相互作用参数ε等于0.392σ等于2.95。顺序不能反也不能漏。如果你有多个原子类型每一对相互作用都要写清楚例如pair_coeff 1 2需要单独定义除非你用pair_coeff * *这样的通配符。对于金属体系EAM势是常用的选择但EAM不是直接写在in文件里的它需要外部的势函数文件比如Cu_u3.eam。用的时候是这样pair_style eam pair_coeff * * Cu_u3.eam Cu注意这里的Cu指的是势文件里对应的元素映射名不能写错。我踩过一次坑从某个网站下载的势函数文件映射名里带着版本号结果命令写了元素名LAMMPS直接报错找不到该元素。解法也简单打开势文件看一眼第一行里的元素列表照着写就行。2.4 输出三件套thermo、dump、restart怎么配合很多新手忽视输出设置觉得只要把run写了就行。实际上输出设置直接影响后续的数据分析。thermo是控制屏幕和log文件里周期性输出热力学信息的命令比如温度、压力、总能量。它输出的频率不要太高也不要太低跑10000步每隔100步输出一次对我来说比较舒服既能看到变化趋势又不会把log文件撑爆。dump是输出原子坐标信息的命令。我常用的是custom格式可以自己指定要输出哪些量比如id、type、x、y、z再加上个vx、vy、vz。有一点要提醒dump文件非常占空间频率设得越密文件膨胀越快。我做长时间模拟时常常把dump频率刻意调低比如每隔5000步才输出一次反正最后分析的时候需要的是足够多的快照而不是每一帧都保留。restart是用来保存重启文件的。很多任务是长任务比如几百万步的弛豫中途断电或者超时被kill掉很正常。没有restart文件就得从头跑有了它就能在中断点附近接着跑。我自己的习惯是restart 50000等于每5万步保存一次配合log文件里的推进速度最坏情况也只损失一小段进度。如果你想让中间结果可以导入其他可视化工具还可以用write_data把当前状态输出成data文件。3. 完整实操从in文件到算完收数据3.1 动手前先把文件清单和目录规划好我第一次跑LAMMPS时被一堆命名乱七八糟的文件搞晕过in文件、data文件、势函数文件、提交脚本、输出文件全堆在一个目录里。后来才发现规划好目录结构和文件名能省下太多精力。一个标准的运行目录大概是这样的example/ ├── in.aluminum ├── data.alu ├── Cu_u3.eam └── job.shin文件命名我习惯用in.体系名比如in.aluminumdata文件也类似。用点分格式比用一堆下划线清爽。还有一点如果你从Windows机器传文件到Linux服务器中文文件名解压出来经常乱码这个我后面在排查部分详说。任务目录最好也分层。一个体系可能要做好几组不同参数的模拟我不会把所有run都堆在一起而是分成run1、run2这样的子目录每个子目录里放对应的in文件和输出。这样算完之后整理数据、做对比不会出现“这个dump到底是哪个温度下的”这种尴尬问题。还有一个细节工作目录的路径不要太长。实测下来某些并行环境和文件系统对深层目录处理会犯迷糊路径太长还可能影响输出文件的创建。我一般控制在三四层以内能不用中文、空格就绝不用。3.2 命令行运行从单核到并行以及权限问题假设你已经装好了LAMMPS最简单的运行方式就是lmp -in in.aluminum这条命令会在当前目录读取in.aluminum并把输出打到屏幕上同时生成log.lammps文件。如果不确定lmp命令是否可用先执行which lmp看一下路径如果没输出说明你没把可执行文件放到PATH里要么补环境变量要么用完整路径直接调用。如果在终端输入lmp提示Permission denied大概率是文件没有执行权限。这种情况我遇到过尤其是别人打包好的二进制文件解压之后默认权限没带x。解法很简单chmod x /path/to/lmp多核并行是LAMMPS的常态用法用mpirun或者mpiexec来启动mpirun -np 8 lmp -in in.aluminum这里-np 8表示用8个进程并行计算。实际用多少个核要看你的体系大小体系原子数太少的时候开太多核反而慢。我一般按总原子数除以每个进程不低于一两万原子来估并行度原子太少并行收益有限。如果你用的是集群还会用到作业提交脚本比如SLURM集群上常见的job.sh#!/bin/bash #SBATCH -J lammps_run #SBATCH -N 1 #SBATCH -n 8 mpirun -np 8 lmp -in in.aluminum这里有个容易犯的错SLURM已经申请了8个核mpirun里也写8没问题但如果你写的是mpirun -np 16而实际分配到只有8核程序会报错。总之申请的资源数和mpirun里的进程数要对得上。3.3 运行中的监控别等跑完才发现白跑了LAMMPS跑起来之后终端会不断刷屏输出的是thermo定义的热力学量。很多人看一眼觉得“哦在出东西了”就干别的去了其实运行中值得盯一下。正确姿势是把log文件打开看温度、压力、能量这几个量的变化。tail -f log.lammps重点关注温度的波动范围。以NVT系综为例温度应该在目标值附近波动偶尔出现一个特别反常的数值比如300K变成3000K那说明体系很可能爆了再不去管它后面跑出来的轨迹全是垃圾数据。还有一个监控技巧用top或者htop看CPU占用。如果8个核的占用率都在100%附近说明并行在正常干活如果只有个别核在动其他核闲着可能是负载不均衡或者并行效率很差这时候该停下来查查参数了。另外要注意磁盘占用。dump文件写得很勤快的话几百MB甚至几个GB几分钟就没了。我跑过大体系时手滑把dump频率设太密结果一个下午把磁盘写满。所以大规模任务开始前df -h看一下剩余空间预留出足够的余量。4. 跑挂与调优那些让新手崩溃的瞬间4.1 新手最容易遇到的五个报错速查表我把这几年遇到频率最高的报错整理成一个速查表希望能帮你少走弯路报错提示可能原因解决思路ERROR: Unrecognized command命令拼写错误或版本不支持检查拼写确认是当前版本支持的语法ERROR: Illegal ... command命令参数格式或数量不对对照文档核对参数检查有没有少参数、多参数ERROR: All atoms are lost原子飞出盒子或体系爆炸降低时间步长检查边界条件查看邻居列表参数ERROR: Bond atoms missing分子拓扑定义不完整检查data文件中分子键、角、二面角定义是否完整WARNING: Temperature being reset温度控制参数初始化有问题检查velocity create和fix控温命令的顺序与参数这些报错不一定瞬间就能看明白但解决办法都是同一个套路先看log文件里报错出现前最后几行正常输出通常能定位到是哪一步出了问题。LAMMPS的报错还是比较友善的它会直接告诉你哪条命令出了问题。如果提示看不懂把报错信息原样复制到搜索引擎里十有八九能找到别人遇到过的讨论。4.2 原子丢失和能量发散先查这三个地方原子丢失Lost atoms大概是新手问得最多的一种报错。它的字面意思是原子跑出了模拟盒子LAMMPS为了保证计算稳定直接终止任务。遇到这个情况不要急着改一个参数就重跑先查三处。第一处是边界条件。如果你设的是boundary p p p那么原子在三个方向上都是周期性边界跑到盒子外面会从对面穿回来理论上不会出现lost atoms。如果你的边界写的是f f f原子跑出去就直接丢了除非你明确知道自己在做什么否则不建议用固定边界跑体相体系。第二处是时间步长。对于大多数金属和LJ体系timestep在0.001左右通常没有问题也就是约1飞秒。但有些体系特别是温度很高或者原子分布不均匀的体系0.001就容易出问题。遇到lost atoms先把时间步长降到0.0005试试很多时候这一步就解决了。时间是残酷的但宁可跑慢一点也不要跑出一堆废数据。第三处是邻居列表。邻居列表更新频率和皮肤距离会直接影响LAMMPS能否及时发现原子碰撞。如果邻居列表设置不合理会导致原子在没有更新邻居的情况下发生剧烈碰撞能量瞬间爆炸。可以适当调整neighbor命令的参数比如neighbor 0.5 bin或者更频繁地更新邻居列表。这个参数不是越大越好太大计算量飙升需要找到一个平衡点。4.3 模拟速度太慢几个立竿见影的提速方法等任务跑起来才发现太慢是所有LAMMPS使用者的共同痛点。提速的手段有不少从简单到复杂排列首先是检查邻居列表设置。neighbor 0.3 bin这个命令0.3就是skin距离也就是在粒子实际截断半径之外再多加0.3埃作为缓冲。这个值设太小邻居列表更新频率就会变得过于频繁设太大邻居列表包含太多远距离原子计算量变大。我一般从0.3起步配合实测调整。其次是pair_style的加速版本。LAMMPS为很多势函数提供了gpu、omp、opt这些加速版本比如lj/cut/omp、lj/cut/gpu。如果你的机器有支持OpenMP的CPU或者有GPU可以试试把这些版本用起来。使用omp版本时把每个MPI进程分配到几个OMP线程往往能明显加快计算。再次是并行效率问题。不是核开得越多越快体系规模小的时候核心之间的通信开销会吞掉计算收益。我用4万原子的体系做过测试8核到16核有提升但32核反而变慢。所以并行核数并不是越多越好。还有一个很实用的技巧尽量减少dump输出频率。dump文件写入涉及大量的I/O操作在计算密集的模拟中过密的dump会拖慢整体速度。从头到尾分析数据需要的轮廓不要贪心每一帧都保存。5. 我的几句真心话文章写到这里流程上的东西基本都讲完了。最后我想分享几点个人体会可能比命令本身更值得参考。第一尽量从小体系开始。我见过太多人一上来就跑几十万原子的体系然后被各种报错折磨得怀疑人生。先拿一个几百原子的盒子把整个流程跑通确认每个环节都没有问题再逐步放大到目标体系。这样排查错误时变量少定位快。第二in文件是给人看的不只是给机器看的。养成写注释的习惯哪怕是临时测试的文件也写上这段在干什么、参数来源是什么。计算模拟是一个长期积累的过程三个月后再看一个没有注释的in文件你真的会想不起来为什么当初要设这个值。第三遇到问题先查log再搜报错最后才考虑重跑。很多人报错后第一反应是改个参数重新提交这样往往治标不治本。LAMMPS的log文件里其实保存了大量现场信息把报错前最后几行认真看一遍多半能找出问题根源。最后说一句我自己的实操体会分子动力学模拟真正花时间的往往不是建模也不是运行而是反复调试和排错。但只要把in文件这块硬骨头啃下来你会发现LAMMPS其实挺讲道理的——每一条命令都是你告诉程序“这个体系应该怎么跑”程序再老老实实地执行。它不聪明但它从不糊弄你。
LAMMPS in文件完全解读：从零构建分子动力学模拟流程
做分子动力学模拟的人十有八九都要和LAMMPS打交道。不管你是做材料、化学、生物还是流体只要想在原子尺度上观察一个体系随时间的变化LAMMPS基本是绕不开的选择。但这个开源软件的入门曲线实在不算平缓尤其是第一次面对in文件时不少人会觉得自己看的是天书units、atom_style、pair_coeff、fix nvt这些命令到底在干什么为什么别人给的in文件能直接跑自己照着写就报错这篇文章我想把我自己从“照着网上教程抄in文件”到“能独立写一个完整模拟流程”这段经历整理出来说说in文件到底是怎么组织起来的从初始化、建模型、设力场到提交运行、调参排错整个流程里哪些环节最容易卡住又有哪些经验可以让你少走弯路。不管你是刚装好LAMMPS还没跑通第一个例子还是已经能跑简单体系但总觉得哪里不对劲这篇文章都值得读一读。说到底in文件不是魔法它就是一份把分子动力学模拟步骤写清楚的操作单。把它拆开看你会发现每一条命令都有它的位置和理由。1. 先要把in文件看透它才是整个模拟的引擎1.1 in文件里藏着一条完整的“模拟流水线”很多人第一次打开in文件时会被里面密密麻麻的命令吓到。其实你把它当成一条流水线来看就清楚多了。模拟一个体系最基本的动作是固定的先告诉LAMMPS“我们用什么单位制、什么原子模型、什么边界条件”然后建立模拟盒子、往里面放原子接着定义原子之间的相互作用力再给原子赋初始速度最后设置输出和运行步数。这一套流程下来就构成了一个最典型的in文件。我贴一个最简版本你对照着看# 初始化 units metal atom_style atomic boundary p p p # 建模 lattice fcc 4.05 region box block 0 10 0 10 0 10 create_box 1 box create_atoms 1 box mass 1 26.98 # 力场 pair_style lj/cut 4.5 pair_coeff 1 1 0.392 2.95 # 设置 neighbor 0.3 bin velocity all create 300 12345 # 输出 thermo 100 dump d1 all custom 1000 dump.atom id type x y z restart 5000 restart.lmp # 运行 timestep 0.001 fix 1 all nvt temp 300 300 0.1 run 10000这个文件大约20行但一个完整的分子动力学模拟该有的环节全都在里面了。注意看命令出现的顺序这个顺序几乎是固定的先定义环境再建体系然后定义相互作用接着初始化速度最后才是输出和运行。你不能把pair_style放到create_box前面也不能在还没定义原子类型的时候就去写pair_coeff因为LAMMPS是逐行解释执行的前面的命令没执行后面的命令就没有可操作的对象。这里我想多说一句很多新手喜欢从网上下载现成的in文件也不管里面命令顺序直接替换几个参数就提交。这种做法偶尔能跑通但只要体系一变报错就会来得莫名其妙。老老实实理解这条流水线的顺序后面排错会轻松很多。1.2 为什么必须用in文件而不是直接在命令行敲LAMMPS其实支持交互式执行你可以一条条在终端里输入命令它也会执行。那为什么几乎所有人都会选择写in文件我自己的体会是分子动力学模拟本质上是一个反复调试的过程同一个小体系可能要试不同的温度、不同的压强、不同的时间步长如果用交互式输入每次改一个参数都得重新敲一堆命令既容易出错也没法留档。in文件解决的是“可复现”的问题。你今天用这个in文件跑出了一组结果半年后想复盘打开in文件就能看明白当初是怎么设置的同事想复现你的数据你把in文件发过去他在自己的机器上跑一遍只要版本和力场一致结果就应该对得上。这比任何口头描述都可靠。所以从第一天开始就养成“一切操作都写进in文件”的习惯对做计算的人来说是受益终身的事情。还有一个很实际的好处in文件里可以写变量可以写循环。比如你要扫一组温度300K、350K、400K不需要写三个in文件用一个变量加一次循环就能搞定。这种时候in文件的脚本化优势就更明显了。2. 从零写一个最小可跑的in文件2.1 第一行别乱来units和atom_style决定全局我能理解看到“units metal”这种命令时一脸懵的感觉。units就是告诉LAMMPS后面文件里出现的所有数字分别用什么单位来解释。金属体系常用metal单位制它定义了长度单位是埃、能量单位是电子伏特、温度单位是开尔文。如果你换成units real那长度仍然是埃但能量单位变成了千卡每摩尔。这个区别很关键因为同样的数字在不同单位制下代表完全不同的物理量。我见过一个特别典型的错误从网上下载一个in文件它在最开头写了units real而你自己的文件里却是units metal你也没注意直接把pair_coeff参数复制过来。表面上看命令一模一样实际上能量差了好几个数量级跑出来的结果一看就离谱。所以拿到任何in文件或者data文件第一件事就是确认单位制是否一致这一点怎么强调都不过分。接下来是atom_style它决定了每个原子要记录哪些属性。atomic是最基本的每个原子只记录序号、坐标、速度如果模拟带电体系要用charge如果体系里有分子键要用molecular或full。我个人的建议是在开始写in文件之前就先把体系类型想清楚不要跑到中途发现需要电荷了再回头改那基本等于重建模型。单位制长度能量适用场景metal埃电子伏特金属、合金、LJ粒子real埃千卡每摩尔有机物、生物分子lj无量纲无量纲纯LJ约化单位2.2 建模部分create_atoms和read_data两条路怎么选建模是in文件里最容易让人犹豫的部分。第一种方式是用lattice加region加create_atoms直接在LAMMPS内部生成周期性晶格。比如你想模拟一块面心立方铝4.05埃的晶格常数就可以用lattice fcc 4.05然后region box block 0 10 0 10 0 10创建一个10×10×10个晶胞的盒子再用create_atoms 1 box把这批原子生成出来。这个过程适合比较规整的晶体、简单液体盒子这类体系优点是快、参数直观不需要外部工具。第二种方式是用read_data从外部文件读入原子坐标。复杂体系比如蛋白质周围环绕着水分子或者一个纳米压痕的模型几乎不可能靠几行命令在LAMMPS里生成这时候就需要借助其他工具准备data文件。你需要先用建模软件生成结构再转换成LAMMPS能识别的data格式。我常用的路径是借助Moltemplate、topotools或者VMD的topotools插件来转格式。这两种方式没有绝对的好坏只有合不合适。我的习惯是纯晶体、纯LJ流体这种简单体系直接用create_atoms参数好控制改起来也快但凡体系里出现两种以上的分子种类、有复杂的拓扑结构就直接走read_data省得在建模命令里写一堆容易出错的东西。注意read_data文件里也有units信息它必须和in文件开头的units一致。2.3 力场参数不是随便填的pair_style和pair_coeff必须匹配建模完成之后下一步是定义原子间的相互作用。pair_style负责定义“用什么形式的势函数”pair_coeff负责给这个势函数提供具体参数。很多新手报错就是因为这两个命令不匹配。你选了pair_style lj/cut后面却想给EAM嵌原子势的参数那LAMMPS当然不认识。我以最常见的LJ势为例pair_style lj/cut 4.5意思是采用Lennard-Jones势截断半径4.5埃pair_coeff 1 1 0.392 2.95意思是第1类原子与第1类原子之间的相互作用参数ε等于0.392σ等于2.95。顺序不能反也不能漏。如果你有多个原子类型每一对相互作用都要写清楚例如pair_coeff 1 2需要单独定义除非你用pair_coeff * *这样的通配符。对于金属体系EAM势是常用的选择但EAM不是直接写在in文件里的它需要外部的势函数文件比如Cu_u3.eam。用的时候是这样pair_style eam pair_coeff * * Cu_u3.eam Cu注意这里的Cu指的是势文件里对应的元素映射名不能写错。我踩过一次坑从某个网站下载的势函数文件映射名里带着版本号结果命令写了元素名LAMMPS直接报错找不到该元素。解法也简单打开势文件看一眼第一行里的元素列表照着写就行。2.4 输出三件套thermo、dump、restart怎么配合很多新手忽视输出设置觉得只要把run写了就行。实际上输出设置直接影响后续的数据分析。thermo是控制屏幕和log文件里周期性输出热力学信息的命令比如温度、压力、总能量。它输出的频率不要太高也不要太低跑10000步每隔100步输出一次对我来说比较舒服既能看到变化趋势又不会把log文件撑爆。dump是输出原子坐标信息的命令。我常用的是custom格式可以自己指定要输出哪些量比如id、type、x、y、z再加上个vx、vy、vz。有一点要提醒dump文件非常占空间频率设得越密文件膨胀越快。我做长时间模拟时常常把dump频率刻意调低比如每隔5000步才输出一次反正最后分析的时候需要的是足够多的快照而不是每一帧都保留。restart是用来保存重启文件的。很多任务是长任务比如几百万步的弛豫中途断电或者超时被kill掉很正常。没有restart文件就得从头跑有了它就能在中断点附近接着跑。我自己的习惯是restart 50000等于每5万步保存一次配合log文件里的推进速度最坏情况也只损失一小段进度。如果你想让中间结果可以导入其他可视化工具还可以用write_data把当前状态输出成data文件。3. 完整实操从in文件到算完收数据3.1 动手前先把文件清单和目录规划好我第一次跑LAMMPS时被一堆命名乱七八糟的文件搞晕过in文件、data文件、势函数文件、提交脚本、输出文件全堆在一个目录里。后来才发现规划好目录结构和文件名能省下太多精力。一个标准的运行目录大概是这样的example/ ├── in.aluminum ├── data.alu ├── Cu_u3.eam └── job.shin文件命名我习惯用in.体系名比如in.aluminumdata文件也类似。用点分格式比用一堆下划线清爽。还有一点如果你从Windows机器传文件到Linux服务器中文文件名解压出来经常乱码这个我后面在排查部分详说。任务目录最好也分层。一个体系可能要做好几组不同参数的模拟我不会把所有run都堆在一起而是分成run1、run2这样的子目录每个子目录里放对应的in文件和输出。这样算完之后整理数据、做对比不会出现“这个dump到底是哪个温度下的”这种尴尬问题。还有一个细节工作目录的路径不要太长。实测下来某些并行环境和文件系统对深层目录处理会犯迷糊路径太长还可能影响输出文件的创建。我一般控制在三四层以内能不用中文、空格就绝不用。3.2 命令行运行从单核到并行以及权限问题假设你已经装好了LAMMPS最简单的运行方式就是lmp -in in.aluminum这条命令会在当前目录读取in.aluminum并把输出打到屏幕上同时生成log.lammps文件。如果不确定lmp命令是否可用先执行which lmp看一下路径如果没输出说明你没把可执行文件放到PATH里要么补环境变量要么用完整路径直接调用。如果在终端输入lmp提示Permission denied大概率是文件没有执行权限。这种情况我遇到过尤其是别人打包好的二进制文件解压之后默认权限没带x。解法很简单chmod x /path/to/lmp多核并行是LAMMPS的常态用法用mpirun或者mpiexec来启动mpirun -np 8 lmp -in in.aluminum这里-np 8表示用8个进程并行计算。实际用多少个核要看你的体系大小体系原子数太少的时候开太多核反而慢。我一般按总原子数除以每个进程不低于一两万原子来估并行度原子太少并行收益有限。如果你用的是集群还会用到作业提交脚本比如SLURM集群上常见的job.sh#!/bin/bash #SBATCH -J lammps_run #SBATCH -N 1 #SBATCH -n 8 mpirun -np 8 lmp -in in.aluminum这里有个容易犯的错SLURM已经申请了8个核mpirun里也写8没问题但如果你写的是mpirun -np 16而实际分配到只有8核程序会报错。总之申请的资源数和mpirun里的进程数要对得上。3.3 运行中的监控别等跑完才发现白跑了LAMMPS跑起来之后终端会不断刷屏输出的是thermo定义的热力学量。很多人看一眼觉得“哦在出东西了”就干别的去了其实运行中值得盯一下。正确姿势是把log文件打开看温度、压力、能量这几个量的变化。tail -f log.lammps重点关注温度的波动范围。以NVT系综为例温度应该在目标值附近波动偶尔出现一个特别反常的数值比如300K变成3000K那说明体系很可能爆了再不去管它后面跑出来的轨迹全是垃圾数据。还有一个监控技巧用top或者htop看CPU占用。如果8个核的占用率都在100%附近说明并行在正常干活如果只有个别核在动其他核闲着可能是负载不均衡或者并行效率很差这时候该停下来查查参数了。另外要注意磁盘占用。dump文件写得很勤快的话几百MB甚至几个GB几分钟就没了。我跑过大体系时手滑把dump频率设太密结果一个下午把磁盘写满。所以大规模任务开始前df -h看一下剩余空间预留出足够的余量。4. 跑挂与调优那些让新手崩溃的瞬间4.1 新手最容易遇到的五个报错速查表我把这几年遇到频率最高的报错整理成一个速查表希望能帮你少走弯路报错提示可能原因解决思路ERROR: Unrecognized command命令拼写错误或版本不支持检查拼写确认是当前版本支持的语法ERROR: Illegal ... command命令参数格式或数量不对对照文档核对参数检查有没有少参数、多参数ERROR: All atoms are lost原子飞出盒子或体系爆炸降低时间步长检查边界条件查看邻居列表参数ERROR: Bond atoms missing分子拓扑定义不完整检查data文件中分子键、角、二面角定义是否完整WARNING: Temperature being reset温度控制参数初始化有问题检查velocity create和fix控温命令的顺序与参数这些报错不一定瞬间就能看明白但解决办法都是同一个套路先看log文件里报错出现前最后几行正常输出通常能定位到是哪一步出了问题。LAMMPS的报错还是比较友善的它会直接告诉你哪条命令出了问题。如果提示看不懂把报错信息原样复制到搜索引擎里十有八九能找到别人遇到过的讨论。4.2 原子丢失和能量发散先查这三个地方原子丢失Lost atoms大概是新手问得最多的一种报错。它的字面意思是原子跑出了模拟盒子LAMMPS为了保证计算稳定直接终止任务。遇到这个情况不要急着改一个参数就重跑先查三处。第一处是边界条件。如果你设的是boundary p p p那么原子在三个方向上都是周期性边界跑到盒子外面会从对面穿回来理论上不会出现lost atoms。如果你的边界写的是f f f原子跑出去就直接丢了除非你明确知道自己在做什么否则不建议用固定边界跑体相体系。第二处是时间步长。对于大多数金属和LJ体系timestep在0.001左右通常没有问题也就是约1飞秒。但有些体系特别是温度很高或者原子分布不均匀的体系0.001就容易出问题。遇到lost atoms先把时间步长降到0.0005试试很多时候这一步就解决了。时间是残酷的但宁可跑慢一点也不要跑出一堆废数据。第三处是邻居列表。邻居列表更新频率和皮肤距离会直接影响LAMMPS能否及时发现原子碰撞。如果邻居列表设置不合理会导致原子在没有更新邻居的情况下发生剧烈碰撞能量瞬间爆炸。可以适当调整neighbor命令的参数比如neighbor 0.5 bin或者更频繁地更新邻居列表。这个参数不是越大越好太大计算量飙升需要找到一个平衡点。4.3 模拟速度太慢几个立竿见影的提速方法等任务跑起来才发现太慢是所有LAMMPS使用者的共同痛点。提速的手段有不少从简单到复杂排列首先是检查邻居列表设置。neighbor 0.3 bin这个命令0.3就是skin距离也就是在粒子实际截断半径之外再多加0.3埃作为缓冲。这个值设太小邻居列表更新频率就会变得过于频繁设太大邻居列表包含太多远距离原子计算量变大。我一般从0.3起步配合实测调整。其次是pair_style的加速版本。LAMMPS为很多势函数提供了gpu、omp、opt这些加速版本比如lj/cut/omp、lj/cut/gpu。如果你的机器有支持OpenMP的CPU或者有GPU可以试试把这些版本用起来。使用omp版本时把每个MPI进程分配到几个OMP线程往往能明显加快计算。再次是并行效率问题。不是核开得越多越快体系规模小的时候核心之间的通信开销会吞掉计算收益。我用4万原子的体系做过测试8核到16核有提升但32核反而变慢。所以并行核数并不是越多越好。还有一个很实用的技巧尽量减少dump输出频率。dump文件写入涉及大量的I/O操作在计算密集的模拟中过密的dump会拖慢整体速度。从头到尾分析数据需要的轮廓不要贪心每一帧都保存。5. 我的几句真心话文章写到这里流程上的东西基本都讲完了。最后我想分享几点个人体会可能比命令本身更值得参考。第一尽量从小体系开始。我见过太多人一上来就跑几十万原子的体系然后被各种报错折磨得怀疑人生。先拿一个几百原子的盒子把整个流程跑通确认每个环节都没有问题再逐步放大到目标体系。这样排查错误时变量少定位快。第二in文件是给人看的不只是给机器看的。养成写注释的习惯哪怕是临时测试的文件也写上这段在干什么、参数来源是什么。计算模拟是一个长期积累的过程三个月后再看一个没有注释的in文件你真的会想不起来为什么当初要设这个值。第三遇到问题先查log再搜报错最后才考虑重跑。很多人报错后第一反应是改个参数重新提交这样往往治标不治本。LAMMPS的log文件里其实保存了大量现场信息把报错前最后几行认真看一遍多半能找出问题根源。最后说一句我自己的实操体会分子动力学模拟真正花时间的往往不是建模也不是运行而是反复调试和排错。但只要把in文件这块硬骨头啃下来你会发现LAMMPS其实挺讲道理的——每一条命令都是你告诉程序“这个体系应该怎么跑”程序再老老实实地执行。它不聪明但它从不糊弄你。
的替代方案)
