OpenMP — CAE用语解释
OpenMP的理论基础
OpenMP的基本概念
我听说OpenMP是用于并行计算的，但具体它是做什么的？它和MPI有什么区别？
很好的问题。OpenMP是一种共享内存型并行化API规范。在单台计算机（服务器或工作站）中，多个CPU核心共享同一内存空间，协调执行处理。而MPI采用分布式内存型，通过在不同计算机（节点）之间发送和接收消息来协调工作。也就是说，OpenMP针对"单台机器内的多个核心"，而MPI针对"多台机器"。
共享内存意味着所有线程都可以访问同一个变量，对吧？那么，多个线程同时改写同一位置不会导致计算出错吗？
完全正确，这就是主要挑战。我们称之为数据竞争（Data Race）。例如，如果所有线程同时对共享计数器变量`sum`执行`sum = sum + local_value`，更新会被覆盖，导致总和不正确。OpenMP使用`#pragma omp critical`指令或`#pragma omp atomic`指令来排他性地控制该部分的执行。或者，可以从一开始就设计算法，使其不会发生冲突。
您提到规范，那么谁来决定呢？不同版本之间有什么变化？
OpenMP体系结构审查委员会（ARB）制定和发布规范。截至2023年，最新版本是OpenMP 5.2。随着版本升级，功能也在扩展。例如，OpenMP 4.0正式引入了SIMD（向量化）指令，使得能够更高效地利用单个核心内的计算单元。OpenMP 5.0强化了任务依赖性的表达，使得复杂的非均匀工作负载的并行化变得更容易。CAE求解器通常依赖于所使用编译器支持的OpenMP版本。
OpenMP的数值计算方法
CAE求解器中的实现示例
在CAE计算中，OpenMP具体用在哪些部分？并不是整个计算都会一下子加速，对吧？
完全正确，有些部分可以并行化，有些则不能。并行化效果最大的部分是单元刚度矩阵的生成和内力向量的计算。例如，如果模型有10万个单元，每个单元的计算都是独立的。我们用OpenMP的`#pragma omp parallel for`来并行化这部分。迭代求解器的预处理和矩阵-向量乘积也是并行化的目标。但是，直接法求解器的前向消除和后向代入，以及收敛判定是逐序处理部分，成为瓶颈。我们可以用Amdahl定律来估计这一影响。如果代码的并行化率为95%，用16个线程执行，理论上最大加速比为
`parallel for`的使用需要注意什么？只是在for循环前面添加就可以了吗？
不行，盲目使用反而会导致速度变慢或结果错误。首先，循环的每次迭代必须独立。如果第i次迭代的结果依赖于第i-1次迭代，就无法并行化。其次，要检查是否存在我们之前提到的数据竞争。另外，如果循环迭代次数太少，线程创建和管理的开销会抵消收益。经验上，每个线程至少需要1000～10000次迭代。此外，调度的指定很关键，根据计算负载的均匀性选择`schedule(static)`（均匀分配）还是`schedule(dynamic)`（动态分配）。
编译时如何处理？需要特殊的选项吗？
需要。主要编译器需要添加以下选项：
- Intel Compiler (icc/icpc): `-qopenmp` (旧版本: `-openmp`)
- Microsoft Visual C++: `/openmp`
- LLVM Clang: `-fopenmp`
没有这些选项，pragma被视为注释而被忽略，代码将以串行方式编译和执行。链接时还需要OpenMP运行时库。
OpenMP的实务应用
性能调优的实际应用
实际运行CAE求解器时，OpenMP的线程数应该如何确定？把它设置为CPU的核心数能获得最大性能吗？
不一定。首先，要区分物理核心数和逻辑核心数（由超线程等产生）。对于计算密集的CAE，通常应该设置为物理核心数。例如，一个20核40线程的CPU，OpenMP线程数应设为20。更重要的是内存带宽和缓存。所有核心同时运行会导致内存带宽饱和，性能达到瓶颈。在这种情况下，适度减少核心数可能反而提高整体吞吐量。通过环境变量`OMP_NUM_THREADS`设置，但求解器内部可能会覆盖，所以要查看手册。
我改变线程数后计算时间，发现8个线程更快，但16个线程反而变慢了。为什么？
这是典型问题。原因有几个。第一是内存带宽饱和。如前所述，所有核心同时访问内存会耗尽带宽，核心处于等待状态。第二是False Sharing。不同线程频繁更新同一缓存行上的不同变量时，维护缓存一致性的开销变得巨大。第三是并行化粒度过细，线程管理开销占主导。需要用性能分析工具（如Intel VTune、GNU gprof等）来确定时间消耗的位置。
我还听说过OpenMP和MPI的组合使用（混合并行），在CAE中是常见的做法吗？
在大规模计算中非常常见。例如，512核心的集群配置为32个节点×每个节点16个核心。此时，用MPI启动32个进程，每个MPI进程内部使用OpenMP进行16个线程的并行化。这样可以减少MPI进程间通信的次数和数据量（节点内通过共享内存进行高速数据交换）。ANSYS Mechanical和LS-DYNA等许多求解器都支持这种混合并行，提交作业时同时指定`-np`（MPI进程数）和`-nt`（OpenMP线程数）。最优组合取决于硬件和问题规模，需要基准测试。
OpenMP软件比较
主要CAE求解器中的OpenMP支持
具体来说，ANSYS和Abaqus是如何使用OpenMP的？用户需要做什么配置吗？
求解器内部实现是黑盒，但用户可以配置一些参数。
Abaqus/Standard中，在环境文件（abaqus_v6.env）中设置`mp_routine=...`或`cpus=N`。Abaqus/Explicit默认使用线程并行。两者都在许多部分利用OpenMP。
开源的CAE求解器呢，比如CalculiX和Code_Aster？
开源求解器的特点是用户直接编译源代码，OpenMP的有无和性能直接取决于编译设置。
Code_Aster规模很大，线性求解器（MUMPS、PETSc等）的并行功能贡献很大，但单元计算等部分也利用OpenMP任务并行。通过运行配置文件（`.export`）中的`ncpus=N`可以同时控制MPI进程数和OpenMP线程数。
商用求解器和开源求解器在OpenMP的使用和性能上有大的区别吗？
主要区别在于调优深度和稳定性。ANSYS和Abaqus等商用求解器与Intel Compiler或PGI Compiler紧密配合，与硬件厂商（Intel、AMD）联合多年进行缓存优化和指令级调优。它们已在各种问题规模和架构上进行了广泛测试，线程数增加时的性能下降（缩放）相对可预测。
OpenMP故障排除
常见错误和调试
在使用OpenMP的自编代码中，每次运行时最终结果都略有不同。没有再现性。这是数据竞争导致的吗？
几乎可以肯定是数据竞争。由于并行执行的时序不同，不同线程读写共享变量的顺序会变化，导致结果不确定。调试的第一步是将线程数设置为1（`OMP_NUM_THREADS=1`）运行。如果结果始终相同且正确，说明问题在并行部分。下一步用Intel Inspector或Valgrind的Helgrind等专用工具检测数据竞争。或者，怀疑所有共享变量的访问，用`critical`部分保护它们，看问题是否解决。
在商用求解器（如ANSYS）中出现内存不足错误。增加线程数会增加所需内存吗？
很可能会。特别是使用直接法求解器（稀疏直接求解）时。每个线程可能有工作缓冲区和线程局部数据。另外，矩阵的并行因数分解中，Fill-in（非零元素填充）的模式与逐序处理不同，可能产生更多非零元素。这导致总体内存需求增加。ANSYS文档中指出，使用SMP（共享内存并行）时，应将内存估算增加（线程数）×0.2～0.5倍。对于迭代法求解器，这种影响较小，但取决于预处理器。
计算过程中出现"栈大小不足"的错误并崩溃。这也和OpenMP有关吗？
有很大关联。在OpenMP并行区域（`parallel`）内声明大的自动变量（本地数组）时，它们被分配到每个线程的私有栈。默认线程栈大小（Linux上通常为几MB）很快就会耗尽。解决办法是用环境变量增加栈大小。Linux上：`export OMP_STACKSIZE=256M`，Windows上通过链接器选项设置线程栈大小。或者，修改代码用`malloc`或`new`在堆上分配大数据，这样更安全。
明明做了并行化，但CPU使用率没有达到100%。看起来只有部分核心被使用。为什么？
可能的原因有几个。第一，代码的大部分是未并行化的逐序部分。OpenMP在并行区域和逐序区域间交替，用分析器检查这一点。第二，负载不平衡。使用`schedule(static)`时，某些线程的计算量可能很大，其他线程早早完成后等待。第三，同步（栅障）等待。`#pragma omp barrier`或`parallel for`结束时的隐式栅障，最慢的线程前面都在等。第四，I/O（文件读写）或锁（`critical`部分）的竞争导致线程排队。性能分析工具确定热点必不可少。
相关主题
价值
详细
错误