谈谈利用开源代码来编写求解器

refeihc

一、初谈开源软件与求解器

仿真论坛的“有限元理论及其数值方法”版块新设置了“求解器/误差”这样一个子版块，不想让它空着，就开个头谈谈利用开源代码来编写求解器吧。

求解器相当于有限元软件的引擎，其意义不能轻视。我知道国内有许多人在编写有限元程序，但是做了大量的底层重复工作，其中就包括自己写求解器，内容涉及：求解线性方程组、特征值、广义特征值和奇异值分解等。

求解器的开发最好是能站在更高的起点上，利用开源的求解器程序包，是一个值得考虑的想法。首选的开源程序包应该是Lapack/Blas，大家可以上www.netlib.org/lapack/index.html免费下载这个程序包。它是基于Fortran编写出来的，以后又有了Lapack++，本质上是给Lapack赋了一个C++外壳。不过，也有人推荐面向对象的MTL，我曾经试过，感觉不太好用，主要是MTL的矩阵类很不便于进行跟踪调试，原因是它的类派生较多采用宏语句（或者是我没能理解程序设计者这样做的精髓）。另外就是MTL很长时间没有发展更新了，也能够理解，毕竟开发面向对象的矩阵类是一个很有难度的工作。Vector类目前都能做得很好，但Matrix类就很难做得好，主要原因大家都明白，就是矩阵的属性太多太多，程序设计者总是想让大家在处理矩阵时，既能像Matlab那样方便，又能针对不同的矩阵属性进行处理而不失效率。

今天先说到这里，且当开个头，期待抛砖引玉。

（继续谈）
二、如何评价数学软件包
兵法云：多算胜，少算不胜，况无算乎？用兵打仗如此，科研何尝不如此。

当美国人开始意识到靠理论研究与实验研究两条腿走路的传统科学技术，在未来将要有第三根支柱——计算科学——来支撑的时候，他们静悄悄地努力了五十多年。而当他们认为已经把竞争对手远远甩到身后，取得巨大的领先优势时，于是在2005年抛出了一份报告《站在风暴之上（Rising Above the Gathering Storm ）》，这份报告重点阐述如何继续保持美国的领先优势。

我们今天已经知道计算科学对工业和经济发展多么重要，但是我们国家至今仍拿不出一个能和ABAQUS、ANSYS、LS-DYNA等叫板的有限元软件，更不用说挑战Nastran的有限元领袖地位了。当美国人还杞人忧天似地担心别人超过他时，中国的软件开发者还是一团散沙，无奈地只能是觉得皇帝不急太监急。

如果说工程科学领域是苦海，那无数的计算软件就是船，而有限元软件一定是旗舰，而旗舰的核心就是求解器，它的要求太高了。

国内有不少高校，都有人试图开发有限元软件，但前期准备工作太仓促，通常起步就定下宏大的目标是商业软件，而且还要求低投入、速成、不求好、先要有，开发队伍通常是“一个大和尚带几个小和尚”，不少研究生可能是刚刚开始学习有限元理论和程序设计，这样开发出来的软件大多无疾而终，根本形成不了竞争力，白白浪费了大量的人力财力，弄到今天基金委、科技部等部门已不爱理睬软件开发类的项目申请了。

这个版块上的朋友相信都会有一个梦想，就是有我们自己好用的有限元软件。苦于现实不如人意，只能使用国外的软件，奈何又囊中羞涩，不得不使用D版软件。

我们今天对国产的有限元软件发展状况不满意，但不妨碍我们来讨论如何发展，只是有限元软件这个题目太大了，本人的能力不够。就勉力谈一下求解器吧，首先要涉及到的就是数学软件包，Lapack只是一个数学软件包，而评价一个数学软件包，必须要有科学的方法。我觉得有几个要素：优良的结构、理想的效率、良好的稳定性、良好的可维护性和可扩充性、严格的检验过程、全面的综合评价过程、强有力的专职研发队伍支撑。我能想到的就是这些！这些要素不是割裂开的，它们紧密相联。

(一) 结构方面
首先看看数据结构，矩阵的存贮方式必须经过认真的研究，Lapack这一方面做得比较好
  1 一般矩阵就采用Fortran和C的数组结构；
  2 上下三角矩阵有2种格式，一是普通型（为全矩阵申请空间，但只用一半，另一半浪费着），二是紧凑型（只为三角部分申请空间）。前者引用元素方便，后者最大限度的节省空间；
  3 带状矩阵引入上下半带宽各一个属性，存贮方式也有紧凑型和引用高效型，前者不浪费空间，后者方便引用。
再来看看Lapack的整体系统结构，它的1千多个子程序进行了很好的层次分类组合，每个子程序的命名（按8.3格式）有严格的约定，变量的命名有统一的规范，这些是高性能的前提保证。

(二) 效率方面
再来看看Lapack是如何重视计算效率的，国际上有人结合现代计算机特点专门研究过矩阵计算如何提高效率，认为要注意许多地方，如恰当的循环层次设计，优化的数据移动方式，双精度与单精度处理上有所区别，64位和32位也要区别处理，通过编译选项控制提高计算效率，通过寄存器变量的使用提高效率，重视机器硬件的影响和操作系统的影响等。

这里解释一下，恰当的循环层次设计是指当有多层循环时，循环变量谁先谁后的问题；优化的数据移动方式是说矩阵运算元素如果一个一个地依次访问，效率并不高，而应该是成批地提取连续存放的数据，但是如何达到最高的效率需要研究；64位和32位机器的底层算法对于浮点数运算是有区别的，双精度和单精度也一样有这个问题；编译选项的控制有助于得到优化的代码；寄存器的寻址速度无疑高过内存，合理的利用也有助于提高效率；不同的机器硬件配置以及CPU的性能对计算的影响会有不同；不同的操作系统如win系列、*nix系列等下的计算效率都会有不同。

上面说的这些方面对于求解器的效率是极为重要的，因此必须加以关注。但要做到这一点极不容易，单凭一两个人是肯定不够的，应该依靠一支跨学科组成的队伍，我们国家应该说不缺乏人，但是缺乏战略、政策、组织、理解和支持。对于Lapack我能确认它有部分方面注意到了，但是不是所有的方面都做得好我了解不够，因此无力评价。

在我国已有不少数值算法的书问世，有些书堪称是精品，有的作者提供了相应数值算法的程序代码包，不少还能从网上下载。这些代码如果是我们的研究生自己算一个小问题或是编一个小软件还够用，但一旦要成为有限元软件的核心就力不从心了。原因在于，这些代码可能仅仅是在数值算法的层面上考虑了效率，而结合编程语言特点、机器性能、操作系统环境影响等方面基本上没有考虑。更有甚者有些书作者可能是为了出书而出书，书中配的程序质量实在是粗糙，甚至校稿不严使得程序中存在语法错误而贻害于人，此时已经远远谈不上考虑计算效率了，能不出错就是万幸。

另一方面，关注计算效率又是一柄双刃剑，不能过份地追求，全部用汇编语言或是机器指令编程开发的软件其计算效率应该是最高的，但对于有限元软件来说那是不可想象的。有限元软件的效率是一个大概念，不仅结构计算要重视效率，软件开发、维护、更新、技术支持等方面都要重视效率。因此程序系统的模块性、可读性、可维护性、可扩充性要想得到保证，有时又得牺牲一点计算效率。这使得求解器的开发充满了矛盾，要兼顾到方方面面，还要提前考虑好未来的发展。

(三) 稳定性方面
稳定性有不同含义，一是软件运行稳定，不要在计算时发生异常而崩溃；二是初始条件对计算结果的影响不要发散。后一个问题涉及到微分方程数值解法，不属于这里考虑的问题，前一个问题要在设计求解器时格外小心。纯计算机专业出身的人（或其它专业出身但有全面的计算机素养的人）对系统方面的稳定性问题有天然的敏感，如内存的申请异常、权限的限制、函数非法调用等。计算数学和计算力学专业的人会对另一类问题格外小心。比如在用消元法求解方程时，如果遇到奇异或病态矩阵，就容易出现被零除；模态分析时如果存在负刚度，就会出现负数开平方等，这些问题不可能完全避免，但求解器应该有容错的能力，对可能出现此类问题的地方预留处理方法。但这又不等于说，就让这三类“计算”家族的人来开发求解器和有限元软件就行了，因为可能造成这些问题的根源，估计是工程专业的人更清楚。这一方面Lapack做得如何，我没有去全面分析它的代码，所以不能评价。

(四) 可维护性、可扩充性方面
可维护性和可扩充性的要求也可说是深谋远虑、高瞻远瞩，这是一个大素养，放在求解器里可以包含（但不仅仅是）这么些内容，如现在能处理的矩阵属性有哪些（如一般、上下三角、带状、对称、正定等），它们的存贮是按什么方式？以后打算新增的属性（如一维变带宽、稀疏等），现在采用的方法有直接法，以后还要引入迭代法，各种内容又有相互交叉组合，即要方便编写程序，又要能处理各种属性，还要保证效率。做到完美是不可能的，但是要求越来越好。

我认为Lapack目前做到了在它所处的这个层级上成为世界上最好，经过长时间的性能检验，现在它需要维护的地方已经比较少了。而别的程序可以方便地和它接口，扩充的潜力巨大，另外它专门有一个论坛，为全世界的用户提供咨询服务，同时任何人发现bug都可报告，这些是长久健康发展的潜力。

(五) 其它方面
严格的检验过程和全面的综合评价过程是指对开发出的软件包，不能只是草率地算几个题目就OK了，而要进行严格的全面的测试、比较、评价。而强有力的专职研发队伍是要求有一支正规军，而不是游击队。Lapack的研发队伍不用去考察，一定是强有力的。

客观的说Lapack未必在所有方面都做得好，从这个链接http://www.netlib.org/lapack/lug/node1.html可以看到它曾经做了些什么，我没有仔细看，相信一定是不够的，但我仍然认为它做得比其它的好。打个比方，我们有时去餐馆，往往找人最多的那一家，因为我们知道人气能说明问题。看看目前多少著名软件的求解器建立在Lapack之上，就知道它的份量了。

说了Lapack不少的好话，也鼓励大家使用它，是不想让大家开发程序时在底层费太多力。当然如果是想学习数值分析算法，自己练手编程，那又另当别论。

今天先写到这里。


三、初步认识开源
金庸语：侠之大者，为国为民。然而当今之世，更有甚者，可谓博爱世界。

世界上的人真是千奇百怪，有人高价研发软件然后卖个好价钱，也有人热心公益事业，推出开源软件。

几年前，我开始接触Berkeley的一批人开发的开源有限元软件OpenSees时，发现它的求解器基本不是自己开发，而是用了Lapack、UMFPack、SLU等开源数学软件，这引起我的兴趣。

随后发现许多知名软件如MATLAB等都不同程度地利用了开源数学软件包，甚至于ANSYS和ABAQUS都分别要采用开源的Tcl/Tk和Python来实现基于脚本交互的shell，人们都知道上面提到的这些软件是要花钱买的，其中有限元软件是天价。

让我惊奇的是这些有限元软件声名显赫，却能放下身段使用开源软件包；让我鄙视它们的是，这些软件成百万元地卖给用户，却心安理得地免费使用开源软件；最让我惭愧地是，多年来，我们一直是傻乎乎地自己编写底层的数学计算程序，编得不好且不说，经常是东补西添，弄得程序结构丑陋不堪；不过虽然惭愧，还是有一些理由让我能够阿Q一把，因为在我的工作经历中，曾有机会接触过日本人开发的一套挺不错的有限元软件源代码，我知道它也是自己傻乎乎地做底层开发。此外，我还和许多国内外的人交流过有限元软件方面的问题，知道同样傻的人还有很多，国内国外总有一批人要将犯傻进行到底。

“实迷途其未返，觉今是而昨非”，既然知道自己傻了就不能再傻下去。马上面临的问题就是：怎么会有开源软件，开源难道不是很傻么？带着好奇去深入了解、分析和思考，就有了更多的认识。我发现美国从事软件开发的一批高端人才堪称具有大智慧，他们有些很强的地方值得我们真心佩服和学习，那就是：视野开阔，成全强者，分工合作，各逞其能。

视野开阔是个模糊概念，在国内有许多杰出的学者不仅学识丰富、更有远见卓识，让人十分佩服。我以为能达到这样的境界，既有自身努力，凭借多年闭门苦读，还需要有很高的立足点，和很不平凡的阅历，这表明中国人的视野开阔比较依赖个人修为和机遇。

美国人的视野开阔是和他们的理念、氛围和环境有关的，就拿学术活动来说，沟通、交流、讨论、争辩等行为如果不能成为他们的常态，那就一定有足够的环境来开展这些行为。而且在进行这些行为时，良好的氛围能使他们的心态更为开放些。因为心态开放，所以能坦诚交流，因为有环境进行交流，所以能获得开阔的视野，也就不奇怪他们能看到山外青山楼外楼。正是凭借开阔的视野，他们想不认识Lapack等开源软件包都难。

当他们意识到Lapack的强大后，下一个举动就是成全强者，向它靠拢，站在它的上面。请注意Lapack是开源的，但没有听说谁把它的全部代码改换一下头面，然后变成自己的。或许也有人想这样做，但一方面有效的法律制度能起到保护的作用，另一方面，代码只是形式，其中蕴涵的研究是任谁也窃取不走的。因为这样的原因，Lapack也敢开放自己，不用担心失去知识产权。

当他们向Lapack等数学软件包靠拢后，就会有一个分工，数学计算这一部分抽象出来，由从事数学软件包的人来专门负责完成。但相互之间商量好数据格式、调用约定，这样就形成了一个良性互动，彼此能够扬长避短。熟悉数学的人去研究方法，精通电脑的人去关心效率，什么都不擅长的人也有用武之地，就是去测试，整理数据。而有限元软件这一头的人，则从底层解放出来，有更多的时间精力去创新。他们都明白一个道理：世界上的人不可能有通天彻地之能，安心做好自己份内的事才是最要紧的。

最后获得的结果就是各逞其能，各方都皆大欢喜。

看了我上面提到的这些内容后，可能会有人迫不急待地就要上了，马上使用Lapack，开源的东西要用大家都用。

别忙，马上就有一个问题是大意不得的，那就是：用什么和怎么用？

改天再写吧！

refeihc

感觉开了一个很大的话题，有点欲罢不能了。就在这里做记录吧。

5月10日开了一个头。
5月11日说了些Lapack的好话。
5月12日谈对开源软件的认识过程，并整理了帖文的结构。
5月13日讨论了开源软件协议，并宣布暂停一阵子。
5月14-16日停了几天。
5月17日讨论稀疏存贮格式与迭代算法。
5月21日谈ublas在统一数据格式方面的尝试
6月3日谈“豪华老爷车”与“后发优势”

caoer

lapack非常不错速度很快，支持lz继续撰写。

tonnyw

You might try the following one. I feel good about it.
http://www.hsl.rl.ac.uk/index.html

refeihc

谢谢tonnyw，我在开始关注数学软件包时，进行了大量的搜索，这个我以前搜索到过，但因为它的开源方式友好程度不够，主要是它的协议不是BSD之类的，所以没有进一步了解它。

相信它也是很不错的，应该能够自由地用于学术研究。如果tonnyw有心得，不妨介绍一点吧。

refeihc

提示：一楼有新内容时会补充，二楼介绍进展。

zsq-w

打个酱油，顺便贴上lz提到的Rising Above the Gathering Storm

flylin

楼主不错，我也是做有限元开发多年，也想过用开源的来做，但苦于找不到队伍啊。

pasuka

看了lz的文章，真忍不住发笑了。。。
Lapack/Blas在20世纪80年代就基本定型了，袁亚湘翻译的戈卢布《矩阵计算》可以看做是lapack算法原理和程序使用的说明书。
Intel的MKL和AMD的ACML很早就集成了Lapack，且附带详细的算例和帮助文档。
Matlab最早的设计初衷也是帮助学生方便使用Lapack进行科学计算
对于用C/C++、Fortran编程搞科学计算的连lapack/Blas都不知道，也太joke了吧？
UMFPACK、SUPERLU、ARPACK、MA47、MA57、EA16这类开源求解器还不能满足要求？
在没有项目经费和明确应用背景的情况下，自己写求解器还不如用用成熟的开源求解器实在。写上述开源求解器的人，基本不是
计算机科班就是应用数学科班出来的，来simwe论坛的怕是机械和力学居多。自己DIY一台电脑，知道CPU工作原理即可，难道
还要自己DIY一个CPU不成？
又，稀疏矩阵存储格式，等带宽、一维变带宽已经不能满足科研和工程需要，压缩行、压缩列等等有很多效率更高的存储方式。

refeihc

8# flylin

谢谢鼓励，写的只是一点心得，希望大家能多交流。

refeihc

9# pasuka

谢谢9楼，虽然感觉说话有些张扬，但所说内容没有本质的冲突。而且9楼的回帖从另一个方面进行了补充，文章也还没有完，希望后面继续关注、建议、讨论和补充。

另：有一建议！
(

对于用C/C++、Fortran编程搞科学计算的连lapack/Blas都不知道，也太joke了吧？

)
目前，用C/C++、FORTRAN编程搞科学计算的人中，不知道Lapack/Blas的大有人在，即使是计算机科班和数学科班的人，甚至于是专攻矩阵计算的人也有不知道的，我们不好因为自己知道了一些，就joke，相反把自己知道的写出来，发在这里，让更多的人了解学习，并与之交流讨论将更有意义。

希望你更详细地介绍一下压缩存贮格式，我会为你鼓掌。

pasuka

中英文各贴一篇，仅供参考，反正原理都是非常简单易懂的
至于在有限元计算中采用哪种存储格式，具体如何实现，八仙过海，各显神通
11# refeihc

hillyuan

Agree with pasuka. You really need NOT to program a new linear solver if you are not a specilist in mathematics and DO have some great idea in a new algorithm or some idea to greatly improve the efficiency of  parellel computation.

You have much choice and most of them are great. Pls refer to http://forum.simwe.com/viewthrea ... ghlight=%2Bhillyuan
although it is quite old now.

caoer

一些基本的道理可能大家都懂都理解，能将知识整理出来并形成文字，还是需要很大力气和对问题的理解的，这不仅仅是对问题某个方面的片面理解，我很支持lz继续撰写，希望回帖评论的朋友以一种平和的心态来讨论来回帖，尊重他人的劳动，也会受到别人的尊重。

构造 和谐 的讨论氛围，是A60最长远最终极的目标，可以让所有的朋友们在这里畅所欲言又不伤和气。

如果有哪位牛人能将PETSc像refeihc前辈那样成文一篇，我给3个积分，金币另算。

bbssbb

支持版主，
术业有专攻，大家的背景不一样，看待问题的角度不一样很正常。
能把自己的想法整理出来，对自己也是对别人都是非常有好处的。

refeihc

四、不得不关注的开源软件协议
白玉堂前春解舞，东风卷得均匀。蜂团蝶阵乱纷纷，几曾随流水，岂必委芳尘。万缕千丝终不改，任他随聚随分。韶华休笑本无根，好风凭借力，送我上青云。一首《临江仙-柳絮》中最让人回味的是后一句。

柳絮虽轻能高飞，只缘借力凭好风。借力的想法是不错，可是得要“好风”才行，万一不能“风”遂“絮”意，就有可能将其吹成“癫狂柳絮”，甚至是“送上西天”，结果反而不美。

开发软件同样可以借力，这是一项投入巨大的工作，方方面面的要求又极高，如果能尽可能高地站在已有的平台上，必然能收到好的效果。但风怎么样呢？这里需要关心一下开源软件的协议。

不同的人使用数学软件包的目的不同，有的是为了学术研究中更高效地计算一些问题，有的是为了开发软件自己使用而不是出于商业目的，还有的纯粹是为了开发商业软件。

如果是前2个目的，那可不理会这一节的内容，如果是为了开发商业软件，那就要首先了解一下开源软件协议，几乎绝大多数开源软件是对使用者有要求的。

目前我了解到有这么几种协议类型：
(1) BSD开源协议（original BSD license、FreeBSD license、Original BSD license）
(2) Apache协议
(3) GPL（GNU General Public License）
(4) LGPL（GNU Lesser General Public License）
(5) MIT（MIT）
当然也有的开源软件单独拟定一个协议。

GPL协议限制使用者将开源软件用于商业行为，要求基于GPL开源软件所开发的软件也必须是GPL类型的，而不能是闭源的，这就是所谓的传染性。而LGPL则稍有放松，可以通过类库引用方式使用LGPL开源软件。而最友好的是BSD类型的协议，我对它的理解是，只要你不把它据为己有，在你发布的软件中声明对它的使用，就可以为所欲为地进行商业软件开发。

Lapack软件的协议是独特的，它对使用者的要求简单到只要引用它的一本使用手册就行了，Blas的协议我找了好久没有发现有相关的文字内容。但是许多著名的数学软件包，要么是闭源的，要么协议限制你为所欲为， 于是，我要为Lapack再说一句好话“它在协议上对使用者友好”。

另一方面，Lapack还对非Fortran类的语言提供了支持，如已有的Lapack++、CLapack等，大家有兴趣可以自己去查。特别要提醒的是，如果是采用C++编程，最好不要通过混合语言编程的call F from C/C++方式来调用Lapack，因为不同编译器的命名约定可能会带来麻烦。

Lapack在处理一般、对称、三角、带状，正定矩阵方面是很理想的选择，我建议大家使用它，而不要自己再低水平重复开发，即使付出很大的代价，也难以达到它的水平，更何况我们无须任何代价就可以得到它的全部代码和基本自由的使用权。

不过它不能支持稀疏矩阵和变带宽矩阵，因此，有必要寻找其它的软件包，经过比较我们又找到了SLU（SuperLU）系列和UMFPack。其它应该有一些基于Fortran的软件包，不过我们当时还要求所有的数学软件包要能和boost numerical bindings连接，所以好多都最后从后选名单中删除了。

但是UMFPack的协议不是为所欲为类型的，记得5.0版是LGPL，后面又成了GPL协议。不明白它为什么要这样折腾，或许MATLAB对它始用终弃就是因为这个原因吧？另一个问题是UMFPack的编译，在Windows下比较麻烦，最后是通过cygwin+mingw才编译成功。

如果追求快速稀疏矩阵计算，又不是出于商业目的，建议用gotoBlas来替代Blas，这是一个Blas的高速实现，可以在sourceforge上找到它，不过要记住它严格限制只能用于学术目的。

refeihc

附几句题外话
就这么断断续续地写，引起一些朋友的关注。这里要特别感谢caoer和zsq-w的鼓励，你们对有限元的痴迷感染了我，才有动力写这篇帖子的。还有楼上各位的跟帖，也是动力的一部分。不管是赞同或是异议，表明这个问题的讨论是有价值的，我会努力地继续下去。

有些朋友可能误解了我的意思，以为我是打算自己搞一个数学软件包，于是表示不支持重复开发数学软件包，甚至有些激动。

其实“不支持重复开发”就是我的想法，我们在这一点上是完全一致的，大家都深知低水平重复是软件开发的大忌。平时见到周围不少人要么用MATLAB，要么自己重新写矩阵计算的程序，但是当我向他们建议使用开源软件包时，几乎得不到响应。现在发现竟有许多志同道合者，内心感到十分欣慰，在此向各位提建议者表示感谢，我很高兴这样的讨论。

另外，写这篇帖子的事情得要停一阵子，正在准备参加一个国际会议，还有一些工作压头，过一段时间再写吧。

refeihc

谢谢12楼提供的介绍稀疏矩阵存贮格式的文章。

英文的那篇感觉和现有的研究工作有一些重复，可能它们也要独立开发软件包吧，但愿不要低水平重复。中文的那篇感觉意义一般。

我建议你关注一下wiki百科和SciPy，前者信息更新及时，后者已有比较全面的实现。

refeihc

Agree with pasuka. You really need NOT to program a new linear solver if you are not a specilist in mathematics and DO have some great idea in a new algorithm or some idea to greatly improve the effic ...
hillyuan 发表于 2010-5-12 21:03

看了你在2005年发的那篇帖子，感谢你提供这条线索，5年前的内容今天已有许多更新，不过它们仍然存在。

类似的内容以前在不同地方见到过，很希望这方面的介绍不仅涉及软件包的功能，也涉及开源协议的类型，如果你能整理一下，应该对大家更有益。

另外，推荐一个比较新的uBlas，应该是为面向对象开发数学软件包准备的，它目前正在进展之中。

bbssbb

高效的求解器一直是有限元爱好者梦寐以求的东西，不过以本人的经验，
当前基于pc机的线性方程求解程序包还没有特别令人满意的。
本人遇到的问题和求解器现状：
1. 使用行压缩或列压缩存储刚度矩阵是必需的，对于超百万自由度问题，内存空间上能省则省。
2. 直接法求解可以直接放弃，如果求解一次都要用小时计，算非线性或多尺度问题会是一个噩梦。
3. Krylov迭代法很有前途，不过需要合适的预处理，非常不具有通用的计算效率，尤其是当计算摩擦接触等，刚度矩阵条件数不好的时候，这类方法表现得很不好。
4. 多网格法，对网格和求解问题的限制太多，根本不通用。
我所期待的有限元pc机求解器：
1。具有通用性，可解对称，非对称，半正定，受条件数的影响较小。
2。具有迭代法的效率。
如果有这样的求解器存在，请各路数值线性代数的高手一定告知。