本文将分享在多种硬件平台上实现高效、稳定的 LS-DYNA MPP 仿真的一系列实践经验。内容涵盖如何为系统选择最合适的 LS-DYNA 可执行文件，如何识别并解决并行计算中的效率瓶颈，包括通过用户自定义的区域划分优化计算性能。参会者将了解到如何通过调整系统设置、合理分配计算资源、采用 Hybrid MPI/OpenMP 执行模式以及进行处理器绑定，在现有硬件上最大化仿真性能。此外，还将介绍基于最新 x86 与 Arm 架构芯片的 LS-DYNA 基准测试结果。最后还将重点介绍如 OneMPI 等 LS-DYNA 最新的 MPP 特性。- 域分解技术（Domain Decomposition）
分区文件 pfile -负载均衡调整的前置步骤
MPP接触
特殊分块策略
重新分块（Redecomposition）
用户定义单元与材料的再分块
- LS-DYNA Undersubscription
本章节将介绍如何最大化 LS-DYNA MPP 的性能，涵盖 LS-DYNA 的 MPP 性能优化、MPP 的一致性以及 MPP 的最新功能。接下来直接进入 LS-DYNA 性能的主题：本节将讨论四种策略，帮助您充分发挥 LS-DYNA 的性能。
选择合适的LS-DYNA求解器程序；
LS-DYNA模型调优；
如何最大化现有硬件的性能表现；
采用最新的硬件；
LS-DYNA 有三种处理类型：SMP（Symmetric Multi-Processing） 、MPP （Massively Parallel Processing）和 Hybrid，其中 Hybrid 结合了 SMP 和 MPP方法。本次演讲只讨论 MPP 和 Hybrid，需要说明的是， SMP 在 R16 版本中仍可使用，但之后版本将不再支持，原因有多方面，主要是维护多套代码困难，同时 MPP 和 Hybrid 的扩展性远优于 SMP，且在低核数时计算式，性能表现相近。
选择LS-DYNA 求解器程序时，有许多版本可供选择。下面介绍细分选择时的几个类别。
首先看处理类型，这里主要是 MPP 和 Hybrid。需要注意的是，为了保证计算与通信的良好比例，LS-DYNA MPP 适用于单个处理器处理超过 10,000 个单元（建议的最低单元数）的情况。Hybrid 也是同样的要求：每个 MPP 进程至少要有 10,000 个单元，但 Hybrid 还可以利用 SMP 线程的优势。为了获得最佳性能，Hybrid 通常建议每个 MPP 进程使用不超过8个 SMP 线程。
接下来看精度设置。运行LS-DYNA显式求解器，通常推荐使用单精度版本，其运算速度比双精度快。如果遇到数值波动，使用双精度不一定能解决，因此建议保持单精度运行。
运行LS-DYNA显式求解器时，以下信息供参考（后续将介绍详细原因）：
关于 LS-DYNA 的指令集，avx2 比 sse2 性能提升约 10%；而 avx512 相较于 avx2 的提升并不固定：有时更快，有时反而更慢，这取决于所涉及的模型、硬件以及 MPI 环境等因素。
建议使用 Intel 或 Open MPI，避免使用平台自带的 MPI；后者仍停留在 MPI-2 且已停止更新；而 Intel 与 Open MPI 持续维护，能及时获得缺陷修复和性能改进。
双精度LS-DYNA 隐式计算性能优化。上图中，“ifort/MKL” 行表示 ifort 编译的 LS-DYNA，“AOCC/AOCL” 行表示 AOCC 编译的 LS-DYNA；列标题则区分 Intel 或 AMD 硬件平台。
若可执行文件由 ifort 编译且运行于 Intel 平台，无需额外设置环境变量；同一 ifort 编译的可执行文件若部署在 AMD 平台，建议追加 MKL 环境变量 MKL_DEBUG_CPU_TYPE=5 以获得最佳性能。该变量是针对 MKL 的设置，MKL 是双精度 LS-DYNA 版本使用的数学库。该设置可以避免在 AMD 硬件上的 CPU 检测，从而最终提升 AOCC 编译的 LS-DYNA 性能。
同样地，若在 AMD 平台运行 AOCC 编译的 LS-DYNA 可执行文件，由于使用的是 AOCC 数学库，R16之前的求解器版本，需要设置一个额外的环境变量 BLIS_ARCH_TYPE=zen4 以获得最佳性能。自 AOCC 编译的 LS-DYNA R16.0 及以上版本开始，经过修正，已无需再设置上述变量。
基于 Intel Xeon Gold 1642（48核）处理器的240万单元的汽车模型性能基准测试。该测试对比了 ifort 与 AOCC 编译版本，以及 AVX2 与 AVX512 指令集。结果显示，ifort 编译的 AVX2 版本在该平台上表现最优，如图所示。因此，若硬件使用 Intel 架构，建议直接选用这一版本。
基于 AMD EPYC 9654（Zen4/192核）处理器的240万单元的汽车模型性能基准测试，我们同样运行了相同的求解器程序。结果显示，AOCC 编译的 AVX2 可执行文件在该平台上表现最优，其求解时间较 ifort 编译版缩短约 5%。尽管 AVX512 版本在相同硬件上表现出轻微性能提升，但仍未超越 AVX2 版本的整体效率。因此，建议在 AMD Zen4 架构平台上优先考虑使用 AOCC 编译的 AVX2 版本，以获取更高的计算性能。
这里给出 AMD Azure 最新 HBv5 高性能结算（HPC）实例的实测数据。该 HPC 实例每节点集成四颗 AMD Zen4 芯片，共 384 核。再次对比 ifort 与 AOCC 编译的二进制可见，AOCC 性能全程保持领先；对比 Hybrid 与 MPP 两种求解器，Hybrid模式下AOCC 的加速幅度尤为显著，大幅超越 ifort 版本。这组结果仅通过替换 LS-DYNA 二进制文件获得，模型与硬件参数均未改动，性能差异却立竿见影。
在此之前，简单介绍 MPP 的域分解技术。
// 域分解技术（Domain Decomposition）
域分解是指将整体模型剖分为若干子域，并交由各 MPP 处理器独立计算。左下图示例中，模型被剖分后分配至 8 个处理器，每个处理器独立求解相应子域，实现并行计算。
LS-DYNA 默认采用递归坐标二分法（Recursive Coordinate Bisection, RCB）执行该剖分任务，子域的几何形状不仅取决于模型尺寸，也综合权衡各子域内单元的相对计算成本，而非单纯依据单元数量。
在 MPP 中，每个等级或处理器将在模型的各自子域中工作，这里可以看到子域的一个示例。每个计算阶段后，我们有 4 个子域，这里用红色表示，每个计算阶段结束后，处理器之间会进行并行同步，所有处理器必须完成当前阶段后才能进入下一阶段。
以处理器1（图中黄色子域）为例，如果该进程处理其子域内的单元耗时较长，而其他处理器2/3/4已经完成了各自子域内单元的处理，那么它们将处于空闲状态，并等待处理器1完成工作。这段空闲时间对应计算资源的直接浪费，并表现为整体并行效率下降。理想情况下，所有处理器应同时完成当前阶段，负载达到均衡，空闲时间最小，并行效率最高。
// 如何检测负载不平衡
我们知道，负载不平衡会直接导致 LS-DYNA 计算效率下降。
负载不平衡可能由多种原因引起：默认分解不理想、模型中存在相对运动、有严重变形的单元、用户自定义单元和材料、大量接触定义，以及相邻单元分布在不同处理器上等等，都会导致负载不平衡。
为了检测负载不平衡，有几种策略：
检查D3HSP 文件中 d3plot 文件输出的时间间隔，若该间隔单调递增或呈指数放大，即提示各进程步长已出现显著差异；
读取 GLSTAT 文件中的 NZC项，即单次区域循环耗时，其持续上升同样预示负载分布逐渐失衡；
还可以查看 D3HSP 末尾和消息文件内各处理器分计时，如果某个处理器在某计算类别上耗时明显高于均值，则可能存在局部过载；
关注负载曲线：LS-DYNA 输出的 loadprofile.xy 与 contactprofile.xy 分别记录整体负载与接触负载的均衡情况，可据此定位瓶颈并确定需调整的模型区域。
上图为某个负载曲线的示例。数据文件同时提供 .xy 格式（可直接载入 LS-PrePost）与 .csv 格式（可在 Excel 中打开）。本例共包含124 个处理器，横坐标为处理器编号，纵坐标为各处理器在对应计算类别中花费的时间占比。例如，红色曲线即示意每个处理器用于固体单元计算的时间分额。
接触分析图表的格式与此相同，仅将纵轴项目换成各接触对、而非计算类别。
理想状态下，任一类别、任一处理器所占用的计算时间占比应彼此接近。左侧示例即达到该目标--所有处理器在壳单元计算上消耗的时间几乎一致。右侧则呈现反例--各处理器对应的壳单元计算时间长短不一，这种负载不均直接拉低 LS-DYNA 的整体并行效率。
// 分区文件 pfile -负载均衡调整的前置步骤
分区文件 pfile 包含 MPP 特定的参数，这些参数会影响程序的执行。上图展示了 pfile 的案例，只需在命令行末尾添加 p=pfile 即可启用。pfile 包含四个部分：目录directory、分解decomposition、接触contact和通用general部分，它允许用户以“特殊分解”方式剖分文件，从而消除负载不均。
默认剖分以模型初始几何为依据，可通过在 pfile 中重写坐标改变剖分方式。上图展示了通过修改 pfile 坐标的案例，先以decomposition段声明剖分类别（红色字体所示），括号内再依次列出若干区域块region。括号内依次为区域限定符<region specifiers>、坐标变换式<transformation>，以及分组<grouping>（即参与剖分的处理器数量）。脚本末尾行追加一个<transformation>，作用于未被前述区域覆盖的剩余单元，执行顺序为先 Region 1，再 Region 2，最后剖分剩余部分，从而完成整个模型的分层剖分。
此外，pfile 可配置项不仅限于上述所列；完整列表与语义见《LS-DYNA用户手册附录 O》，该附录同时给出 MPP 专用参数的系统说明。若不愿在命令行中引用 pfile 参数 ，也可使用关键字 *CONTROL_MPP_PFILE，将所需添加信息输入原始 pfile，实现更简单的维护。
// MPP接触
下面说明如何缓解 MPP 接触中的负载不均。简单介绍，MPP接触计算按列表串行执行，即在任何时刻，仅与当前接触相关的子域进程参与运算，其余处理器为空闲状态。图示模型包含两个接触（黄色框内圈出），当轮到接触 1 时，只有黄色子域对应的处理器投入计算；接触 1 结束后，接触 2 的关联处理器再开始工作，而其余处理器依旧处于空闲状态，以此类推。为缩短这类全局等待时间，我们希望以一种方式剖分模型，使得处理器能协同处理同一接触；另一个思路是，尽量减少接触总数。
尽可能将大量小的接触合并大的接触，这是由于覆盖整车的 1 到 2 个接触定义具有极佳的可扩展性，减少接触总数可以提高并行性能及可扩展性。
若需在多处读取接触力，不必布置大量小的接触，而应将它们合并为单一的大接触，然后测量该大接触的接触力，使用接触力传感器，这是一种提升模型可扩展性的有效策略。实测表明，少量“传感器-接触”组合的可扩展曲线斜率明显高于“数百小接触”方案，并行效率随核数增加而近乎线性提升。
若用户仍希望保留多个小的接触定义而不愿采用力传感器，可改用可分组接触（ Groupable Contact ）作为折衷方案。该机制在运行期把若干接触定义内部归并，使原本需串行执行的接触检测与力计算转为并发操作。上图中 MPP接触默认按列表顺序依次处理，前一接触未完成则后续全部等待；启用可分组接触后，同一组内的接触被同时分发至可用进程，显著缩短整体计算耗时，从而提升并行效率。
如何启用可分组接触？可通过定义*CONTROL_MPP_CONTACT_GROUPABLE参数，也可在 P 文件中定义 contact {groupable GRP}，指定是否包含绑定接触、非绑定接触或基于面段的接触参与分组。上图图表展示了未使用和使用可分组接触的性能对比。
若需仅将特定接触纳入可分组，可在*CONTACT关键字末尾添加 _MPP，系统随即插入两张新卡片，其中grpable设为 1 时即可把该接触单独加入分组，实现精细控制。
案例分析-如何验证是否存在负载不均衡，查看前述负载曲线，当负载曲线揭示处理器 10–29 在处理接触阶段出现异常高耗时，浅蓝色曲线为接触的镜像曲线，其余处理器则处在空闲阶段（图中粉色、红色、绿色等曲线所示），等待处理器10~29完成计算。锁定负载失衡问题后，进一步查看接触剖析发现：同一 10~29 号处理器中，接触 7100000占用了大量时间。
那么该如何解决这个问题？调用关键词 *CONTACT_MPP_DECOMPOSITION_CONTACT_DISTRIBUTE，将接触界面均匀分发至全部处理器。对比图中视图表明：原模型（红色曲线）负载差异显著，启用该选项后的模型（绿色曲线）在各核心间趋于一致，接触计算由全体处理器共同承担，本例运行时间因此缩减逾 30%，并行效率明显提升。
以下概述MPP 接触的指导原则，作为前述讨论的归纳：首先，应降低接触总量，少数大接触优于大量小接触；实现途径包括以力传感器，或使用可分组接触合并并行处理。其次，对于仍保留的大型接触，应通过 *CONTACT_MPP_DECOMPOSITION_CONTACT_DISTRIBUTE 关键字或 *CONTACT_MPP_DECOMPOSITION_ARRANGE_PARTS 关键字（后文介绍）将接触界面分摊至全部处理器核心，以分散计算负荷。最后，若需诊断并行效率缺陷，可依托负载曲线与接触性能剖析工具进行定量审查。
更多内容欢迎持续关注摩尔芯创！
相关阅读
深度解读 | LS-DYNA中损伤与失效模型
How to | LS-DYNA使用技巧（十）-材料篇
How to | LS-DYNA使用技巧（九）-材料篇
How to | LS-DYNA使用技巧（八）
How to | LS-DYNA使用技巧（七）
How to | LS-DYNA使用技巧（六）
How to | LS-DYNA使用技巧（五）
How to | LS-DYNA使用技巧（四）
How to | LS-DYNA使用技巧（三）
How to | LS-DYNA使用技巧（二）
How to | LS-DYNA使用技巧（一）