计算化学公社

 找回密码 Forget password
 注册 Register
Views: 1515|回复 Reply: 6
打印 Print 上一主题 Last thread 下一主题 Next thread

[Lammps] LAMMPS中密度不均一体系域分解问题,和性能调优的一点经验

[复制链接 Copy URL]

290

帖子

7

威望

3187

eV
积分
3617

Level 5 (御坂)

石墨

本帖最后由 Graphite 于 2023-11-22 13:21 编辑

1、起因
在用LAMMPS帮别人用多体势算一些无机材料体系时,因为性能调优很是折腾了一阵子。
这些体系包括纳米团簇、金属-液体界面、气相热解等。

共同的特点是性能开销都很大,64核一两万原子经常跑不到一天1 ns。多节点并行效果也不好。但是体系不可能裁太小,因此就要充分发挥效能。

2、域分解和重新划分
LAMMPS采用典型的基于MPI和域分解进行CPU运算的解决方案,通俗地说就是为每个核划定“包干区”。

想象32个工人来回搬20000块砖,要使他们各司其职,LAMMPS是这样实现的:
1、划定域分解区域,如果什么都不指定,默认是空间平均分成像4x2x4的空间,如果核起了14个,而又不能划2x7x1,那么每个核会起若干个线程,比如各起4个线程,划成2x7x4。
(当然,很不推荐核数是质数或质数x质数,如14核效果可能不如12核)
2、每个核处理自己手头的原子的力和速度计算,同时用接邻列表(neighbor关键词)作缓冲,相当于做着手里的,余光盯着旁边区域的。
3、如果有别的区域的原子进入域分解区域,移交到手上。如果手上的原子离开,移交给别的核。

因此,就产生了以下几个注意点:
1、域分解要合理,例如纳米团簇,原子可能全都集中在不到30%的空间中,此外都是真空。如果平均划分显然造成30%的核干活,70%核跑空,单纯等待。
2、neighbor范围要足够,否则就会报lost atom崩溃——有原子跑出原来的核的区域,又不在旁边核的缓冲区域内,结果没有核管了。

这当中涉及到的关键词:
comm_style:指定域分解的划分样式,brick(默认)或tiled。

balance:重新划分一次,例如balance 1.2 shift xy 10 1.1,也就是若不平衡度(Imbalance Factor,负载最大的核的负载/平均负载)大于1.2,执行shift方式重新分解,最多尝试10次,要求达到1.1以内的不平衡度。
rcb方式只需要1个参数不平衡度。但是2022版本的LAMMPS,rcb如果实在尝试不出来,会卡死,没有最大尝试次数一说。

参照LAMMPS手册的一张图:

左图为brick平均分,属于是极不平衡的状态,6个核在空跑。中图是brick样式+shift方式重新划分之后。右图为tiled样式+rcb方式重新划分之后。

fix balance:运行过程中每N步尝试balance,变量参数和balance差不多,还能设定计算划分的细节,例如weight neigh表示以接邻列表为权重划分,而不是原子数为权重。out变量能输出每次的重新划分方式到一个文本文件中,做出图出来类似上图。虽然图做出来也没啥用,但至少能确认是否有在好好重新划分。

neighbor:接邻列表相关,考虑重新划分时,接邻列表半径要设的稍大些,例如原来2.0的可以设4.0,防止核数多,划分方式又复杂,在两次重新划分之间的某步掉原子。当然设太大会在搜索接邻列表时消耗太多性能。
另,reaxff力场若要输出键合情况(reax/c/bonds),会覆盖neighbor设定,所以这时neighbor写在所有力场相关设置之后。

体系大小、核数、划分空间在这类问题中互相影响,如果密度极高,可能一个核也就带300原子,那么不合理的设置可能会导致因为通信崩或者效率极低,相比化学结构不合理崩就太不甘心了。

3、例子和广告
气相热解问题见http://bbs.keinsci.com/thread-38799-1-1.html
这个体系越跑到后期团簇生成的就越紧密,而别处都是低密度气相,如果不设置fix balance,开局2 ns/day可能觉得还不错,后期相互作用项更多+不平衡,只剩不到0.5 ns/day乃至根本算不动了。
合理设置之后,好歹到最后还剩0.8 - 1 ns/day。
某个除了团簇全是真空的模拟,不设置fix balance只有五分之一的性能,就是真正的”一核有难八核围观“了。
对于均相、两相间密度/作用复杂度差别不大的,设置一下也能提升10%左右性能。
这些问题实际上都是代算,实际呈现的交付报告肯定是基于具体体系的研究,而且远比帖子里要规范、丰富十倍。
代算归代算,良心还是要有。钱很重要,但更重要是图一开心和念头通达,否则迟早要和黑心的同流合污。我钻研(折腾)得开心,收得堂堂正正,客户收到规范合理的结果,也省心舒适。
会把前因后果、为什么这么建这么算、详细的结果和表述写进报告,也会附上恰当的引用。客户(的课题组)哪天要是自己学了,把报告翻出来看看肯定能学到点,并且能复现。给内行把关评理,也完全欢迎,问心无愧。



评分 Rate

参与人数
Participants 4
威望 +1 eV +11 收起 理由
Reason
naoki + 5 谢谢分享
hdhxx123 + 3 好物!
chever + 3 赞!
sobereva + 1

查看全部评分 View all ratings

镜像空间计算模拟

28

帖子

0

威望

1046

eV
积分
1074

Level 4 (黑子)

2#
发表于 Post on 2024-1-24 22:32:20 | 只看该作者 Only view this author
从图中来看是不是表明tiled样式+rcb方式的划分最好?是否推荐用这个样式,还是推荐中间的brick样式+shift方式?

290

帖子

7

威望

3187

eV
积分
3617

Level 5 (御坂)

石墨

3#
 楼主 Author| 发表于 Post on 2024-1-25 15:09:47 | 只看该作者 Only view this author
ggshining 发表于 2024-1-24 22:32
从图中来看是不是表明tiled样式+rcb方式的划分最好?是否推荐用这个样式,还是推荐中间的brick样式+shift方 ...

大部分情况值得一试tiled+rcb,但不绝对:一方面是有些功能/fix只适配第一种最简单划分;另一方面是复杂划分舍弃了空间上的平均均,在如含能材料向真空爆炸、快速的冲击、蒸发等情况下,容易粒子越界崩。(不过这些情况也不用跑太久就是了)
镜像空间计算模拟

46

帖子

0

威望

928

eV
积分
974

Level 4 (黑子)

4#
发表于 Post on 2024-2-27 15:36:00 | 只看该作者 Only view this author
Graphite 发表于 2024-1-25 15:09
大部分情况值得一试tiled+rcb,但不绝对:一方面是有些功能/fix只适配第一种最简单划分;另一方面是复杂 ...

多节点的话OMP包加速的效果怎么样,我自己测感觉要比纯MPI并行的效果好一些

290

帖子

7

威望

3187

eV
积分
3617

Level 5 (御坂)

石墨

5#
 楼主 Author| 发表于 Post on 2024-2-27 18:55:05 | 只看该作者 Only view this author
本帖最后由 Graphite 于 2024-2-27 18:56 编辑
lmch 发表于 2024-2-27 15:36
多节点的话OMP包加速的效果怎么样,我自己测感觉要比纯MPI并行的效果好一些

节点间mpi通信+节点内部分omp还可以,具体看整个计算系统的架构,要最大化性能得专门调优,找到甜区,比如4 node× 8 MPI×4 OMP之类。
镜像空间计算模拟

46

帖子

0

威望

928

eV
积分
974

Level 4 (黑子)

6#
发表于 Post on 2024-2-28 21:52:31 | 只看该作者 Only view this author
Graphite 发表于 2024-2-27 18:55
节点间mpi通信+节点内部分omp还可以,具体看整个计算系统的架构,要最大化性能得专门调优,找到甜区,比 ...

感谢,测试上4~8 OMP效果上要相对好一些,有些集群很怪,纯MPI居然跑不起来

31

帖子

0

威望

373

eV
积分
404

Level 3 能力者

7#
发表于 Post on 2024-5-1 21:13:19 | 只看该作者 Only view this author
我最近用GPU加速lammps计算,kokkos加速,然后发现计算发现,单卡的适合计算没问题,但是多卡并行计算的时候,发现只一个卡在计算,其他卡基本上出工不出力,功耗很低,,调用不起来,不知道你遇到过没有

本版积分规则 Credits rule

手机版 Mobile version|北京科音自然科学研究中心 Beijing Kein Research Center for Natural Sciences|京公网安备 11010502035419号|计算化学公社 — 北京科音旗下高水平计算化学交流论坛 ( 京ICP备14038949号-1 )|网站地图

GMT+8, 2024-11-24 02:45 , Processed in 0.172395 second(s), 25 queries , Gzip On.

快速回复 返回顶部 返回列表 Return to list