开通VIP，畅享免费电子书等14项超值服
首页
好书
留言交流
下载APP
联系客服
2022.09.18上海
全文约18000字，主要针对工业软件研发
本文所说的工业软件主要指工业设计仿真软件。
工业设计仿真软件范畴：包括通常意义上的通用CAD，CAE，EDA，CFD，TCAD，BIM，CAM以及各个行业的CAD设计软件等。
1.行业研发内容
2.行业技术框架：
如何定义超大模型？
超大模型主要从两个方面定义，一个是几何单元的数量，一个是网格的数量，分别对应几何复杂度和仿真复杂度。
继续细分的话，考量几何单元数量的同时还需统计每个单元具体的面，边，点等数据以及曲面，曲线的数量。相同的面，参数平面和曲面的数据量可以相差数量级。
分析单元网格数量也要考虑求解模型类型，比如边界元，矩量法满秩矩阵数量会比稀疏矩阵多出几个数量级。相同网格数量，高阶网格自由度会随着会成倍增加。使用显式方法无需求解方程组，非常适用分布式计算且没有误差。
有些复杂的三维几何在结构计算中通过分析，可能将整体简化成计算的二维或者一维单元，在局部使用三维单元，分步分析，简化模型减少计算量。
假设现有一个几何单元数目在10万，六面体网格自由度在1亿左右的模型。
在操作这种模型的时候，不管是GUI操作，视图显示，模型编辑，都非常容易卡顿，或者程序容易死机。工程师对操作这种规模的模型应该是有概念的。
从以下几个方面考察：
1.UI层面：将10万个单元挂在UI树形节点上，如果只是单纯的添加，性能应该没问题，如果涉及到快速反复插入，删除，更新，遍历等操作时，UI会出现明显卡顿。
2.渲染层面：10万个几何需要单独处理的话，需要10万个实体几何对象，离散成面片，根据实际情况，面片数普遍在千万级别，如果不使用任何加速方法，显示会非常卡顿。刚推出的UE5使用NANITE已经能支持十亿面片的渲染。
对于工业仿真软件的渲染显示，考虑性价比，其加速在已有框架的基础上，更多的是在偏业务层实现。
3.模型编辑
模型编辑设计到模型的创建，删除，修改，赋属性等操作。
以最常用的创建模型的捕捉操作为例。捕捉操作是为了在模型创建时保证精准性。
比如为了做接触分析，需要创建两个相互接触的对象，第一个对象创建好后，创建第二个对象时需要捕捉到第一个对象的几何。在捕捉第一个对象时，需要遍历第一个对象的几何数据。如果有10万个对象，那就需要遍历10万个对象，因为捕捉操作是实时计算，所以必需要做过滤优化处理。类似操作还有拾取，框选，高亮等操作。
超大模型的几何编辑一定要通过优化过滤等操作控制在局部范围。
4.模型检查遍历
公差中常见的几何干涉分析，需要遍历计算整个模型中的几何数据。针对10万个三维对象每两个做干涉计算，程序直接拉胯。同理还有分析整体模型中的自由实体，最短边，最短距离，最短形心距，最短质心距。这些计算操作都涉及到整体模型的遍历检查，有些可能是实时操作。
5.常见I/O操作
虽然现在硬盘读写速度已经达到500M/秒，但超大模型的读写，传输仍然存在瓶颈，尤其是文本文件的读写，优化的空间还很大。
6.1亿自由度的仿真计算方法后续介绍
如何处理超大模型
目前，分布式，并发等技术和工具已经非常成熟。熟悉相应的工具即可应用在程序中。对于研发来讲，其核心仍然是如何将模型分解分治，方便软硬件的并发处理。
2.开发调试工具
工欲善其事必先利其器，对于超大模型需要开发出相应的调试工具，不能依赖于原始的简单调试方法。
所以，“调试工具”的开发是一项“磨刀不误砍柴工”的工作，虽然并不能直接体现在软件产品上，但却是提升超大模型开发效率的必备工具。
3.根据数据特征，选择合理的数据结构和操作算法
这个涉及到软件研发中各种数据模型，一方面要精通软件研发中常用的数据结构和算法，另一方面对业务数据和逻辑也要比较熟悉。是一个最能体现研发人员研发功底的地方。细节问题后续再讨论。
4.轻量化底层组件
5.解耦性能瓶颈功能
利用各种性能查看工具，找到性能所在点。将各种造成性能瓶颈的问题抽象提炼出来，做成专用模块在外部处理。比如海量数据查询检索等，可以交给专业数据库。
6.模型提取和二次优化
超大模型处理的性能问题符合典型的“木桶理论”：一只木桶能盛多少水，并不取决于最长的那块木板，而是取决于最短的那块木板，“木桶理论”也可称为“短板效应”。软硬件中任何一个短板或者bug都可能影响整体，针对超大模型，一般模型不起眼的问题也可能成为大的瓶颈。
需要说明的是，超大模型的处理也是考验软件架构设计的一个指标，好的软件架构能帮助定位发现问题，也方便功能扩展改进，在软件设计之初需要考虑到。
做如下测试：在软件中建立圆柱，长方体，球体，圆台，多面体各一个，然后阵列100*100，也就是总共5万个模型，测试编辑性能。事实上，绝大部分商业软件都无法在台式机上流畅的编辑该模型。从实际应用角度看，这还只是一个中小规模的模型。
我们知道三维模型显示起来直观，能表达很多信息，但是数据量也会很大。在很多设计行业，比如服装，零件，建筑草图等最初的设计都在二维进行，一方面是便于出图加工，另一方面也是因为可以轻松处理大模型数据。在桥梁，船舶等设计中，通过多次取三维的二维切面，也可以得到满足设计需求的三维模型信息，在结构分析中以一维和二维单元为主，显示又以面片为主，整体框架实际需求中对三维造型要求并不高。
对于三维模型的显示数据，都是三角形面片为主，再包括点或者面的法向以及UV材质贴图等信息。这些数据采用索引和引用，文件可以压缩得很小。
BIM和EDA行业的模型有一个共同特点：模型中存在大量相同的小几何模型。比如一栋楼的窗户或者大门形状完全相同，只是位置不同。EDA设计中的存在大量形状完全一致的电容电阻焊盘过孔等器件，也只是位置不同。
对象过滤是一种有效的提升性能的方法，其思想是只处理当前用户关心的对象，而让其它对象失效。比如一栋建筑我们关心一扇门时，我们可以将其它对象全部隐藏，或者从视图里过滤掉，这样要处理的数据量就会减少。
这种过滤分几个层次，一个是通过用户操作过滤；二个是在算法层面主动过滤，比如当缩放视图时，根据业务需求只截取当前视图里的对象，如果对象之间有遮挡，只处理最前面的对象。三是根据业务过滤，比如常用的LOD方法(LevelOfDetails)可以根据模型的大小，像素，来选择是否显示或处理。模型的对象上可以赋上各种属性，通过属性来加速过滤操作，类似AutoCAD里的图层信息。
缓存+更新也是处理大数据的有效方法之一，主要用于需要频繁耗时的动态计算逻辑里，数据计算后之后进行保存，需要的时候直接拿取无需再重新计算；只有当业务出现更新时，才重新计算再保存，从而减少计算次数。
开发组件的选择：开发中一般会使用各种第三方组件。
在处理大模型时，组件性能瓶颈也就是程序的性能瓶颈。早期选择三维模型转换组件，最好的和最差的性能瓶颈相差接近一个数量级。而这种组件一旦选定使用后，因为商务和开发周期的原因，一般很难再改。所以早期要做好充分评估。
本文聊了下工业仿真软件中关于大模型的前处理，细心的朋友可能已经注意到了，一般的通用前处理或者CAD软件乃至行业标杆软件在处理超大模型时是没有优势的，在面对实际工业行业应用时也有很多无法满足性能要求。所以很多行业有专门的二维三维设计软件，通过各种针对行业的优化，以及变通方法来满足超大模型的处理需求。
做如下测试：
在软件中建立圆柱，长方体，球体，圆台，多面体各一个，然后阵列100*100，也就是总共5万个模型，测试编辑性能。事实上，绝大部分商业软件都无法在台式机上流畅的编辑该模型。从实际应用角度看，这还只是一个中小规模的模型。
两个典型的例子：
一层楼的实体模型
一栋楼的实体模型
使用一维梁单元力学分析的框架网格模型
2.对一个长，宽，高为1000的立方体进行四面体体网格划分，不带任何材料，边界荷载等属性。以下是在某前处理软件中进行体网格划分，单元长度和单元个数的数据表。
在16G内存，i5CPU4核，有独立显卡的笔记本上，使用前处理器交互操作400万左右单元网格，已经非常卡顿。
之前有朋友在使用开源渲染工具Paraview后，提出Paraview实现过于复杂，不适合做后处理显示。事实上Paraview的设计初衷并不是在单机上进行图形显示，而是处理超大规模的数据，比如模拟核爆，天气，大规模CFD等等。Paraview使用远程和并行数据处理机制，因此在设计上使用了Server/Client的模式，使得在集群，分布式等各种环境中最大化硬件使用效率。
400万左右单元的文件大小在500M左右，1亿单元左右网格文件在8G左右。当单元数在10亿以上时，文件大小也会增加一个数量级。对于这种超大规模的文件，导出，读取，验证都是很耗时的操作。
-----求解器干了什么-----
有限元模型生成后，通常会导出保存为一个文件，文件中保存了节点，单元，材料，边界，荷载，工况，求解等设置信息，求解器会读入该文件进行计算。ANSYS为cdb，ABAQUS为inp，PATRAN为bdf。
一般商业软件都会把求解器做成单独的可执行程序（*.exe程序），单独启动进程求解，而不是集成在前处理器中。一是单独的进程便于管理和分布式计算；二是解耦前处理器和求解器，方便调试；三是可以方便导入到第三方工具中，缺点是模型文件容易被非法查看，可以通过二进制和加密来解决。
求解器读入有限元模型后，首先会检查模型的有效性，比如网格节点是否正确（重复节点，重复网格，索引错误等），还会检查网格质量，最小角度，边长，Aspectratio，skewratio以及对应的求解配置是否正确，比如边界是否设置，工况是否合理（振动频率阶次过多），材料是否有效（比如泊松比大于0.5）等等。当出现不合理设置时，给出警告信息；出现错时，则返回不计算。模型检查合格之后，根据求解器设置，计算每个单元的刚度矩阵，然后组装刚度矩阵成全局矩阵，最终建立起一个非齐次线性方程组，最后求解该线程方程组。
可以看出，超大模型在普通台式机或者笔记本上是无法流畅运行的，一般都需要大内存，好CPU的服务器，而跑仿真更需要高配置的服务器或集群。有些线性方程组求解库提供了OOC(outofcore)功能，即在求解过程中将临时数据保存到硬盘，需要时再导入，以减少内存的开销。从硬件上看，不考虑对CPU性能的压榨，处理大模型最容易造成瓶颈便是内存容量。
宏观上讲，大的几何并不代表计算模型大，小几何也一样。模型的大小和复杂度没有必然的联系。比如火箭振动分析，采用的都是一维单元加质点单元，强度也是采用局部分析。电磁中电大尺寸分析，普遍使用MOM，BEM以及物理光学分析，相比有限元，对网格的依赖非常低，对计算的要求高。一块设计复杂的PCB板，激励上千，体网格数量在千万级别也很常见。而FDTD的GRID数量直接决定了计算复杂度，所以根据实际业务定义超大模型也很有必要。
对于研发来讲，超大模型的一大特点是调试困难。所以也是反复强调开发调试工具的重要性，几何网格开发都需要，尤其在求解器开发中，会产生各种大规模的中间数据，如果没有好的调试工具，出了问题几乎没办法定位调试。
本文扩展讨论了超大模型的一些特点，也是为后面介绍求解器做准备。求解器求解核心内容是对矩阵的操作，这块内容其实也相对成熟，但是针对超大规模的矩阵操作，仍然有许多值得研究的地方，有些还是前沿内容，后续详细探讨。
图1
对于研发而言，从整体框架看，超大模型求解主要涉及到以下几个方面：
1.硬件资源
即如何有效的利用（压榨）所有硬件资源，包括：
1.1.硬件本身资源合理利用，例如内存页面缓存，CPU优化指令
1.2.硬件和硬件之间瓶颈，比如CPU-内存之间带宽，缓冲瓶颈
1.3.硬件资源调度，硬件资源负载分配，负载均衡等，把软件的资源调度归到高性能计算硬件资源这块。在图1中，高性能计算（偏硬）。
参考上图，将仿真计算中对硬件依赖简单分成四层：
第一层，对于小模型我们无需考虑硬件的情况，即不需要做硬件方面的设置，普通台式机即能完成仿真。也就是我们通常所说的“仿真还没有受到硬件的限制”。
第四层，当使用超大规模集群进行计算时，并发性，负载均衡，网络，通信开销等问题出现，在资源调度方面对软件开发提出了要求。
除了常规的硬件，可以利用性价比高的专用硬件，最常用的GPU，TPG。
2.框架并行性
通常我们聚焦于大规模线性方程组的求解方法，事实上对超大模型而言，在现有硬件条件下，计算必须使用分布式计算。常见情况是数据无法一次性读入内存。
（win95时期硬件内存一般只有32/64M，在申请内存时有可能出现硬件内存不够而分配失败的情况）。
从硬件角度看，硬件关心的是数据的整个流程的读入，计算，存储和传输效率以及硬件和硬件之间的协调。以矩阵操作为例，框架并不关心大规模矩阵的分解，分块，求逆等算法操作，因为算法底层最后都是简单的矩阵加减乘(乘法也是加法)操作。
以超算为例，单个硬件的数量可能达到百万级，仅硬件的管理就可能造成瓶颈。数据量大后硬件管理是个运筹学问题。
框架的并行性主要考虑资源的分配，资源调度，沟通开销，根据各自硬件的特性，尽可能利用已有硬件资源。
通常的多线程，多进程方法，以及各种
OpenMP，OpenMPI，MPICH，CUDA等工具可以看作是框架并行性的具体体现。
3.算法并行性
后续会结合硬件资源使用，重点介绍各种大规模线性方程组迭代解法。
针对整体模型求解，通常不考虑常规(算法复杂度高于n*n*n)的求解方法。
4.高性能C++编程
常规编程中，可能对一些C++细节要求并不是很高，比如类似字节对齐，除法改乘法，数据遍历查找，谨慎使用智能指针等，有些编译器会帮助优化代码，比如将乘法优化成位操作等。在大模型处理时，这些细节改进可以带来明显的性能提升。关于高性能C++编程，网上多有描述，后续有空给出详细总结。
我们列举五种有代表性的数值方法来说明超大模型的求解。后续将分篇详解给出每种方法的求解策略。
1.有限元
有限元是目前工业软件仿真领域最常用的数值方法，没有之一。其特点是对求解对象划分网格，对每个网格单元构建刚度矩阵，然后将所有网格单刚矩阵组装整体刚度矩阵，将各种边界，激励，荷载加入其中，最后形成一个线性方程组，其中系数矩阵稀疏，有些对称，有些不对称。显式动力学没有线性方程组。该方法优点是适应性好，通用性强，没有太多前提要求。参考（点击链接）
后续求解器计算中，将介绍
MKL,PETSc,MUMPS,OpenBlas,HYPRE等各种迭代数值计算库在超大模型求解中的应用。这些库分别在硬件和软件层面都做了不少优化。
2.时域有限差分
3.边界元(BEM)/矩量法(MOM)
边界元是一种将网格划分在边界上的求解方法，也就是三维计算只需面网格，二维计算只需线网格。边界元是一种数值解和解析解结合的方法，计算需满足一定条件。借助于解析解，可以大幅减少最终线性方程组的规模。但最方程组的系数矩阵一般满秩，需要借助快速多极子，多层快速多级子等方法提升求解效率，加大了开发难度。矩量法也是一种半解析半数值解法，最终形成的也是满秩矩阵。
4.有限体积(FVM)
有限体积是CFD计算最常用的方法，在大规模计算中对网格划分子块的方法支持比较友好。
5.格子玻尔兹曼(LBM)
LBM是最近十几年逐渐在工程领域流行的求解CFD问题的方法。该方法在介观尺度离散玻尔兹曼方程，不需要划分网格，并且易于并行化，前处理效率高，在一些非常规CFD计算领域有较高的计算精度，是一种典型的无网格方法。
这五种数值计算方法基本涵盖了目前常用的大模型求解场景，即超大规模稀疏矩阵，稀疏对称矩阵，满秩矩阵，有网格无需解线性方程组和无网格无线性方程组迭代计算。
之前简单介绍过HPC，即高性能计算，超大模型的计算和HPC有关联，但并不等价(点击链接参考)：
本文简单介绍了超大模型求解器求解的一些特点，可以看出在现有技术条件下，超大模型求解对硬件资源依赖程度较高，在算法层面也不是简单依靠数值计算方法，更多的是针对实际数据特点，对软硬件资源，数值方法，整体框架，计算策略等综合性考量。
在偏微分方程求解的几种数值方法中，有限元方法(FEM）最为通用，在工程领域应用也最为广泛，没有之一。
FEM有时候作FiniteElementMethod，
有时候FiniteElementModel，
注意区分。
本文将重点讨论有限元方法中的隐式方法，也就是需要求解线性方程组，且线性方程组的刚度矩阵一般是稀疏对称矩阵。还是老规矩，尽可能少用专业术语和方程，软硬件偏软件介绍。
将从以下几方面讨论：
从显式，隐式和准静态说起
以上图片来自网络
1.有限元基本原理和特点
这里简要介绍一下有限元方法基本原理和特点，有限元本质上是求解偏微分方程的一种方法。针对偏微分方程整体求解解析解困难的情况，有限元方法是将分析目标对象本身进行细化，划分成小的有限个网格单元，比如三角形，四面体，六面体等，有时也会根据求解特点将高纬度几何降为低纬度几何单元，将构造的基函数和形函数应用在每一个网格单元，利用加权余量方法求解未知量。
有限元方法最早应用于结构力学分析，后来逐步推广到热，声，电磁，流体等领域，是解决工程数值分析的通用方法。最早基于三角面片，后来推广到各种形状网格单元，主流网格单元为三角形，四边形，四面体和六面体。目前大部分介绍有限元的教程集中在结构领域，对多物理场以及多物理场耦合介绍的非常少，这是国内教材可以加强的一个方向。
有限元方法自诞生以来，在理论基础，物理，数学，工程应用等都得到了验证，是目前求解偏微分方程以及多物理场问题最完备，最有效，最广泛的数值计算方法。
需要提及的是我国的胡海昌于1954年提出了广义变分原理，钱伟长最先研究了拉格朗日乘子法和广义变分原理之间关系。而冯康更是在20世纪60年代于国内独立提出了有限元的方法和概念，并研究了有限元分析的精度，边界条件以及收敛性问题，指导了国内多项重大工程实践。（1965年冯康发表了论文“基于变分原理的差分格式”，这篇论文是国际学术界承认我国独立发展有限元方法的主要依据）。知Zienkiewicz而不知冯康，是我们科普和教材需要改进的地方。
关于有限元更详细的介绍，点击链接查看
2.数据的生产，存储和管理
大模型处理首先要考虑的是数据结构和数据存储方式，我们以1亿自由度double实数存储为例，1亿为1e8，矩阵规模为1e8*1e8，即1e16，假设稀疏矩阵非0数据为总数的0.01%(1e-4)，即1e12。double类型数据占用8字节，内存占用数据为8e12，即8000G，考虑到编译器设置，页面对齐，硬件管理等因素，实际占用数据只会多不会少。
在以往实际用例中，一般自由度越大，其稀疏矩阵中非零数据比例越低。这个比例并没有固定规律，和仿真类型，几何形状，边界，荷载数量，网格大小密度质量等都有关系。假设实际情况其比例在1e-6到1e-4之间，即使取最小1e-6，其1亿自由度的内存消耗也在80G以上，普通台式机无法存储。这还仅仅是一个总刚矩阵数据的存储，没有涉及到任何计算内存消耗。
稀疏矩阵的存储方式
对于一般矩阵，我们常使用一个二维数组来定义，通过行列和索引来存储数据，如：
constintNUMSIZE=1e6;doublevalue[NUMSIZE][NUMSIZE];栈存储不了太多的元素，一般在堆上分配数据，即
constintNUMSIZE=1e6;double**value;value=newdouble*[NUMSIZE];inti;for(i=0;i 稀疏矩阵常用的存储方式有： 该方法采用了三个一维数组，分别存储行索引，列索引和对应的数值 intx[NUMSIZE];inty[NUMSIZE];doublevalue[NUMSIZE];C++STL标准模板库中提供了map容器，该容器可以将一对数据作为key存储。也就是 map 下图展示了分别使用二维数组和map存储double型数据随元素个数N，也就是NUMSIZE值增加的内存开销。下图可以看出到后期，相比数组，std::map的内存开销随N的增加呈指数级增加。 实际存储double数据个数为N*N 在对矩阵数据操作中，一般不会使用STL或第三方库，而是直接使用数据指针。使用过矩阵求解库的朋友应该也有体会，函数参数以及数据传输一般都是直接使用地址操作，矩阵操作首先要保证性能。这也是为什么很多库都会使用C风格的编码方式，即使使用C++，也主要是用在管理数据上，实际数据操作都是偏向C风格。 2.CompressedSparseRow(CSR)和 CompressedSparseColumn(CSC) COO方法虽然降低了内存需求，但从数据压缩角度看，并不是最优。CSR和CSC数据结构可以进一步压缩数据，是最常用的稀疏矩阵存储方式。 以CSR为例，在上图4*4矩阵中： rowoffsets表示行偏移值： columnindices和values则分别表示列索引和对应值： 比如按顺序，第0列的第一个数为1，第1列的第一个为7，第二个为2。以此类推。 可以看出CSR是一种全局编码，相比COO，进一步减少了行索引值占用数据。CSC数据结构类似。 3.DIA(DiagonalSparseMatrix) 即对角稀疏矩阵格式 对于矩阵元分布在主对角线以及主对角线附近的稀疏矩阵，采取这种存储方式比较有效，但通用性不强。 还有其它很多稀疏矩阵存储方式，一般是以上几种方式的衍生，扩充或者组合。 稀疏矩阵的数据结构定义 矩阵数据结构是最基础的数据结构。从计算角度看，稀疏矩阵一般单独定义，单独实现接口；但是从平台和系统架构看，最好是将数据结构融入到系统设计中。 看几个关于矩阵计算的需求： 4.按照业务封装成模块供其它模块调用 这些需求从计算角度看是要尽量避免的，但是从业务和程序逻辑看，又是合理和很可能出现的。 一般矩阵结构定义 C++中提供了template模板功能，可以使用相同的数据结构形式，处理不同的数据类型(double,float,int,complex等)，在矩阵定义中可以灵活使用。 裸指针or智能指针？ C++中，我们把直接使用关键字new在堆上分配内存创建的指针对象称为裸指针，顾名思义也就是没有任何装饰，裸指针在使用结束后需要显式调用delete删除对象。 使用裸指针最大的挑战在于如何管理对象资源。如果数据的生命周期非常短，且作用域非常明确，那问题不大；相反，如果数据贯穿程序大部分生命周期，且容易出现拷贝，赋值，在第三方数据库中操作使用，如果不清楚指针的生命周期和所有权，就非常容易出现空指针，野指针以及内存泄漏等各种问题。 为了从根本上解决指针操作出现的各种问题，C++先后引入了各种智能指针，包括auto_ptr，unique_ptr，shared_ptr等。而一般的开源库软件也都有自己的智能指针， 比如VTK的vtkSmartPointer，OCC的handle等。 在一般业务流程操作和小规模数据操作中，推荐使用智能指针；求解器中对大数据的操作仍然建议使用裸指针。 在以往非求解器和非UI开发代码规范中，会强制使用unique_ptr 3.业务计算流程 典型的一次业务计算流程： 1.解析网格数据 2.创建单刚矩阵 3.组装总刚矩阵 4.组装各种边界荷载激励 5.求解线性方程组 6.提取结果数据后处理 这样的一次流程在软件开发中需要进行封装，便于网格加密迭代，优化算法，扫频，或者多步瞬态方法等外部程序调用。尽可能做成独立通用的模块，即不依赖具体的业务，不依赖特定的算法，在使用过程中按照外部输入参数定制。 不同物理场由于基函数取值不同，实际组装内容是不同的，不同的仿真类型和网格单元，其单刚矩阵具体内容也非常不同，计算单刚矩阵和组装总刚矩阵是有限元计算方法的核心业务。在常用的三种最基本类型边界和荷载基础上，不同物理场会衍生出多种具体形式的边界荷载，进一步结合几何模型，仿真类型，实际操作方法等，会固定出业务上的常用边界荷载，这也是商业软件的一大突出特点。 不同物理场计算其刚度矩阵组装过程大同小异，在求解器架构设计和开发中是可以流程化和平台化的。 4.并行和分布式处理 抛开算法，从软件角度看，并行和分布计算体现在以下几个层次： 1.业务并行 这个是最容易理解的，业务并行的最大特点是每个任务之间没有互斥的数据，前后顺序依赖关系也比较弱。比如在DOE设计，扫频，优化设计中，各个模型之间共享模型数据，只是某些求解参数设置不同。所以很容易将每个任务派发到不同机器节点上执行。这里没有涉及到数据交互，网络带宽，负载均衡等，是最容易的并行计算。 2.Culster集群式并行 3.单机并行 在单机上，CPU多核已经非常普遍，利用多线程，多进程可以轻松做到在不同CPU核上并行计算。而单机的线程工具已经非常普及，比如OpneMP，C++11新增线程类，QT提供的线程进程操作工具。对于类似共享内存式并行，网络以及通信开销可以忽略不计。 4.指令优化 单指令流多数据流机器（SIMD） SIMD是采用一个指令流处理多个数据流。这类机器在数字信号处理、图像处理、以及多媒体信息处理等领域非常有效。 Intel处理器实现的MMXTM、SSE（StreamingSIMDExtensions）、SSE2及SSE3扩展指令集，都能在单个时钟周期内处理多个数据单元。也就是说我们现在用的单核计算机基本上都属于SIMD机器。 多指令流多数据流机器（MIMD） MIMD机器可以同时执行多个指令流，这些指令流分别对不同数据流进行操作。最新的多核计算平台就属于MIMD的范畴，例如Intel和AMD的双核处理器等都属于MIMD。 指令优化主要针对具体硬件的指令支持情况，程序中合理使用指令集，计算可以起到很好的加速效果。 5.异构架构式并行DPU（DataProcessingUnit）是以数据为中心构造的专用处理器，采用软件定义技术路线支撑基础设施层资源虚拟化，支持存储、安全、服务质量管理等基础设施层服务。2020年NVIDIA公司发布的DPU产品战略中将其定位为数据中心继CPU和GPU之后的“第三颗主力芯片”，掀起了一波行业热潮。DPU的出现是异构计算的一个阶段性标志。与GPU的发展类似，DPU是应用驱动的体系结构设计的又一典型案例；但与GPU不同的是，DPU面向的应用更加底层。 从工程学角度看，并行计算的本质是提升性价比，GPU的应用对于数值计算而言是异构架构一大成功。NVIDIA提供的CUDA计算语言成为GPU计算的主流工具。 有限元求解器主要操作对象是矩阵，对于大矩阵计算，涉及到的是矩阵的分块和分解以及并行计算。矩阵的分块和分解是两个不同的概念，注意区分。 求解线性方程组，不管是迭代法还是直接法，最多的运算是矩阵和矩阵乘法，矩阵和向量乘法。乘法的并行计算是各个基础库的计算核心功能之一。 图画分 对于一个超大矩阵，通常需要分块，分块的目的是在已有硬件资源基础上，让每块获得合理的计算资源，达到并行计算的目的。而并行计算一个核心问题就是负载均衡，即整体上每个计算资源要与计算内容匹配，避免部分硬件资源长期闲置。这就要用到图画分工具。 图论：一般将网格单元抽象成一张图的顶点，顶点的权重代表网格单元的计算量，网格单元之间的数据依赖关系抽象为图的边，边的权重代表网格单元之间需要交换的数据量，这张图反映了问题的基本计算量和数据依赖关系，可以作为该问题的负载模型。对于稀疏矩阵，该图可以描述向量乘法的基本计算量和数据依赖关系，稀疏矩阵向量乘法的负载均衡可以转化为图的多路划分问题。在一些线性方程求解库中，可以看到相应的图划分工具。 5.线性方程组求解 1.MUMPS网址： 最新版是5.5.0(2022年4月) MUMPS全称 MUltifrontalMassivelyParallelsparsedirectSolver 是一款经历了长期实践检验，专业可靠的求解大规模稀疏矩阵线性方程组的工具库，在很多商业以及开源CAE/EDA/CFD等数值仿真软件中都有采用。 MUMPS采用的是直接法，支持串行和并行计算，底层编码语言Fortran和C。 MUMPS求解过程： 1.主进程执行排序和符号分解； 2.进行LU分解或LDLT分解，将矩阵A分布到多个处理器上，每个处理器对每个波前矩阵进行数值分解 3.主进程将B和x分布到各个处理器进行因子计算后 在以往超大规模的热，结构动力和高频电磁有限元仿真计算中，相比其它求解库，MUMPS表现出了内存消耗少，速度快，负载均衡合理等优势。 2.OpenBLAS网址： OpenBLAS是一个优化的BLAS库，基于GotoBLAS21.13BSD版本(该版本不再维护更新) 6.后处理 数据的后处理涉及到的也是关于大数据的公式计算，查询，提取以及存储。有限元方法计算的结果通常放在节点，边或者高斯积分点上，根据实际需要将其映射到对应单元节点上，即可方便实现绘图。 1.后处理的计算一般依据已有公式，没有太复杂的算法。对于大数据，单机可方便使用共享内存OpenMP即可实现并行加速。图形渲染上可以参考Paraview的客户机/服务器模式。 2.在后处理中，尽量避免全局计算：用户通常感兴趣的是物理量最大最小值以及一些特殊特定几何位置的数值。合理设置探测点，同时通过业务逻辑过滤，减少数据的计算，避免全局任何n方以及以上的操作。 7.优化改进 1.设计模式 点击链接查看 设计模式本质上是一种代码规范，它要求开发人员针对某类问题能使用相同或类似的设计思路和方法。这样做的好处是： 1.能反映出问题的本质，帮助做出更好的设计； 2.方便开发人员之间协作和沟通； 3.有利于提升软件质量和代码维护。 求解器开发并不仅仅是底层算法实现，还包括了大量业务和应用层面的需求。比如线性方程组的库的包装，切换，更新；网格自适应迭代集成；优化设计模块集成；第三方平台调用；硬件参数自适应；程序稳定后的功能维护扩展或者重构等等。 这些非常需要从软件工程和系统工程角度考虑问题和设计，而非仅仅有限元算法本身。这也是长期以来强调软件开发要重设计架构，轻语言代码的体现。 2.调试 大模型的求解器调试一直是非常有挑战性的难题，主要原因还是数据量太大，导致平常一些不起眼的小功能也能导致性能瓶颈，比如文件读取，网格解析，有效性检查，中间数据导出等。很多的这种性能瓶颈集合在一起，最终的结果就是一天可能只能调试2-3次，严重影响开发效率。可以从以下几个方面改进调试： 1.完善模型数据导出。在任意一步计算中，可以方便地将数据导出为常用的数据格式，比如CSV，MATLAB文件格式。这个操作和模型大小无关，是基础性的功能开发，需要保证高效和正确性。 3.模块化分级。将整个计算仿真流程模块化，按照功能有重要程度分级，每个模块能够通过文件提供接口。这样做的好处是流程中每一步可以做有效性检查，一旦出现错误可以快速定位出问题的步骤。也方便更新golden模型。 4.独立的数据分析模块。该模块可以独立提供整体模型的数据特点，包括网格质量分析(求解角度)，敏感度分析，各种矩阵特征分析等。有些功能第三方库会提供。 3.硬件使用 前面讲过超大模型的计算和硬件紧密关联，有些工具库甚至需要在运行机器上编译，根据硬件实际情况优化后使用。根据业务合理的选择硬件和软件资源是加速求解的关键。 本文介绍了超大模型有限元求解器计算方法的一些研发知识，可以作为有限元方法工业级应用开发的入门参考。需要说明的是，超大规模的有限元模型求解方法非常依赖模型数据的特点，并没有一个黄金标准方法，需要在实践中选择合适的方法。