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

SnowWave02 2023年5月6日浏览：1909 评论：17 收藏：6

（原创，欢迎转载，转载请说明出处）

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

2 总结概述

随着有限元基础理论和Abaqus内部实现方式研究系列的文章的发布，我们每十篇将总结一下我们在开发自主CAE过程中的实际经验和体会，和大家共同探讨自主CAE的发展道路：

（1）自主CAE开发实战经验第一阶段总结。介绍了iSolver开发以来的阶段性总结，从整体角度上介绍一下自主CAE的一些实战经验，包括开发时间预估、框架设计、编程语言选择、测试、未来发展方向等。

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

（2）自主CAE开发实战经验第二阶段总结。iSolver上一阶段主要是技术功能的开发研究，第二阶段介绍自主CAE开发过程中的商业化思维和可扩展、易维护平台的重要性。

https://www.jishulink.com/content/post/1204970

（3）自主CAE开发实战经验第三阶段总结。介绍自主CAE软件的开发目标的初心、市场推广策略和第三阶段iSolver的开发重点。

https://www.jishulink.com/post/1294824

本文为第四阶段，分享自主CAE软件在团队的抉择、产品方向和迭代响应速度等的经验，并介绍iSolver在这个阶段工程案例、前后处理、对标Nastran精度的一些成果。

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

犹记写系列文章第一篇时我们的初衷只是在大家都普遍使用商软不知其内部实现方式的时候，分享一些我们对商软的研究和自主开发的有用的经验，但随着国家慢慢重视自主工业软件，看着现在很多公司的大力宣传，别的软件写的宣传文章风生水起，有时也想是否也拓展一下，把发文章当成真正的宣传为主，但时不时我们都会收到看过我们文章或者直接用过iSolver软件的给我们来信说真的很深入的在讲有限元和做有限元软件，很多朋友都直接跟我们留言希望iSolver能稳点，这时我们总是冷静下来，比起商软来说我们实在差的太远，而且基本所有的算法精度、使用方式等都是商软教给我们的，同时市面上很多自主CAE软件公司也做的相当扎实，我们实在太微不足道，只希望往后还能按自己的节奏沉下心来做有点小用途的软件，同时写点有意义的文章，少点宣传，而是多点对大家学习开发有用的经验，让大家看完一次还想回头再仔细研究一下，对得起哪怕只有一个看我们长篇累牍讨论一个小问题的读者和用户。毕竟再先进的软件也只是暂时的，譬如曾经风光无限的MSC和Nastran如今落寞到几经转手，也许过了不久，达索和Abaqus也同样有此命运。但知识的分享才是永恒的，就像现在我们看的有限元理论基本都是上世纪八九十年代Simo、Bathe、辛克维奇等的书一样。

3 第四阶段工作总结

第四阶段从2020年12月开始到现在为止，这段期间也是自主CAE市场第一波大浪淘沙的过程，2018年自主工业软件刚兴起的时候大批的自主CAE公司或者团队都冒了出来，经过这两年资本和市场的洗礼，大家已慢慢对自主工业软件有了一定的标准来甄别，一方面是自主工业软件的开发者走向市场了解需求，另一方面是市场和资本等变得更加专业来和开发者融合，是骡子是马都不得不拿出来溜溜。很庆幸我们还活着，而且在慢慢壮大，起码现在已经聚焦做自主CAE软件了，不再是以前商软二次开发和自主CAE双线作战了。这段时间主要做的事：

3.1 第一件事：50+工程案例

除了线下的案例，从2021年3月开始，我们陆续在技术邻上发布悬赏，让广大网友们自己挑选工程模型采用iSolver软件进行分析，并至少对比Abaqus、Nasran、Ansys三个商软之一的结果，至今为止，我们收到了50+个案例的应用报告并逐一发表于技术邻上，感谢@饼干树、@Infinite98、@RogerHan0208、@mech、@代进、@南笙781等我们从没见过的ID无私的奉献，我们的软件并不好用，很多案例整理模型和图表明显花了很多心血。每次收到大家发来的案例时就像打开一盒巧克力的心情一样，很好奇到底大家这次会采用什么模型做案例，^.^。感谢大家带来的这种从心底发出的喜悦，我们把这些案例按行业统计列表如下。如需要查看具体的案例，可以直接在技术邻上搜索“iSolver案例分享”，我们的案例的名称都是iSolver案例分享xx（有朋友说不够标题党，起码得大书特书完全自主研发…^.^）

案例号	模型名称	行业	案例号	模型名称	行业
1.	桥梁的模态分析案例	桥梁	26.	欧拉梁单元弯矩计算	机械
2.	标准紧凑拉伸(CT)试样的弹塑性分析	岩土	27.	桩靴的承压测验	海工
3.	理想弹塑性简支梁三点弯曲	岩土	28.	吸力桶的力学性能测试	海工
4.	钢混组合梁支梁三点弯曲	岩土	29.	弹塑性钢架桥梁的模态分析案例	桥梁
5.	龙门架模态分析案例	建筑	30.	压力容器受内压仿真案例	机械
6.	桁架的跃越失稳	建筑	31.	轴承受力分析	机械
7.	内压罐分析案例	建筑	32.	带柄板锚的力学性能测试	海工
8.	三角桁架结构分析	机械	33.	固土圆撑和加强筋构成的地基承载分析	岩土
9.	上承式公路拱桥	桥梁	34	异形支架受力分析	机械
10.	单自由度振动隐式动力学	机械	35	螺旋锚的抗弯性能测试	海工
11.	电连接器端子变形分析	电子	36	人工脊柱受压分析	医学
12.	无铰拱的几何非线性分析	建筑	37	Spudcan的材料性质检测	海工
13.	支架变形分析	机械	38	海上桩的抗水平荷载测验	海工
14.	有缺口工字梁四点弯曲	建筑	39	海上承台自振频率分析	海工
15.	空间站太阳翼桅杆模态分析案例	航天	40	壳单元几何非线性Benchmark校核01	机械
16.	三维刚性壁面圆管声模态计算	机械	41	承力方梁受力分析	建筑
17.	波纹钢腹板简支梁受弯分析	建筑	42	塔架强度刚度建模分析	建筑
18.	一端开放圆管空气声腔声模态分析	机械	43	蜂窝芯子受压刚度分析	航天
19.	开口钢管桩的单轴压缩试验	岩土	44	多螺片螺旋桩的抗拔力学性能测试	岩土
20.	地基中波的传播特性	岩土	45	瑞士兰德瓦瑟高架桥承压受力分析	桥梁
21.	自主化圆柱建模及静力分析	机械	46	真空罐模态分析	机械
22.	铝制易拉罐的单向压缩试验	机械	47	海洋浮式基础受水平风浪荷载	海工
23.	镂空钢板的承压测验	建筑	48	海上吊机承压测试	海工
24.	球面网壳模态分析	建筑	49	机翼建模分析	航空
25.	假肢脚踝受冲击荷载	医学	50	多肋保护框受力分析	机械

3.2 第二件事：增强前后处理的体验感

本以为我们软件最大的亮点是求解精度几乎和商软一致，但出去推广多了后发现，精度只是基础，体验感才是用户最关心的功能，体验感包括很多方面，譬如安装后无法打开界面能不能马上解决，试算一个模型出了问题能不能在两三天内发个新版本解决，还有最重要的是用户界面也就是常说的前后处理的体验感，算法再厉害，如果用户没法操作，对用户来说意义不是很大，但如果做了某个功能用户能马上体验到，用户能马上知道操作的结果就非常流场，譬如加了载荷，马上界面三维区域就更新载荷的方向和加载区域，梁的偏置可以自动一键设置等等。

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

这些看起来很小的问题在实际开发时发现改起来周期都远超我们的预期，我们在以前的总结文章中就说过，前后处理的开发难度要比求解器更难，至于为何难，我们理解有以下几点：

（1）思想上不够重视：前后处理涉及的面很广，这是一个具有非常大门槛的技术，只要你缺少一个环节做不好，就没法实际使用，导致几年内基本看不到成效，而领导们只关心展示效果和核心功能，基本没人亲自点几下鼠标操作一下，导致一方面前后处理很多时候追求高大尚的场景展示，而对如何方便操作得到这些结果不做研究，另一方面除了CAD内核和网格划分外，领导们总觉得前后处理的物理属性等等设置就是个基本的界面编写，毫无难度，没法真正获得支撑，但只有编程人员才知道几十种单元、边界、载荷、材料等等的组合是多么大的数字。

（2）商软模型的兼容性：商软对其它同类软件支持不好，倡导只进不出，譬如Abaqus导入Nastran的bdf支持的很完美，但导出bdf很多信息都丢失，而Patran导出bdf非常完美，但导出的Abaqus的inp调用Abaqus求解器经常计算失败。自主软件不比商软，给别人推广第一个问题都是已有的模型怎么办？看起来仅仅是个接口问题，但实际是个涉及你的前处理关于网格、载荷等数据结构的问题，Abaqus、Ansys、Nastran的db数据内部定义方式有着巨大的差异，自主软件数据内核无论如何做，都只能和其中的一个软件比较接近，而客户往往要求的是你能支持所有的商软模型的导入，这时候如果内核数据结构设计不合理，那么只能告诉用户其它商软没法导进来。

（3）大模型的快速处理：工程模型往往都是几十万网格，如何在单机上处理大模型数据的存储和三维显示一直是个难点，这些都是小细节，譬如Patran对几十万的网格操作就会卡顿，所以它打开大模型默认用线框而不是面显示，Abaqus导入bdf或者inp大模型时特别慢一个原因就是它在打开的同时也在三维渲染，很多人只注重求解器的求解效率，而没有想过有些大模型导入导出文件的时间都可以和求解时间相提并论了。

（4）定制开发和平台开发难以分开：定制项目是自主CAE市场推广不得不经历的一个阶段，对于推广宣传来说，定制项目越多越好，但功能点好加，想要维护或者去掉它就不容易了，而且一般自主前后处理的平台框架都不够完善，各个模块耦合关联过多，很多模块的基础功能都还有缺陷，导致无法将定制部分封在一个小范围内，这些功能点都会直接影响整体的平台，后面功能点越多，越会拖累整体平台，这也导致我们的前后处理每过一段时间都要大范围重构一次，每次重构都需要花大力来保留基于我们原来的功能接口开发的功能。

（5）团队协作困难：前后处理和求解器不同，你可以发现MSC和Abaqus的前身HKS公司名都是由两三个人名的简称MSC（Mac Neal（下图右方）和Robert Schwendler（下图左方））、HKS（David Hibbitt、Bengt Karlsson、Paul Sorensen）组成，而他们公司成立一开始都是只有求解器，也就是求解器可以靠两三个理论大牛开发，可能一个月也改不了几行代码，但只要算法正确，持之以恒的投入研究就可能搞定。前后处理的代码量和工作量都要远远高于求解器，就算是你一行行手工码50w行无意义的代码也要累死，必须要更大的团队协同开发，还包括测试人员、技术支持人员等，软件开发水平往往比力学理论更重要，这需要水平极高的软件架构师和软件开发团队，而无论架构还是在团队协作和管理方面一般自主CAE软件要比大厂差很多，需要更加高效的发挥团队每个人的长处和积极性，还需要保持团队的稳定性起码10年以上。

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

就算除掉CAD建模和网格划分，我们的前后处理比起Patran、Abaqus、Ansys、HyperMesh等商业软件前后处理来说，实在差的太远，连徒弟都算不上，只能算是拙劣的仿照者，但不管如何，起码网上能直接下载试用，有兴趣可以在下方百度链接下载：

最新版和用户手册下载地址：百度网盘链接:

https://pan.baidu.com/s/10d6jHdZ01SBY2JxiS6bffw 提取码: 6fdf

（如下载比较困难，发送至SnowWave02@qq.com或留下email，我们可以单独发送）

有问题依然可以到下面2017年发布的软件主页上留言，欢迎多拍砖，多吐槽：

https://www.jishulink.com/post/337351

3.3 第三件事：增加和Nastran的精度对标

我们以前的结果精度完全对标Abaqus，线性和材料非线性与Abaqus计算结果对比精度误差<0.1%，但在推广过程中，发现在线性问题上，客户只相信Nastran的结果，因为很多工程的校核规范和经验方法都以Nastran的结果为基准，如果换成其它软件，那么那些经验系数和校核公式都可能会修改，而这些修改还需要做大量的工程验证，这是客户承受不了的代价。因此我们软件中增加了Nastran的部分算法，使得一般工程算例和Nastran的误差控制在1%内，主要包括：

（1）增加Nastran的CBEAM梁单元的算法

（2）增加Nastran的CQUAD壳单元的算法

（3）增加Nastran其它细节方面的算法

有兴趣可以查看下面文章：

第三十七篇：梁单元差异（1）-理论基础

https://jishulink.com/content/post/1872208

第三十八篇：梁单元差异（2）-梁截面方向

https://www.jishulink.com/content/post/1874628

第三十九篇：梁单元差异（3）-剪力和弯矩

https://www.jishulink.com/content/post/1876013

第四十篇：梁单元差异（4）-形心、剪心和偏置

https://www.jishulink.com/post/1888000

3.4 第四件事：细节功能完善

用户在实际使用中，必然会涉及细节功能的修改，在此仅列出这个阶段部分细节功能完善：

序号	其它功能描述
1. 分析类型	（1）支持杆的线性瞬态动力学（2）支持杆的几何非线性瞬态动力学（3）瞬态动力学加入力的人工阻尼（4）增加声学边界单元处理（5）支持声学有限元模态分析，包括一次、二次六面体，一次、二次四面体单元（6）支持声学有限元谐响应分析（7）支持惯性释放Inertia Relief功能
2. 单元	（8） BUSH单元支持Cartesian坐标系设定（9）模型有Assembly节点，但该点不属于任何单元，不应该有UR,修复（10） C3D6支持质量阵（11）支持B31OS （12）加入绳索单元（13）支持两点重合的四边形壳单元
3. 载荷和边界	（14）加入shell的edgeload （15）支持Amplitude的载荷（16）支持Amplitude的载荷用于瞬态动力学（17）支持节点既做了BC，又被Kcoup使用时的自动处理。（18）支持C3D20R、C3D20的面载荷（19）支持体的surface traction，包括general和shear两种。（20）支持声压边界条件（21）支持声学加速度载荷（22）支持声模态结果的POR提取（23）进一步修正近似奇异矩阵的求解方式（24）支持稳态动力学的速度边界
4. 约束	（25）自动处理某个set重复约束的问题，按最后一个约束施加（26）支持弹簧单元Spring在Assembly和Instance点之间连接
5. 材料	（27）支持体的复合材料
6. 输入输出	（28）瞬态动力学支持0时刻输出结果。（29）静力问题依然自动输出总质量（30）修改应变各分量和Abaqus一样，但是max principal等值不一样的bug （31）修正主轴应变显示和abaqus不一致的问题（32）支持声学边界元的辐射声场计算（33）输出Set集，支持后处理按set集查看结果
7. 非线性	（34）解决固支约束时收敛准则过严的问题（35）解决Step设置最大迭代次数超过10万次后出错的问题。（36）支持只输出某些增量步的结果（37）进一步修改力的收敛规则（38）支持模型没收敛时报错再退出（39）修正field output的增量步间隔过大导致的bug （40）改进C3D8R的迭代方式（41）修改非平衡力Moment的计算（42）改进几何非线性下线性外插的方式（43）改进非线性下体的沙漏内力（44）改进非线性下壳的沙漏内力（45）修正S4R的弯曲方向的几何非线性（46）优化C3D8R/C3D8的几何非线性下的计算效率（47）提前预判8次迭代后的收敛规律，加速收敛（48）加入平均力的收敛判据
8. 子程序	（49） UMAT支持COORDS参数传入，支持DROT、DFGRD0参数传入用于几何非线性（50） UMAT支持CPS4，CPS3等平面单元的状态变量SDV的后处理显示（51）自定义单元UEL增加对杆单元的处理（52） UEL的SVARS更改节点自由度方式（53）新增DLOAD子程序，接口和Abaqus一致（54） UEL的RHS按每个节点的总自由度分配（55）解决UEL中RNODE3D单元导致无法用abaqus显示问题
9. 其它	（56）解决用户使用过程中的其它bug

4 第四阶段经验分享

分享一些第四阶段的经验，希望对你有所帮助。

4.1 “根基"：团队即软件本身

我们相信每个人都明白团队是自主工业的根基，但很少人有机会亲历从无到有的过程，大部分人还是习惯站在后来者的上帝视角去总结评价，所以也很难有人能够讲清楚在软件发展过程中到底团队本身发生的变化以及这些变化产生的原因和其与软件发展过程的关系。尽管我们的团队在管理和实际运行中仍然存在着很多问题，但我们仍然希望能够给大家分享我们的一些理解，如果能得到各位朋友的一些指导，那就更好了。

首先，我们先从软件的发展过程看对应的团队变化。从一开始的仅求解器开发到如今的整个软件包括前后处理的开发，相应地我们团队也发生了很大的变化。

在仅求解器开发初始阶段，我们团队人员一直维持在5人以内，这可能打破很多人的固有认知，包括我们自身在回顾那几年时也觉得不可思议，尤其我们那会儿还是用业余时间开发的。可以想象，除了几个人的一腔热血、坚持和我们一直仅限于内部交流时自夸的能力，更重要的在今天看来我们觉得是两点：保持快速开发能力的方法和保证性能稳定的手段。保持快速开发能力的方法主要体现在两个方面：1、快速的算法验证，关键点是快速的实现验证所必须的输入准备和输出校验，这有利于降低调试纠错的效率损耗。2、不要迷信任何关于软件工程体系的理论，特别是陷入面向对象和模块化思想的漩涡。软件总是在发展的，再好的框架总会过时，不变的只有变化。我们要借鉴成功的经验，但不能尝试复刻。所以当时我们的开发重心一直在快，并不纠结于代码写的有多优雅。当需求扩展到当前状态无法满足的情况下，那就再重构一下。可能又有点违背直觉，到目前我们重构的次数屈指可数。在开发效率得到保证后，我们最大的隐患就是如何保证软件是稳定可靠的。相应地我们做了许多系统化测试的工作，这一块团队花费的精力并不比开发少，严格按时间来算甚至更多。有点跑题，但我们想说方法和手段再好，能够贯彻执行下来才是好的。这个时候就不得不说当时团队的特点，人少，虽然不是所谓精兵强将，但大家目标、思路和方法高度统一，工作方式更像一个突击小队。

慢慢地借由一些契机，我们团队开始进行前后处理开发，但内部实际是求解器和前后处理两个小组。一开始，我们照搬了求解器的开发经验，仍是以快为首要前提。值得肯定的是，我们在初期基本是一路高歌猛进，很快就有了软件版本。可以现在的眼光来看，那个版本我们是不可能发给任何人使用的，那是一个无法维护的版本。当时，软件版本的特点就是功能丰富但不凝练，甚至于无法满足一个基本流程的分析需求，就像花团锦簇的文章没有主心骨。更要命的是，软件还极为不稳定，崩溃是家常便饭（虽然现在只是好了一丢丢~~）。再回看当时的团队，状态几乎是一模一样，仅仅形式上统一终归是无法形成有效的战力。

经历了近一年的龟速发展，因为一些外部因素，团队内部的两个小组正式合并。顺理成章地，软件尤其是前后处理经历了一次翻天覆地的重构，这项被外部评估为大约需要几十人团队花费一两年的工作，我们团队花费三四个月时间完成了，而这个时期我们团队的人员规模一直在20人以内。现在来看，团队出现问题并不是人增加了，而是目标、思路和方法其中之一不统一了。软件也是如此，问题并不是由新功能或者新需求引起，而是新功能和新需求是否与软件的发展一致。

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

目前我们对团队内部的状态还是非常满意的，但也亟需一些有志之士特别是有推广渠道的朋友合作一起共同成长。我们始终坚信什么样的团队就会开发什么样的软件，对应地看到软件也可以大概地了解背后的团队。很多人都说只要管理到位，团队成员可以随便更换，但自主CAE软件的代码开发在公式编写、精度对标、庞大的代码体系等有其特殊性，代码中很多的设计思想其实是团队成员们有个性的创意体现，很多代码只有原始加上的人才能明白当时为什么这么加，团队成员换人的成本是巨大的，这和基于开源软件难以长久一样的道理。我们不是什么编程天才，只能靠时间堆积慢慢乌龟式的前进，没有每个人朝着同一个目标步调一致的前进，很多年的默默付出，哪来的真正能看得着摸得着的软件实体，可以说团队即软件本身。

4.2 "活下去"：选择带来经济效益的道路

以前自主工业软件无人问津时，一直期望能专注做需要底层研究和代码开发而不得，只能每天晚上和节假日抽时间做，现在国家重视自主工业软件后，申请的自主工业软件的经费按过往的考核指标足够几年内可以让整个团队不用再接外部市场的项目了。照理这个时候我们的团队可以安心几年做底层研究，不用再背负每年经济指标考核的重压了。只可惜现在更愿意走以带来经济效益为目标的道路，相比研发更关注软件的推广应用。两方面考虑：

（1）从软件所处阶段的考虑：现在的基础和以前不太一样了，以前是软件还处于开发阶段，平时正常工作时的商软二次开发和仿真定制项目太占时间，当然希望能静心研究有限元核心算法等，但现在整体软件已经成型，而市场上对自主CAE软件的目标也是做有生命力的商业化的软件，如果做不出商业化软件，静心研究几年团队依然要被市场淘汰，而我们现在的困难点是在推广和应用上，静心研发离我们的目标太远了，只有以争取在市场上的经济效益才可能在有限的人生生命中离这个目标更近一点，当然，还有一种可能是我们太理想和眼界太局限了，自认为觉得照这样发展下去我们是有希望在市场上和商软一起共存的，实际还是蚍蜉撼大树，但无论如何我们也希望往前大踏步的走出去尝试。

（2）从未来发展考虑：虽然研发人员是很想静下心来慢慢打磨的，领导一开始也都是很重视研发的，但如果是CAE这种长期不能见效的，那么一段时间的热度后领导估计又会回到经济指标考核的老路上面，如果你是研发人员，最好理解领导们的决定，不用期待领导们的大力支持，领导能让团队在保证经济指标的前提下按团队自己的想法研究自主CAE就已经是你最大的支持了，如果没有领导的大量人力、财力的支持，那就自己在有限的能力范围内自己去推广，毕竟真正要做实际使用的软件的人是你，真的靠情怀来做事的也只有你。

对于能带来经济效益的项目，一般有两类，一类是宏观的大而全的软件，操作过程尽量一键式，输几个参数就出来一个大模型的计算结果，追求三维模型的宏观展示和给领导们演示，证明自主化。另一类是真的对标商软的一个个小的功能点，把这些功能点都一点点做到界面上，界面看起来不怎么花哨，但追求计算的结果的精度，并对结果的物理含义进行阐述。我们现阶段两者都做，对于只要能带来经济效益的项目现阶段同等重要，但我们的侧重点还是在后者。

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

4.3 "初心"：在定制项目不断打磨产品

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

在市场上，只有区别与商软的定制项目才是客户愿意自主投入，光是对标商软，研究商软再深也是依样画葫芦还是劣质品，深度定制的项目需求才是用户最需要的，很多时候跟客户聊天获得的需求，我们开发出来再给客户一看，离他的想象依然差的很远。在深度定制的过程中不断打磨平台，才可能将平台功能做的更加实用。我们团队已经经历过多年的给商软打工的定制项目，每个定制项目结束后，发现除了对商软二次开发和用户业务模型了解的更深一点外，一直缺乏一个自己的平台去把这些技术应用上去，现在能基于自己的平台做定制项目能不停在平台上积累对我们来说就已经是上天的恩赐了。

定制项目除了打磨产品外也能有两个额外的好处：

（1）锻炼队伍：我们以前接触过很多客户，很多客户的同事之间是有技术壁垒的，不怎么愿意分享经验，但对我们这些没有竞争关系的外行，反而能真心诚意的手把手教我们怎么快速理解他的需求和思路，和他一起完成这个项目，同时，客户本身就是最不讲情面的导师，虽然有时很苛刻，但绝对要比你慢慢研究一个问题更有压力、动力和方向感。

（2）建立客户关系：我们现在推广自主CAE软件很多时候都是找以前的商软定制项目建立的客户关系，既然商软是这个功能需求，那么自主软件也是这个功能，因此，当你想要推广自主CAE时，可以厚着脸皮请以前的客户试试。

4.4 "决心"：版本迭代的响应速度

很多人都说自主软件很难得到用户的反馈，但当你已经时不时会收到用户的使用反馈，有时是bug，有时是新的功能点的需求，这个时候另一个问题就会浮现出来了，就是团队是否有足够的响应速度来迭代修改用户提出的问题，只有版本更新快速迭代才可能真正让这些珍贵的用户反馈对产品的发展起作用，要不然这些反馈就永远是bug管理系统中状态永不更新的记录而已。

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

对于商软来说，商软一般情况下是很稳定的，但有时也会遇到Bug，遇到希望商软修改的地方，这时候你联系了商软，商软处理问题的程序相对复杂，如果有些开发问题，那么必须还要联系国外的开发人员，周期较长，而且还要看你的客户等级，下个版本修改绝对算快的。

商软响应速度慢的一个深层次原因是，底层代码修改成本非常大。软件外在的前后处理功能是很容易修改的，但如果涉及到求解算法或者流程的更改，那么最终还是要修改求解器的底层代码。譬如现在市面上的结构显式动力学软件基本都是从DYNA3D这个原始的代码修改过来的，但你要是看过DYNA3D的代码，可以发现无数难以理解的地方，函数简写后很难猜测简写后的命名规范，很多变量名从A00一直到A50，输入参数的起始位置的关系相当的复杂，而NASTRAN的代码一看就有许多Fortran语言刚刚产生时代的影子，语法明显和Fortran77不同，同时为了适应当时有限的硬件条件做了许多限制内存开辟空间的功能。而Abaqus的单机节点数也限制在2千万以内，否则就会出现模型Size过大的问题。

对于这些底层代码，加任何新的功能都是极其困难的，也许这也是近十年内结构商软的算法没有大的改动的一个原因，对于基本的线性、模态等问题，10年前的计算精度和现在完全一致，也就是虽然这10年全世界的试验室用软件做了大量的更多的例子，但软件本身的精度一致没有利用这些试验结果改进。

说了这么多商软难修改的问题，其实自主软件更是问题多多，但有些方面的改进还是能很大的提升团队的响应速度的：

（1）重视平台的扩展性和易维护性。在第二阶段经验总结中，我们就指出一个可扩展、易维护的软件产品平台是软件需求->研发->反馈->更新这个良性循环的必备条件，研发人员往往会提出影响平台整体框架修改的建议，但面对客户的售前和实施人员总是希望平台不要大改影响进度，除了产品负责人权衡外，自主软件总是有很多问题的，在自主软件推广阶段可以不用把人员分为实施和产品研发，客户那边出了问题平台开发人员需要到第一线去解决问题，了解真正的客户需求，面对客户的压力，调接口的开发人员也可以在家安心编程，这样双方都能为对方考虑问题。

（2）重视开发时的测试和版本发布时的场景预演。很多软件管理人员都强调高效的用户反馈机制和版本发布的流程，按开发人员：测试人员为2:1的比例来配测试人员，只可惜自主软件比不上商软，真正开发的人员很少，测试人员更是有专门的就已经不错了，这个时候比起规范的测试流程和机制来说，重视下面两个问题可能来的更实际点：1.开发端的测试，按开发人员发现问题->测试人员发现问题->用户发现问题的过程，越往后bug修复问题的成本也越大，尽量把问题暴露在开发人员那头，开发人员多测试，实际情况是开发人员总认为自己是没问题的，或者开发人员总认为测试不是他的工作，是测试人员的责任，这种思想上的觉悟我们也没找到好方法，除了每次跟开发人员说强调测试完，就是产品负责人带头测试，让下面的研发人员明白软件质量的重要性。2.让每个开发人员和测试人员都明白这个新版本发布最终要解决什么问题，因为每个开发人员和测试人员可能只测试小的功能点，但客户需要的是这些小功能点连在一起的流程，譬如用户需要支持重力载荷，结果开发人员做了一个简单的界面加重力载荷的例子算对了就以为OK了，但版本发出去后发现用户用软件时没有新建，直接导入已有的一个大模型的bdf开始计算，结果发现不支持导入bdf中的重力载荷，同时大模型由于单元集的复杂形式前后处理的内核数据也有bug。这就需要所有人都能理解到用户如何去使用这个功能，在心里能模拟出用户的使用场景，每个人都把这个场景流程走一遍，不到最后的结果正确前都认为是错的。

5 "用"-下阶段的工作重点

现在，自主CAE的公司已不像2018中美贸易战时那么多的如雨后春笋一样冒出来了，照这个趋势来说，再过个两年，工业软件也不会像现在这么热门了，对我们这样更多的以经济效益为考核指标的团队来说，就是生和死的问题了，以前靠的是兴趣，使得团队能坚持“白天做商软二次开发，晚上做自主cae软件”，但现在如果回到以前给商软做二次开发分点经费的境地，整个团队还能不能很好的继续静下心来开发自主软件就有很多不确定性了，因为并不是每个人都是靠兴趣做事的，毕竟先要保证养家糊口才有可能抬头看到自己是不是因为兴趣而码代码。对我们来说，唯一的突破点只有乘着这两年有国家项目和零星的市场采购的时候把自己的软件做到实用，真正的取代商软，到时自主工业软件不是必选项时靠功能和价格也能在商软的世界中分一杯羹。

因此，我们下阶段的工作重点依然是“用”，只有以此为目标，才能梳理整个功能点的先后顺序，以用户操作软件的思维去开发，跳出软件编程者的固有思维，当面对一个功能达不到商软的精度或者操作非常复杂时，就知道做了用户也不会用，同时，界面上再花哨，但用户使用时，当你的精度和功能使用达不到他要求时，一点意义都没有。同时，真正的用户压根不关心你的软件是不是自主，而只关心功能能不能满足他们要求，有没有license限制，至于你的网格划分引擎和三维显示引擎是否购买了商业的开发库，他们不关心，只要卖给他们的时候没有产权纠纷就行。去关心功能的用户那边推广软件时会很明显的给平常关心自主化的领导那边汇报不同。我们在推广过程中已经遇到了很多次这样实际的情况。有时我们刚坐下来准备找PPT时，下面的用户就直接说了能不能把软件打开对着软件介绍。还有，本来准备了10分钟的按部就班的演示，实际操作了足足3个小时，用户完全不会按照你准备的演示流程问问题，只会问他关心的问题，回答一个问题也只有两种方式：要么说暂时还没这个功能，以后准备怎么实现，譬如Nastran中的湿模态的计算方法暂时没有，以后准备用现有独立声学边界元的单元怎么扩展到声振耦合来解决湿模态的问题；要么你就回答有，然后用软件操作当场证明，譬如和Nastran的精度误差多少，然后用软件算一个实际模型，导出模型到Patran中，直接再算一个模型，对比精度，证明你的位移误差是1%内，同时说明应力差异并不是本身求解器的问题，而是我们的软件和Patran后处理的节点应力平均方式不同而已。还有听说你讲的时候说能同时无缝导入Nastran和Abaqus模型，然后当场拿个U盘拷个你完全不知道是什么的bdf模型给你电脑，对着开会的投影看你的软件是否真的能导入成功，所有人注视着屏幕看你的三维显示那边会不会出现他的模型。不管如何，这些实际用户的需求才能真正促进我们软件的进步。