有限元理论基础及Abaqus内部实现方式研究系列11：自主CAE开发实战经验第一阶段总结

SnowWave02 浏览：3534 评论：6 收藏：2

（原创，转载请注明出处）

1 第十一篇：自主CAE开发实战经验第一阶段总结

不知不觉，有限元理论基础及Abaqus内部实现方式研究的系列文章已经完成了10篇，还记得写系列文章的最初目的就是将我们自研有限元求解器开发过程中的经验记录下来，供后来者借鉴参考，也希望能和同行进行更多的交流，前面10篇文章更多是有限元的局部技术的经验分享，本篇做个专门的阶段性总结，结合自编的iSolver求解器，从整体角度上介绍一下自主CAE的一些实战经验，希望能对大家平时的实际开发起到点微小的帮助。同时，由于水平有限，经验也局限在自身，可能有许多的理解错误，欢迎交流讨论。大家在阅读的时候欢迎在技术邻上下载我们的软件试用，同时也可以更加直观的查看我们的视频和资料等。

国产CAE领域，有两种声音，一种是觉得很难，绝对不可能替代商软，然后对商软推崇备至，只要是商软的结果都是对的；另一种是觉得很容易实现，随便弄个团队干个三五年就可以商用甚至打破国外垄断了，然后觉得没必要用商软，高深新颖的有限元理论自己编程才是王道。我们只是一头过河的小马，听到了老牛和松鼠的告诫声，不想停滞不前，就想要用自己的脚一步步测试河的深浅，也许永远也到不了对岸，但起码了解了什么地方深，什么地方浅，以及哪些地方有石头可以垫个脚，哪些地方有很深的大坑。同时，也像一个探针一样，测一下商软的电压是多少，到底哪些结果是可信的，哪些结果根本就是完全错误的，从而指导自编程序的实现。

1.1 十年磨一剑是不够的

2007年的时候，看到某个论坛上有个ID叫“十年磨一剑”，觉得很贴合自研有限元的开发难度和专研精神，然后在记事本的首页写下了“十年磨一剑”（From 2007年），接着开始调研自主CAE的实现途径，12年过去了，才发现我们的自主有限元求解器依然还只能算刚上路。回头想想也正常，看结构商用有限元的发展，那些有限元洪荒时代的Nastran、Ansys、Abaqus等，在基本没有竞争对手的情况下，也开发了少则4年，多则8年之久才推出第一个版本，而现在，在商软垄断下的状况下，推出任何一个新的软件都是非常困难的，在没有应用没有需求的驱动下，10年的开发时间其实真不长。（10年仅指我们开发iSolver的经验，毕竟团队能力和实际开发时间每个开发者不一样，而且计算机技术也在突飞猛进，如果你的团队配置和投入增加，这个时间应该可以减少很多）

按现有的开发经验来说，如果不是国家政策和发展模式的转变，预估一下，我们这一代人退休了，自主CAE可能还是没法达到商用，我们现在工作的意义就是可以把开发CAE的代码和经验留下来，让下一代人继续在此基础上研发，还有，就是给下一代人一点不是纸上谈兵的信心，通过愚公移山的笨办法实现国产CAE商用这一目标。

1.2 源于兴趣，始于积累

如果让你做一件需要10年以上的事情，在这十年内都不会有什么产出成果，你会不会做？

我们开发自研CAE，从本源来讲首先是兴趣驱动，未知的领域在探索过程中觉得很有意思，在晴朗的周日午后，搬个桌椅坐在阳台上，吹着凉风，听着音乐，自己编程解决一个一般人没有研究过的难题时，偶尔放下键盘，在心底升起一丝丝的满足感，这满足感不是来之于钱、地位、权利等等，仅仅来之做自己喜欢的事情时的快感。

有了兴趣，基本的开发技能还是必须的，否则就是空想了。平时估计大家都要讨生活做杂事，学生还要忙毕业，技能的锻炼只能靠业余时间的不断积累，如果你已经确定了要开发自主CAE的目标，每天工作、吃饭、睡觉想的是这个目标的话，那么平时所有的事情只要和目标相关，自然会投入更多的精力去学习，去朝着目标而努力，素材多了，融会贯通，良性循环，剩下的就是时间和耐心了。

按我们的经验，认为开发有限元求解器的基础知识主要分为三类：数学、计算机、力学，如下图所示：

在开发自主CAE软件的同时，我们经历了许多实际仿真工程项目，这为我们积累了很多宝贵的实际工程经验。这些项目主要分为两类：

一类是商业CAE软件的二次开发，这也是最常见的工程项目，通常是根据客户需求定制仿真流程，目前二次开发过的商业CAE软件主要由Abaqus、Patran\Nastran和Ansys。从这类项目中一方面可以积累丰富的开发经验，另一方面可以从客户需求中了解背后的物理问题和相应理论，无论是对知识的深度还是广度都有极大的提高。

第二类是专用有限元求解器，通常是针对某一类特定问题进行求解。这一类项目做多了就会深刻体会马克思主义的伟大，从特定问题找出一般规律。我们软件的框架也正是基于有限元的基本问题，综合这些特殊问题来抽象建立的。

1.3 成长是曲折艰难的

1.3.1 编程语言选择

单纯编程语言之间的优劣比较是没有任何意义的，每种编程语言都有长处和短板。一开始，我们选择编程语言的考虑主要包括以下因素：

1、运行速度

尽管如今的计算机硬件性能已经如此之强悍，有限元求解器需要解决问题的规模仍然是如此之大以至于我们不得不花费如此多的精力去考虑如何让计算变得更快。而编程语言运行速度就像人类身高这样的天赋，它决定了计算速度的上限。在科学计算领域，Fortran有巨大的优势，它的编译器优化是其它任何主流编程语言也无法媲美的。如果有人认为是C或C++，请放弃这个错误观念，这两种语言的运行速度最终取决于编程能力而不是语言本身，而能够让他们与Fortran运行速度相差无几的编程大师应该也没什么精力来搞有限元。

2、易维护性和易复用性

不得不说，一提到这两个词，大部分时间里我们脑袋里首先蹦出的是C++或者是一些别的面向对象的语言，这与我国的编程教学有关。从一开始学习编程语言，我们就被迫地接受面向对象就代表着易维护性和易复用性。在这一点上，我们首先认识到面向对象只是一种思想，一种描述问题的方法。它与语言无关，使用C语言这个被人认为是面向过程的语言也可以优雅地写出面向对象的代码。更进一步，我们看到编程思想与易维护性和易复用性毫无关联，面向对象被浓墨重彩夸了很多年，别人用C++写出的代码我们依然看不懂，更别谈维护和复用了。在实际的开发过程中，我们慢慢意识到合理的框架设计和严格的编程规范才是易维护性和易复用性的根本。

3、第三方库

很多人会抵制第三方库，因为它们让我们的软件显得不完全自主可控。在这一点上，我们觉得到底该不该抵制第三方库取决于你用它们来做什么，毕竟如果严格一点来看的话，操作系统、编译器等等也包含大量的第三方库了。在科学计算领域，传统的编程语言Fortran、C和C++都已经具备了大量的数学计算库，这有助于我们从求解线性方程组的泥沼中暂时脱离出来，集中精力关注有限元中的静力、模态、动力学等问题。后起之秀，如Matlab、Python等，由于语言的设计意图，各种计算工具箱更是花团锦簇。请注意，Matlab不只是一个计算工具箱，它实实在在是一门优秀的编程语言。

4、编程效率

编程效率是一个极为重要的考虑因素，也是我们最终选择内核用Fortran接口用Matlab的决定因素。编程效率其实隐含了上述的三个因素，也还包含了一些别的因素，例如团队整体的编程能力、以往的经验积累复用效率、跨平台移植效率等等。

目前，基于Matlab和Fortran的混编进行自主CAE软件开发仍然是我们的优先选择。但后续如果重新规划整个软件的编程语言，可能是这样的：

（1）求解器计算这块，采用Fortran，同时将并行计算和显卡硬件加速规划进求解器的整体框架设计中；

（2）前后处理的人机交互界面，后台的核心计算功能，采用C++；

（3）前后处理的业务逻辑和用户开发接口采用Python。

1.3.2 求解器整体框架研发

很多时候我们都在疑惑为什么国内这么多高校和研究所都在研究有限元，却始终没有一个成熟的商业求解器，显然这么大一个问题的原因是多方面的。这里，我们只考虑有限元理论研究和软件研发的可持续问题，即缺乏一个可持续的体系，能够将我们以往的工程经验以统一形式固化下来并融合为一体，经过不断地积累，发展成为一个成熟的商业求解器。这个可持续的体系，我们认为就是软件的框架。

首先，我们需要去区分软件的架构和框架，因为大多时候我们将其混为一谈，而最终导致软件永远在空想中，而未能形成实体。

软件的架构即软件的草图，它定义软件的各抽象组成和这些组成之间的关系和相互接口，这也是很多软件项目论证报告中填写的主要内容。很多软件研发人员喜欢讨论软件架构，并将软件项目的最终成功与失败归结到软件架构上，因为一方面软件架构代表着领导地位，是需要从全局去考虑问题的，讨论它似乎会带来一种天然的优越感；另一方面，软件架构就是个抽象的概念，并且没有可以量化的技术指标或者性能指标，架构设计完成之后似乎也干不了什么事情，这使得其成为软件项目最好的背锅侠。

软件的框架就很实在了，它是软件的半成品，实现了软件的共性部分，为软件提供基础的结构和一些规范约束，然后开发人员在软件框架的基础上进行开发。从这个定义我们可以看出，软件架构设计到软件开发完成的过程是必然要形成软件框架的。遗憾的是，在国内大部分软件项目的研制总结报告中，我们看到的仍然是软件架构而非软件框架。

那在求解器中，我们的软件框架到底做什么呢？举个例子，我们在软件框架中提供了用户自定义材料的接口，用户根据接口集成了一个自己常用的材料，并将其应用在前处理模型中，就可以直接提交计算了，因为我们的软件框架包含了完整的有限元求解流程和基本有限元数据类的实现。由此可见，软件框架是我们研发求解器的基础。

在软件框架中，最核心的莫过于有限元问题基本数据结构和有限元问题求解算法了。有限元问题基本数据结构与前处理息息相关，更侧重于描述问题，这里我们不作讨论。经过多方调研，综合考虑线性和非线性的问题，我们确定使用增量迭代法求解有限元问题。

1.4 吾日三省吾身

很多时候我们往往只关注专业问题本身而忽略软件工程在实际开发中的重要性，这也是大多高校学者和研究机构科研人员的通病。测试是软件工程中极其重要的一个环节，加强软件测试可以有效地提高软件的质量和生产效率,并可以降低整个软件生产的成本，这是我们在遇到很多问题之后深刻反省才意识和理解的。

测试的问题不是怎么测试，而是大部分编程的人都不重视测试，我们的经验是开发和测试时间的比例大致1：1比较合适，专人负责。测试可以在编程前先做，用测试驱动开发（TDD Test-Driven Development）。测试可以分为功能测试和正确性测试，功能开发的目标就是通过前面的功能测试算例。功能测试完后需要做正确性测试，正确性考核算例的选择可以有很多。线性情况下对梁和体，因为iSolver的结果和Abaqus完全一致，所以没有考核了，对壳的话，需要进行正确性的考核。正确性的考核有很多标准算例，我们下面的文章：

有限元理论基础及Abaqus内部实现方式研究系列5：单元正确性验证

http://www.jishulink.com/content/post/373743

文章附件中有我们采用的标准算例的Abaqus模型，你可以直接使用，希望能帮你少建一部分考核模型。

1.5 邻家有女初长成

1.5.1 功能

CAE的开发是一项复杂功能，可以分版本开发，第一个版本为基础版本，没必要样样具备，文档、推广和应用也是要花时间和精力的，第一个版本自主有限元求解器应该满足的功能如下，后面的版本可以在此版本上滚动发展：

1.5.2 目标

iSolver的目标不是也无力实现通用的商业化求解器，而是做一个完全自主的有限元程序通用开发框架，可以快速集成客户的自研有限元算法和分析流程，开发解决特定问题的、与商业软件系统建立接口的、具备良好互操作能力的专业仿真软件，避免用户从头开发，最终帮助客户实现自研程序的商业化包装和推广，快速的形成自主品牌的CAE软件。

1.5.3 成果

1.6 路漫漫其修远兮

如果认为基础功能完成后，自主有限元就已是康明大道，那还是太小看CAE软件了，Nastran都有被淘汰的危险，更何况新的有限元软件，只能适应现代有限元的发展趋势继续赶路，前途依然乌云密布。按照难易程度对自主CAE的发展做个简单的规划，当然这几个步骤是交叉在一起的。自主CAE开发的阶段和难易程度预估如下，每一项都很难，当然我们现在还没走到最后，可能预估的不够精确。

1.6.1 求解器的发展方向

有了基础版本，能想到的应用领域有下面几点，大家要有好点子可以补充：

（1）专用求解器开发，针对某一细分领域做专用求解器，在细分领域积累客户和专有知识，培养核心竞争力，这是我们一直在努力的，希望能和更多的同行合作。

（2）做物理场耦合，和其它领域求解器结合完成多物理场迭代的定制开发。

（3）做优化、参数化、自动化，和实际工程业务背景结合实现自动化快速建模的流程，封装用户流程。

（4）做教学软件，带教学例子，将有限元原理和实现同时以简单易用的方式展现出来。

（5）做游戏或者动画等对计算精度不高的领域，快速出结果。

1.6.2 前后处理

有限元的前后处理主要功能可以分为几何建模、网格划分、边界和载荷条件施加、分析步设置和结果的可视化处理，目前流行的商业软件主要有Abaqus/CAE、Femap、HyperWorks、Patran、Ansys WorkBench、ANSA等。近些年，在CAD与CAE相融合的大趋势环境下，很多CAD厂商也纷纷加入前处理软件的战团，如UG NX、PTC Creo等，并且充分发挥了它们在几何建模这一方面的优势。更长远的看，前后处理软件必将与CAD软件融为一体，设计必须通过仿真校核，仿真是设计的一部分。

注：Femap也是Siemens软件家族的一份子，几何建模部分采用的是ParaSolid内核。

目前，我们开发了一个简单的前后处理软件，相对商用前后处理来说还有较大差距。在我们看来，相比求解器而言，前后处理软件的开发难度是更大的，主要内容有以下部分：

1、三维造型引擎

作为几何建模的核心，这块内容一直被国外商业公司垄断，部分应用广泛的开源内核如OpenCASCADE之类也一直存在速度和精度方面的问题。但无论如何，前处理软件开发是需要突破这个技术难题的，毕竟前处理的起始必然是几何建模。考虑到商业三维建模内核价位普遍很高，仅此一项成本，就已经是自研前处理软件的巨大障碍。

2、三维渲染引擎

前后处理不单单是构建三维模型，还需要将三维模型显示出来，在后处理中还需要将应力应变等等与三维模型结合起来共同渲染。在实际工程应用中，经常会出现网格规模超大的有限元模型，这对三维渲染引擎的性能要求是极高的。遗憾的是，国内目前尚无成熟的三维渲染引擎，或者适用的工业三维渲染引擎。值得庆幸的是，由于大家似乎都比较感兴趣能够在计算机上直观地看到三维模型，所以开源的三维渲染引擎倒是很多，并且部分引擎的性能已经足够使用，如VTK之类。

3、网格划分工具

有限元网格划分是进行有限元分析至关重要的一步，它直接影响着后续分析结果的精确性。网格划分涉及单元的形状及其拓扑类型、单元类型、网格生成器的选择、网格的密度、单元的编号以及几何体素。与三维渲染引擎类似，目前市面上也有比较多的优秀开源网格划分工具，如GMesh、Netgen等。

综合来看，有限元前后处理软件开发在没有基础的情况下，最好还是结合现有的开源软件进行开发。至于难度，这里我们举一个例子，Abaqus与达索CATIA合作多年后才推出了自己的前后处理软件，而且也不是从头开发的，依然用了CATIA的造型和三维渲染开发包。所以前后处理看上去简单，实则是一个巨坑，同时考虑到CAD厂商的扩张和无网格法的发展，或许在下一个十年之后，前后处理领域已是天翻地覆了吧。

注：Abaqus已被达索收购，且收购之后发展更为迅猛，但祸福相依，后事如何，静观其变。