zoukankan      html  css  js  c++  java
  • 如何评价数学软件包[转]

    兵法云:多算胜,少算不胜,况无算乎?用兵打仗如此,科研何尝不如此。

    当美国人开始意识到靠理论研究与实验研究两条腿走路的传统科学技术,在未来将要有第三根支柱——计算科学——来支撑的时候,他们静悄悄地努力了五十多年。而当他们认为已经把竞争对手远远甩到身后,取得巨大的领先优势时,于是在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不少的好话,也鼓励大家使用它,是不想让大家开发程序时在底层费太多力。当然如果是想学习数值分析算法,自己练手编程,那又另当别论。

  • 相关阅读:
    部分Gamefest 2011的材料已经放出
    glloader 3.7.0发布,支持最新的OpenGL 4.2
    关于D3D11,你必须了解的几件事情(二)
    不争气的geometry shader
    day2:数据类型、字符编码、文件处理
    jquery 常用
    Eclipse插件开发之EasyExplorer
    如何切图&PS切图&网页切图
    PS切图的相关技巧
    Eclipse快捷键大全(转载)
  • 原文地址:https://www.cnblogs.com/xiexiaokui/p/1789159.html
Copyright © 2011-2022 走看看