有限元理論基礎及Abaqus內部實現方式研究系列11：自主CAE開發實戰經驗第一階段總結

SnowWave02

瀏覽：5728 評論：11 收藏：3

（原創，轉載請注明出處）

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.yqgqt.org.cn/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已被達索收購，且收購之后發展更為迅猛，但禍福相依，后事如何，靜觀其變。