lsdyna mpp平台搭建经验

admin管理员组

文章数量:1531294

2024年6月23日发(作者：)

随计算机硬件和网络设备技术的进步和价格的降低，以及工业上对更精细的FE模型的

需求，MPP版LSDyna所点市场份额逐渐增加。LSTC公司的 Benson在关于DYNA

history的presentation中甚至预测今后几年MPP会逐渐取代PC,SMP版Dyna。

目前LSTC公司硬件合作厂商(IBM,HP,SGI,SUN,etc)都推出了商业化的LS-DYNA计算

Cluster，这些硬件厂商通常会投 入相当一部分人力和财力在平台方面做开发和优化，借

着与LSTC良好的合作关系，其平台上的MPP LS-DYNA加速比都能达到很理想的值。

网站给出了MPP DYNA 相关的两个Benchmark文件(一个单车前撞，一

个三车碰撞)，并且专门收集用户在各种硬件平台上对这两个文件MPP LS-DYNA并行计

算的速度信息。其中不乏各硬件厂商提供且来测试的硬件平台信息，包括CPU速度，数目，

网络连接类型等。从这些信息多们大致可以比较 不同的DYNA版本，不同的CPU，不同

的网络连接类型对MPP计算速度的影响。

然而今天我要讨论的是自己搭建平台时需要注意的一些问题(前面的信息对我们会很

有指导意义)。商用平台固然好，但并不是都能轻易得到。有时候不得不自己组建，这时候

就得在选择配件时作好规划，免得最后达不到自己期望的并行效率(加速比)。

影响MPP并行效率的几个关键因素：

－－网络连接

－－选择的MPI和执行块

－－模型的规模和domain decomposition

一个Dyna计算所花费的时间主要分成两块，CPU计算时间及网络通信方面花费的时

间。对同 一个分好块的domain，CPU选定之后CPU计算时间基本上就确定了，但在网

络通信方面所花费的时间则根据网络设备和连接类型有大的关系。从比较典型 的汽车碰撞

过程中对mpi消息的tracer发现平均每个处理器每个周期发送28条消息，其中90%的消

息长度小于8K字节，67%小于1K字节[Ref 1]。一条消息的通讯时间依赖于两个因素，内

部连接的带宽和响应时间(bandwidth & latency)。另外消息传递过程中存在着竞争，当两

个或多个处理器试图通过同一网络通路传送数据时就会产生竞争。在基于IP的工作站网络

中，当两个机 器试图同时通过同一路径进行通讯，其中一条消息将延迟直到另一条传送完

毕，而这个延迟通常比实际直接传送两条消息所要的时间更多。

网络设备的bandwith & latency至关重要，带宽大，则传输同样数据所需时间少，

latency小，则等待时间会降低，同样有助减少通讯时间。在同样的CPU配置下，如果选

择bandwidth小，latency大的网络连接，则花在通讯上的时间所点的总时间比率增加，

大部分时间内可能CPU要等待从别的CPU传过来的信息 才能继续计算，这样导致单机的

CPU利用率不高，总的加速比没办法提高。就好比一部跑车开进了交通拥挤的低速道。因

此在选择网络设备时尽量选择 bandwidth大，latency小的硬件。这也是为什么目前大型

商用系统大多用myrinet,infiband替代GigE的原因。 除此之外，设备的参数设置与驱动

的tuning也会对加速比有所影响。目前操作系统和网卡驱动通常是根据平常的网络浏览和

交互进行参数设置的，对这样的应 用其效率比较高，但对LS-DYNA MPP这样的应用其

参数就不是最优的。前面已经提到在典型的LS-DYNA MPP计算过程中大量的消息为长度

小于8K字节的短消息，因此要对设备进行调谐以使得在短消息方面得到最佳性能。比如

在我组建过的做LS-DYNA MPP并行计算的linux cluster上，适当的进行网卡参数的设置

缩短了总的计算时间在7%左右。

MPI的选择在linux平台可以有很多种，HPMPI/Intel-MPI/MPICH/LAMMPI，前两

者通常是接合特定的硬件平台和执行块 进行优化，而后两都对自己组建的Cluster更容易

获得。从以前我自己组建的40CPUs 的Linux Cluster实际测试结果来看，在GigE作为

网络连接情况下同样参数设置和同样版本MPP Dyna执行块，LAMMPI的计算效率要稍

高于MPICH。DYNA MPP版本在不断的更新过程中，其不同版本的效率也不一样，从

topcrunch上也可以看出5434a版比3858执行效率就要高。

计算模型的规模和domain decomposition也是两个影响比较大的方面。规模小的模

型如果分的domain多，则很可能体现不出并行计算的优势。因为这样分在每个CPU上 的

CPU计算时间与网络通讯时间之间的比率会下降，CPU大部分时间可能在等待，加速比在

CPU超过一定数目时甚至会下降。domain decomposition方法直接影响分配到各个CPU

上的模型之间的公共节点的数目，如果两个domain之间共用的节点数多，则这两个

domain 分配到的CPU就计算过程中需要通讯的消息就多。在做Domain

decomposition时需要一些技桥巧和经验，尽量将各个domain之间的交界面减少。关于

Domain decomposition方面的详细参数设置可以参考lsdyna keyword user’s

manual中关于MPP的部分。

上面只是自己搭建LS-Dyna MPP并行平台方面积累的一点点经验，不能面面具道，

也可能会有些理解不对的地方，欢迎交流！

Reference:

1 . Message Passing and Advanced Computer Architectures.

Brian Wainscott and Jason Wang, LSTC.

2. A Correlation Study between MPP LS-DYNA Performance and Various

Interconnection Networks — a Quantitative Approach for Determining the

Communication and Computation Costs. Yih-Yih Lin, Hewlett-Packard Company

本文标签： 时间计算平台方面消息