另外，这个帖子写的进度慢了许多，主要是最近到了学期末，事情比较多，按我的计划还有5~6节要写，避免虎头蛇尾，所以宁可慢一点，也不想草率。
请朋友们理解。
恩，支持refeirc慢慢写，精品都是这样的。
还有个建议，这么好的文章，完成后能不能投给期刊，我觉得可以做封面文章了。
本帖最后由 refeihc 于 2010-6-3 15:42 编辑
七、“豪华老爷车”与“后发优势”
十年流落负归期，临水登山客有思。今日樽前千万恨，不堪频唱鹧鸪辞。王安石当年曾轰轰烈烈地干过，但变法终未成功，或许这首诗表达了他内心的愁苦。不过我想说的是，对于今天中国的有限元软件事业，诗中的情景几近相似。
我国的有限元软件开发多年前就开始尝试了，曾几何时老一辈专家怀着登高山必自卑，扬远帆必自迩的心情，慨然启程，虽然竭力打拼，但十余年流落，如今能在市场上有卓越表现的高质量大型软件系统依然难觅踪影，岂不让人怅然有思。
再看国外十多年过去，又出现了许多新的变化，只要看看这个论坛上新出现的那么多的软件名称，就知道一大批后进软件已然进入市场。但和十几年前一样的是，目前仍然没有谁有能力在通用软件市场上撼动龙头老大Nastran的地位。总体上看，我们不仅没有缩小差距，反而更落后了。
有限元理论经过五十多年的发展，取得了丰硕的成果，造就一批通用有限元软件雄霸于高端市场，这些软件或成为标准，或垄断某个行业，或占据大的份额，不容后来者超越。其卓尔气势，让我等艳羡不已。在这样的背景下，任何人都能意识到，中国的差距很大，路很漫长，差距不仅在于研发和技术方面，还在于政策、法律、观念、传统等许多方面，一想到这些，许多人会很灰心。
难道真地只能“樽前千万恨，频唱鹧鸪辞”吗？其实，我们大可不必灰心，更不能丧失希望。我相信那些大牌软件公司的担忧和压力比我们要大得多，因为他们很清楚的一个事实就是自己做为一个曾经大名鼎鼎的软件，到了今天已成了“豪华老爷车”，我这样说是有根据的。
几年前，我们的研究工作中要进行一些前沿性的分析计算，需要的计算能力在当时是已有软件提供不了的。当时考虑着如何解决这一问题，研究后认为最快捷有效的办法是基于通用有限元软件进行二次开发。于是我们对当道的一批有限元软件进行了筛选，并考虑了其在国内的服务质量和技术水平，最后选择了各方面实力都很强的一家，并与该公司驻中国机构进行了联系，对方也同意提供技术支持。最初的经历表明前景很看好，选择的软件声名显赫，功能完备，还有良好的用户扩充能力——二次开发。二次开发什么都能做，自定义材料本构、自定义单元、自定义求解器、底层数据访问、全方位的接口、计算过程干预、挂接外部库文件等，甚至可以让你把通用软件吃进去——成为用户程序中的一个可调用模块，还有什么不能满足你的呢？因此没有理由不乐观。
然而随后的工作困难重重，一些典型困难如：
(1) 你明明有很好的程序设计方式，偏要受制于Fortran77。
(2) 很原始的DOS运作方式，包括编译、链接、调试和运行，造成很低的效率。
(3) 范例代码中经常出现不明的变量、数组和函数名，没有注释，手册指南中也没有介绍。
(4) 手册中对一些功能函数的介绍不完整，有时漏掉几个参数的说明，使你无法知道这些参数用来干什么，是标量还是数组，当然也就不能用这些功能函数了。
(5) 用户能得到简单一维问题的例子，但是如果是更高维问题，关键调用接口不知道是什么，手册中也不介绍。
(6) 有些历史或状态变量的数目有限制，对你加以限制。
最让人无奈的是公司技术人员提供技术支持的能力极为有限，基本上不能作为依靠。那段时间的经历极其难忘，每天游历于各大论坛、邮递列表和技术网站等寻找帮助，时间精力花了不少，但是只能够得到一些基本的帮助，而关键问题要靠自己摸索解决，少量问题找不到解决办法，除非你能接触软件的核心层。
现在回过头看，真正的困难不在语言、编译、链接、调试等方面，那只是一道坎，过了就没事。最困难的地方在于目前各大有限元软件公司在中国的策略是重销售轻研发，甚至其外国母公司对中国用户的二次开发从心里就是不欢迎甚至轻视的，这一理念导致它们的驻中国机构对用户二次开发能提供的资料和帮助，以及公司本身的技术贮备和经验积累都相当不够。
在工作的进展过程中，由于自己迫不得已地需要钻研，对该软件的认识也就逐渐深入，用今天的眼光来评价它，就是一句话：它已经年老了，主要有以下症状：
(1) 核心架构老化，如同冷兵器上现代战场；
(2) 数据结构设计方式陈旧导致管理的困难；
(3) 过度数据冗余导致大量空间被无谓占用；
(4) 过度代码冗余导致系统十分笨重；
(5) 不能有效地实现子系统、功能、权限的合理配置。
以后的经历更让我意识到，上面的症状不只一家有，而是比较普遍的现象。
我们今天知道计算机行业进步太快了，技术在飞速发展，单就软件开发技术来看，这几十年来发展进步有多大，如网络计算、跨语言/平台、面向对象、多态、动态联编、动态数组、容器、迭代器、泛型算法、设计模式等。这些新的技术老牌软件用到的不多，实际上它也不能用了，因为它经不起大手术。因此，这些软件就只能在外围增加功能，于是，大家就经常能看到一些知名的有限元软件公司最喜欢做下面的一些事情：
(1) 通过兼并实现绑定新的功能模块；
(2) 玩几套bench类用户方案；
(3) 弄出一个脚本方式的shell；
(4) 把哪个国家的规范给整合进去；
(5) 宣传一下自己最近又打破了一项什么记录（比如算了NNNNNNNNN个节点的问题等）。
这些方面的工作并非不重要，但是如果只能做这些而不能进行内核的改进，那就说明软件发展到这一步，只能称之为“豪华老爷车”了，因为它的核心在一天天变老，最后走下神坛是早晚的事。
相信还有不少人有过和上面类似的经历，这让我们意识到软件行业与别的行业相比有一个特别的地方，就是“后发优势”永远都不能低估！别的行业历史越悠久越有品牌优势，但软件行业的悠久历史却有可能成为拖累，这表明：任何时候开发有限元软件都有后发优势！
即使身陷绝地，也不要失去希望。
本帖最后由 caoer 于 2010-6-3 12:13 编辑
当年学习upfs，看了不下100篇资料，最后只有一篇 同济博士后的论文在商用有限元二次开发上稍有建树。后来决定还是不攻upfs了，发现当时是个明智的决定。
楼上精神可嘉呀，哈哈！
看了你的贴，很希望能认识你。 1# refeihc
太震撼了，受益很大。现在才知道自己知道的多么浅显。。。
楼主太牛了！！！
一口气读完了楼主的帖子，以及热心人士的回帖，看完后感觉楼主的知识的确很渊博，应该是前辈吧，呵呵！ 对不必要进行重复性编程工作有了认识，感谢此贴!
确实，我们还在等待refeihc的后续文章。
这么好的文章不整理发表确实可惜阿。
老牌FEA软件的确在用着很老旧的架构和求解器，
但是这么多年的发展在他们的code里面已经沉淀下来了很多架构以外的东西
比如说经过几十年的QA和debug积累下来的无数tuning parameters.
这些参数已经形成了一种软件的AI，
而这种东西除非你能看到源码，在手册里你是绝对看不到的。
因此自己搭一套软件即使能克服你说的那N种架构上的问题，
但是仍缺少几十万个算例来调整你的代码。
你会发现即使你用的是更先进的数值算法更先进的架构，
算一个显式碰撞的例子居然会比NASTRAN慢了100倍。。。
这也是为什么NASTRAN这么多年仍然能占有市场的原因。
43# refeihc
在这里学的东西太多了
本帖最后由 hillyuan 于 2010-6-24 12:09 编辑
Attached document provides a good summary on 稀疏存贮格式.Wish it would be helpful. Pls also visit its homepage, http://www.ssisc.org/lis/. They also provide a open source corresponding to those format
在这里又看到了lis格式等，谢谢楼上，不过日语不懂的干活！
希望楼主继续更新，看到了不少观点啊，很受启发！
好好地学习了！原来求解器指的是求解刚度矩阵的部分，我以为直接就是一个有限元方法的核心。误解了。
受益匪浅，谢谢各位前辈！
lapack速度确实不错，处理起来还是些许方面的缺陷，希望大家能多提供捷径
哎看得我云中雾里
朋友，请继续啊
写的真好，讨论的挺有氛围的，学习了