你为什么感觉自己比ABAQUS算得快 原创

关键词：软件架构，ABAQUS，UMAT，铺层，开发者视角

适用阅读人群：ABAQUS高阶用户、有限元软件开发人员、求解器开发人员、工业软件从业者

练习书法过程中，需要不断地读帖。所谓心摹手追，读帖过程中，揣摩每个字的结体、行笔线路、线条变化，然后再下笔临摹，时间久了水平自有进益。

开发软件的过程也是这样，尤其是模仿自己非常熟悉的软件。我们需要跳出自己的习惯，去审视它，它为什么这么设计？优点是什么，限制又是什么，为什么只能这样，不能那样。

最开始开发求解器的时候，尤其是简单的求解器，跑一个简单的案例，你会经常发现自己的代码比ABAQUS算得快。如果对软件设计不够了解，便容易洋洋得意，甚至发论文讲自己的代码效率高，显著优于商用软件，打破国外垄断，填补国内空白，推动行业进步，应用前景不可限量。

在SFEM以及其他有限元软件开发项目中，我常常有豁然开朗的感觉，忽然明白原先以为ABAQUS一部分很难理解的设计，可能是不得不这么干，否则软件逻辑就会不通。

本文就从开发者的视角，浅谈一下ABAQUS软件的一些设计思路。由于该软件整体上是个黑箱，大部分都是我从开发的角度揣摩的，未必对，仅供参考。

1. 分析步与网格类型必须强制匹配

ABAQUS要求分析步类型与网格类型必须匹配。举个例子，如果分析步选用了热力耦合分析步，那么单元类型也必须选热力耦合单元。

分析步类型

网格类型

如果选了常规的静力使用的单元，就会报错。这么设计当然没毛病，因为热力耦合单元和静力单元的维度不同，刚度矩阵也不一样。但是为什么必须这么设计呢？

为什么ABAQUS不能根据分析步的类型，自动对单元进行处理呢？比如，明明知道它是三角形单元，非要让用户定义它是热力耦合的还是静力或者单纯传热的，而不能自己根据分析步对这个三角形单元进行处理。

如果我们自己写一个简单的线弹性求解器，就很难理解这一点，我们会觉得，无非就是刚度矩阵组装后，代入边界约束，然后矩阵求逆就完事了。

ABAQUS这样处理的原因，很大程度上是因为软件高度模块化的结果，即由网格到刚度矩阵的生成是一个单独的模块。求解器的输出是inp文件，inp文件中，节点和单元直接丢给网格处理网格，网格处理模块根据单元的类型关键字，就可以直接进行单元刚度矩阵的生成和总体刚度矩阵的组集，而不需要读入inp的分析步设置。

分析步模块，专注于负责求解控制，这里负责搭建完整仿真流程，控制步长，判断收敛等等。

通过这种解耦，各个模块不去干涉对方的工作，更容易形成通用、成熟的软件模式。

2. Part 与Assembly的解耦

ABAQUS的这种模块解耦设计的思想，在Part 与Assembly的设计上体现得最深刻。

在Part部分，我们可以导入一堆几何模型，但是在Assembly可能我们只会选用部分几何模型，用于后续的边界条件定义和网格生成。这样做的好处是，用户便捷地更换模型，方便进行设计迭代与参数化研究。只要拓扑关系相似，原先建立在装配体级别的接触（Interactions）、载荷（Loads）和边界条件（BCs）通常可以自动保留或快速重新映射，大幅缩短了设计迭代的周期。

Assembly

另外，如果你在一个装配体中需要用到50个相同的螺栓，你只需要在 Part 模块中创建一个螺栓模型。然后在 Assembly 模块中，你可以将这个螺栓实例化50次，并放置在不同的位置。

我在开发SFEM V1.0阶段，正是借鉴了这一点，预留了Assembly模式的接口，方便在2.0版本实现Part和Assembly隔离。

3. Set（集合）思想

ABAQUS软件的另一大精髓设计就是：贯穿始终的 Set（集合）思想。

体感上，我们导入模型后，定义材料参数，你会觉得是把材料赋予了整个模型。

定义边界条件的时候，你从视口中拾取一个面约束，你会感觉整个约束加在了这个面上。

实际上，在上述过程中，ABAQUS自动把你选择的模型、点、面、单元自动转化为一个Set或者Surf：

材料参数定义后自动创建的Set

约束定义后自动创建的Set

这个天才般的设计思想，被全部借鉴到了SFEM的开发中。

首先，Set具有极高的复用性。一个定义好的SET可以在模型的各个环节被反复调用，而不需要每次都去屏幕上重新框选。举例：假设你定义了一个名为 Bolt_Hole 的SET（包含螺栓孔内表面的几何或节点）。你可以：

(1) 用它来定义接触面（Surface）。

(2) 用它来施加螺栓预紧力或边界条件。

(3) 用它来定义局部坐标系下的材料方向。

(4) 在后处理（Step模块）中，专门请求输出这个 Bolt_Hole SET 的应力集中数据（History Output）。

一次定义，多处引用，大大提高了建模效率。

其次，Set显著提升 INP 文件的可读性与可维护性。ABAQUS的底层求解器是读取 .inp 文件的。如果不用Set，你的输入文件里会充斥着成千上万个毫无规律的节点和单元编号，难以阅读和修改。

另外，Set思想极大便利了参数化建模与二次开发。如果你使用Python对ABAQUS进行二次开发或参数化建模，Set是不可或缺的桥梁。在脚本中，通过坐标或拓扑关系自动找到某些点/面是非常复杂的。标准的做法是：通过脚本利用坐标系找到目标几何 将其命名为特定的Set后续所有的施加载荷、网格划分、结果提取操作，全部通过调用这个Set的字符串名称来完成。这种基于名称的寻址方式，使得脚本非常稳健。

4. 铺层角度为什么无法批量定义

在使用ABAQUS进行复合材料铺层定义的时候，Composite Layup的使用让人觉得很难受。因为每行的Region、Material、CSYS都需要点击后进入另一个弹窗去定义。这逼得你不得不手动操作半天，如果铺层区域很多、铺层角度很多，这个工作量还不小，且容易出错。

Composite Layup窗口

我在使用的时候常常想，为什么不让我们直接导入一个表格定义呢？又快又方便。

表格导入不是技术上达不到，而是ABAQUS出于一种防错设计思想。Region的定义，需要让用户选择定义好的单元Set，如果未定义，就链接到Set定义。同样的，Material、CSYS都需要如此。

如果直接导入表格，可能会出现根本不存在的Set、Material、CSYS。

我在设计SFEM的时候，没有借鉴这一点，因为我们工程中接触的大部分实际构件铺层都很厚。花半天的时间逐行输入，确实太耗时间。为此，我设计的导入铺层的功能，可以直接导入表格，材料参数和区域都通过文本定义即可。

SFEM软件铺层定义窗口

对于变厚度的情况，通过参考几何、铺层表格，自动完成复杂的厚度、铺层定义。

SFEM软件变厚度铺层定义窗口

SFEM软件变厚度铺层定义效果

5. 铺层定义为什么无法和UMAT同时使用

继续聊铺层。在ABAQUS中，如果使用了铺层Composite Layup定义实体或壳单元，这时候再调用UMAT子程序就会报错。

也就是，ABAQUS并不支持铺层定义与子程序的联合使用。我开始以为是ABAQUS的问题，后来发现还有“用户”的问题。

我们学复合材料力学，就会接触到单层板的Q矩阵，以及层合板的A、B、D矩阵。

对于大部分人来说，编写一个代码：单层板根据铺层角度、厚度，同时进行坐标系变换、积分，逐层汇集的A、B、D矩阵是个不小的挑战。单这一条，就拦住了80%的用户。

除此之外，还有个更关键的问题，如果需要支持用户在UMAT中定义层合本构，UAMT需要增加铺层信息的传入，否则用户无法进行坐标系变换和厚度信息的获取。

另外，UMAT中的应变不是含有“铺层”的应变，如果要用，应变要给用户提供每一层的应变。

同样的还有要应力的处理，因为UMAT需要用户返回应力结果，因此在刚度矩阵集成后，用户需要计算出每一层的应力返回给UMAT，UMAT同样没有整个接口。

这将大大增加ABAQUS主软件端UMAT接口难度，可以说需要他们重新开发整个接口。

因此如果要满足铺层定义、UMAT的联合使用，需要用户具备很高的水平，也要求ABAQUS专门开发非常复杂的UMAT接口。

如果我是软件开发商，这个吃力不讨好的功能，也不会列入开发计划。

6. 子程序为什么要进行环境配置，以及为什么算得慢

我最先接触ABAQUS的时候，最头疼的就是软件的安装。尤其涉及到子程序后，还需要额外安装VS、Fortran，安装的时候，必须要软件版本互相匹配，且要按照一定的顺序安装。每换一个电脑，经常捣鼓一天的时间搞安装。

那么为什么子程序一定要进行环境安装呢？

这是因为ABAQUS的求解器从根子上就是Fortran编写的，用户写的代码需要直接与求解器的底层核心代码进行编译链接，使用同种语言效率最高、最稳定。

但是单纯的Fortran程序是无根之萍，无法直接运行，需要相应的运行环境。

正因如此，使用子程序意味着ABAQUS的求解器需要调用外部函数。这也造成了，相同本构情况下，内置模型算的快，子程序算的慢。

ABAQUS在发展过程中，引入了C、C++、Python等语言，尤其是前端交互，支持Python二次开发，养活了一大帮人。但是早期求解器的语言限制，Python短期内还不会被引入作为求解器的接口。

7. odb文件为什么无法在ABAQUS外部解析

ABAQUS 求解器的输入inp文件是可读、可编辑的，这个设定给我们搞二次开发带来了充分的发挥空间。

然而，一旦我们试图把ABAQUS当做底层求解器使用，自己搭建前后处理流程，就会面临一个重大的问题：结果文件无法被外部解析。

ABAQUS的结果文件.odb 并不是像 .csv、.json 或开源的 .vtk 那样的纯文本或公开标准的格式。它是高度定制的、闭源的二进制数据库格式。

这不是技术问题，而是设定问题，你不知道人家是如何编码的，自然也就无法解码。

这也是商业上的巧妙考量，如果 .odb 是开源格式，那么其他竞争对手（如 ANSYS, Altair HyperWorks）或者开源后处理软件（如 ParaView）就可以完美、无缝地读取 ABAQUS 的结果。达索系统希望用户留在自己的生态里。你要看结果，就必须购买并使用具备 Abaqus License 的环境。这是一种非常经典的商业软件护城河策略。

8. 你的求解器为什么感觉比ABAQUS快

回到我们开头的问题，有时我们开发一个有限元求解器，在ABAQUS对比效率的时候常常发现自己的代码出结果更快。

之所以有这个现象，是因为我们拿求解器的效率去和ABAQUS整个软件的效率在比。

在我们提交job任务的时候，ABAQUS后台会有如下处理步骤：

（1）生成inp文本。这需要ABAQUS从内存数据中，通过inp生成模块创建inp文本；

（2）求解器读取inp。求解器解析inp，讲网格信息、分析步、边界条件等丢给不同的处理模块

（3）求解。

（4）结果写入odb文件。

（5）读取odb文件，解析为后处理显示用的云图等数据。

上述步骤中，网格少、求解步骤简单问题来说，求解的时间反而是最少的。因此我们拿自己求解器和整个流程去比，当然显得速度很快。

结语

你不做有限元软件开发，见ABAQUS如井底望月，你做了有限元软件开发见ABAQUS则如浮游见青天。

除了数学、力学知识外，有限元软件的开发本身就是一套严密、复杂的系统工作。我的文章留言中，有很多的唯AI论者。好像有了AI，工业软件的开发就易如反掌。

我从不质疑AI的强大，并且在目前我所有的软件开发中，都使用了AI进行辅助。但是“有了AI，有限元软件开发就不再重要，即使开发也变得十分简单”这个论调是完全反智的。

难道有了AI，数学、力学我们就可以不学了？软件逻辑就不需要人来推演了？行业知识与物理模型的融合，就可以脱离人了？

之前的这类留言，我都保留了。以后这类反智留言我会直接删除，这类人会直接被拉黑，咱们互不打扰。