Bo Zhang's Homepage
..The universe is unfolding as it should..

2015-1-24

FLASH Code傲娇记

归档于: 天文空间科学, 天文软件 @ 9:07 pm

近日因为要计算相对论性激波的缘故,需要进行数值模拟,于是就面临一个选择:是自力更生编写代码,还是直接拿来现有程序?考虑一开始要求解的问题还算简单,使用现有大型模拟程序颇有牛刀杀鸡的感觉,而且这些大型程序的学习使用也非易事,有必要专门为此抽出两三个月的时间,本人最初是计划走前一路线的,相关代码主体也很快就编写完毕了。但是数值方法多少会带来误差,就本人所用的算法而言,人工耗散的懒往往是不可以偷的。不过相对论性流体基本方程组在分离变量之后造型奇特且复杂,自己一下子就因为耗散的添加方法而卡了壳。这时候合作导师又提出了新的课题,必须通过复杂的数值模拟工作才能解决,于是心一横,还是拿来主义好。

由于相对论性流体理论应用范围甚窄,可以求算相关问题且代码公开的模拟程序可谓屈指可数,之前在站里提到过数次的FLASH就是其中之一。之所以选择FLASH,是因为本人知道的另一套程序更加奇葩,并非使用Fortran或者C等“已知”计算机语言编写,而是出于模块化的考虑,用了作者自创的语言,在编译过程中再经由Python脚本将其转换为Fortran代码(嗯啊其实FLASH的模块化做得也不差啊,理解不能了)。换句话说,如果选择后者,必须从零开始学习这种诡异的新语言,感觉不是很妙啊。虽说有组内师弟称不大喜欢FLASH小组把核心代码留一手的作风,不过本人要解决的问题跟被留一手的部分没有什么关系,就随它去吧。其实个人以为,对于这种大型模拟程序,代码公开就意味着外人有可能跟小组成员抢饭碗,因此公开版有所保留纯属正常,大家体谅一下就好。何况开发FLASH的最初目的涉及天体环境下核爆燃的求解,核反应链以及点爆炸模拟的部分出于国家安全等因素的顾虑不能完全释放,也还是很能理解的。

说来本人是9年前经由芝加哥大学FLASH中心Donald Lamb的讲座第一次正经了解FLASH这个东西,那个时候还没有意识到它的强大之处;7年前对其威力有了初步认识的时候,这套程序因为政策原因还没有对中国开放,于是顺便还见识了系内老师的一连串怨念。不得不说,当年本人真的是做梦都没有想过有朝一日会真正接触它,而且可能还要将其用到研究工作中。好吧,实际上若干年前修过计算天文课程之后,也压根没想到日后自己的工作还会用到其中的内容……

决心已下,去FLASH中心填写代码申请表格不提。在正常情况下,申请提交后只消3、4个工作日就可以收到答复。不过本人时间不赶巧,是在去年圣诞节前后提交的申请,正逢美国的假期,于是等到新年过后若干天才得到了被批准的消息。然后就是令人无比抓狂且崩溃的配置过程了,这程序不愧是专为大型并行机开发的,多年来早已被无数世界一流的超算宠坏,在个人计算机上使用,怎一个傲娇了得。应帮助本人配置相关环境的Z师弟要求,为方便今后的查阅参考,遂有本文。至于什么供人借鉴学习之类就免了,一来并行运算相关知识水平实在太菜不具备指导他人的能力,二来估计也没有几个人需要使用FLASH……吧……

FLASH的代码主体是用Fortran90以及C语言编写的,当前的最新版本是4.2.2版,其中还用到了Python脚本。所以其运行环境要求多核计算机,配备Fortran90和C语言编译器,外加Python运行环境,当然可执行文件的生成还要用到make工具。不过对于Linux来说,Python和make大抵是操作系统自带的,也毋须劳神。为了实现并行运算的信息传递,FLASH使用了消息传递接口(MPI)库,官方提供的程序使用手册推荐安装美国阿尔贡国家实验室开发的免费软件包MPICH2。数据输出可以选择HDF或NetCDF格式,分别需要安装HDF5或PnetCDF相关的软件包,本人身边两名趟过FLASH的水的师弟都用了前者,于是跟风。计算数据的可视化可以选择商业软件IDL或者美国能源部提供的免费软件VisIt,准备其中之一即可。

下载到的FLASH代码压缩包名叫FLASHX.Y.Z.tar.gz,其中X.Y.Z是版本号,比如当前最新的就是FLASH4.2.2.tar.gz,下面以它为例。首先解压,然后进入生成的文件夹FLASH4.2.2/中:

tar -zxvf FLASH4.2.2.tar.gz
cd FLASH4.2.2/

紧接着,为了可以编译代码,需要在FLASH4.2.2/sites/<hostname>/文件夹下准备一个Makefile.h文件。这里的<hostname>/要用各人的主机名来替换,本人的主机名是Melipal,以下亦是以此为例,不再一一声明。Makefile.h文件的作用是指定各种所需编译器以及库函数在计算机中的路径(如不在这个文件中人工定义,程序会根据默认模板“猜测”相关程序和文件的所在,不过这猜得准确与否,就两说……),还要指定不同编译命令所需的各种参数(开始抓狂了)。

Makefile.h准备好之后,按照国际惯例,先拿程序自带的二维Sedov解问题试刀。进入FLASH4.2.2/文件夹,在终端输入如下命令:

./setup Sedov -auto

如果顺利的话,程序就会将求算Sedov解所需的各段代码在object/文件夹内做好链接,准备下一步生成可执行文件了。这里的./setup调用的是bin/文件夹下的Python脚本setup.py,Sedov是待解决问题的名称,对应source/Simulation/SimulationMain/文件夹下的子文件夹名,其他问题依需要替换。而-auto是./setup最常用的相关参数之一,至于其具体含义……还请各位看官暂且饶过本人。FLASH当前版本的使用手册厚达500余页,不是一时半会能啃得完的,而且光是./setup的相关参数在手册中就足足列了十来页,容我慢慢消化先……

什么,不会写Makefile.h?没关系,FLASH代码包自带欧美各路超算(以及疑似各种个人计算机)的Makefile.h文件供参(zhào)考(chāo):

好,那就随便抄一个来。出自美国劳伦斯—利弗莫尔国家实验室的zeus.llnl.gov服务器的模板看上去貌似还不错,先拿来一试好了。谁料麻烦由此开始出现了,原因出在这么一组编译命令的参数上:

看到没有,-m64啊!64位啊!悲催的是,本人当前使用的操作系统是32位的,这个参数不适用……然后鉴于本人跟帮忙配置的Z师弟都不是编译器行家,两人开始进行了一系列“根本不知道自己在做什么”的修改,改来改去还是毫无眉目,只能弃之不用……

然后又换了密歇根州立大学某集群的模板,结果更是离谱,执行./setup期间居然报错,称代码本身存在语法错误,这个,不大可能吧?也许这要归结为文件调用的开源编译器语法限制严苛所致,不过本人到现在也没能搞清楚问题所在。总之最终是换上了第三个已经不记得来路的模板(貌似是某台个人计算机所用?),才把./setup的问题解决掉。(呃啊,后来发现使用手册对Makefile.h的写法是有说明的,我错了……)

再然后进入object/文件夹,执行make命令,生成可执行文件:

cd object
make

此时诡异的报错再次出现,反复解决无果。最终发现,问题出在HDF5相关软件包上,HDF5 serial版,一个开发包,一个执行包,只是一个apt-get(或者什么类似命令)而已,一定要装全啊,要全!二者全部安装完毕就OK了!

好吧,这话说来轻松,其实在本人的计算机上,从解压完毕到顺利make,足足花费了一个下午外加半个晚上的时间。那天带着计算机去南大仙林校区向系里的Z师弟求助,反复make无果,连砸机器的心都起了。最后在打算放弃外加去FLASH邮件讨论群大吼一声的时候才找出了原因所在,于是赶忙补好所需组件,再一次执行make命令,终于看到了SUCCESS的提示。之后本人匆匆扣上屏幕,抄起书包径直冲下山去,一路小跑,好歹在最后一班返回市区的公交车发车之前赶到了校门口……

嗯嗯,下图极好地描绘了反复make期间本人与Z师弟的状态,也极好地描绘了两人在随后进行若干配置期间的状态……

但是据Z师弟称,如果是64位操作系统而且相关软件包已经安装完毕的话,FLASH的配置一点也不麻烦。好吧,算本人倒霉,系统各种不合要求,都要搞并行了还在用32位硬撑,哪里有这样的……可是为了照顾某些其他软件的使用,自己也不方便更换操作系统啊,只好凑合了……

make成功的话,应该可以在object/文件夹内找到一个名为flash4(或者说flashX,X是主版本号)的可执行文件:

然后……执行呗,在终端中输入如下命令,让这货跑一个试试呗:

./flash4

哦,忘了说明一点,如果需要设置计算参数,在执行之前需要修改object/文件夹内的flash.par文件,内里的内容大致如下,至于各参数的具体含义,还请参考使用手册:

鉴于FLASH采用了自适应网格技术,部分区域的网格可能会根据某些判断条件越划越密,因此格点总数会随之增加。同时为保证计算效率,程序不会为每一个处理器分配过多格点(严格地说是格点组,block,每个block由若干格点组成)。这样很可能出现的情况就是,运行到某一时刻后,程序就会因为格点数过多而中断,同时一并请求增加所用处理器的数量。为了解决这一问题(同时提高求解速度),并行运算是很有必要的。

在多核CPU早已普及的今天,并行运算说来也不是什么遥不可及的事情,个人计算机也不妨一试。在MPI环境配置完毕之后,只需在终端输入:

mpirun -np N ./flash4

这里的N是所用的处理器数量。但是问题就出在这个MPI环境上!作为并行技术盲,在配置期间,本人稀里糊涂地先后安装了MPICH2、OpenMPI、Intel的Fortran和C语言MPI编译组件等MPI相关软件包若干,然后,这些软件包彼此的冲突在所难免……

先是Intel的组件成了默认之选,执行mpirun期间报错称找不到mpivar.sh等相关文件;重装软件包之后发现问题出在缺乏相关MPI库文件上,下载解压之,再次吃了32位操作系统的亏,Intel提供的MPI库它只认得64位系统……然后换用MPICH2,对应安装目录是/usr/bin/mpirun,号称无法与本地mpd取得连接,至于这个mpd它到底是什么东西,不好意思本人真的不知道……

随后Z师弟硬是在网上搜索到了一个解决方法,也就是如下命令:

/usr/bin/mpdboot

如果上述命令也无效呢,最后一招大杀器在此:

/usr/bin/mpdtrace

执行mpdtrace之后,系统往往会提供一个方案,照办就是了。隐约记得我们是按照指示touch了一个文件,再mpdboot一下,就好了。不过被touch的具体是个什么东西,本人现在是一点印象也没有了。而mpdtrace是啥,mpdboot又是啥?嗯,本人也不知道,或者说是还没有来得及研究,姑且先在这里记上一笔待考……

为了使用方便,可以在家目录下的.bashrc文件中加上这么两行,这样今后只要执行并行运算,系统就自动调用MPICH2了:

alias mpirun=”/usr/bin/mpirun”
alias mpiexec=”/usr/bin/mpiexec”

于是,FLASH这个傲娇的货终于可以撒欢地跑开了,一边跑一边会输出各种参量:

这个时候,本人跟Z师弟已经是又累又饿,濒临崩溃……

不得不说,就算在个人计算机上执行如此简短的一个测试,并行运算的速度都会明显加快不少。虽说没有具体计时,若用4核执行Sedov解的求算,感觉所需时间大约只是非并行的三分之一甚至更短,实在是给人印象深刻啊。

不过也不要太得意。FLASH这货的傲娇之处还在于,哪怕在并行条件下,只要分配的处理器总数不是很多,在进行规模稍大的计算时,它就有可能出现各种撒娇耍赖老子不肯干的情况。有朋友对此评论曰,只见过搜X、迅X、3XX等等各大流氓或准流氓软件到了卸载时分作出万分忸怩娇羞状,这货是怎么了?头次听说还有程序在运行的时候给你玩花头的么……

Z师弟亲身遇到的FLASH耍赖实例,最后这两行不就是可以理解成,“你这什么破机器,条件太差老子不算了”么!

唉,谁让人家FLASH正常的运行环境都是国家级计算中心里的第一流集群/超算呢,放到个人计算机上处理一些小问题,也还真是委屈它了。估计执行大规模计算时,你要是不能一口气拨给它几百个核,它会跟你闹个没完的……当然,只要你不嫌慢(外加内存足够),完全可以在./setup期间通过修改maxblocks参数来提高每个处理器所能应付的block数量上限。不过出于运算速度和效率的考虑,这种做法并不是首选就是了,否则并行还有什么意义?

接下来要做的是输出数据的可视化。FLASH小组专门开发了一套Linux/Unix平台的IDL程序xflash3从事可视化分析,下面的任务是对其进行配置。因为配置过程(貌似连带也是IDL的默认运行环境?)需要在cshell下完成,首先要对自己的操作系统查漏补缺,没有安装csh的赶快去补好。然后进入csh,设置IDL_DIR、IDL_PATH以及XFLASH3_DIR三个环境变量:

setenv XFLASH3_DIR “<flash home directory>/tools/fidlr3.0″
setenv IDL_PATH “${XFLASH3_DIR}:$IDL_PATH”

这里的<flash home directory>是FLASH代码的解压路径,请自行替换。一般来说,执行以上两个命令之后,系统八成会提示IDL_PATH未定义,于是补充一句:

setenv IDL_PATH “${XFLASH3_DIR}:${IDL_DIR}:${IDL_DIR}/lib”

再然后,系统可能又会提示IDL_DIR未定义。没关系,继续补充:

setenv IDL_DIR “<idl home directory>”

其中<idl home directory>是IDL的安装路径,也请自行替换。到这里,在正常情况下就应该是一切OK了。当然,以上4条命令是每次使用xflash3之前都要输入的,只要你不怕麻烦。不过本人系懒虫一条,很怕麻烦(csh用起来真!心!烦!Tab不能,光标前后左右移动不能,上下键调用先前输入的命令不能……),于是打开家目录下的.cshrc文件,在其中添加如下几行:

setenv IDL_DIR “<idl home directory>”
setenv XFLASH3_DIR “<flash home directory>/tools/fidlr3.0″
setenv IDL_PATH “${XFLASH3_DIR}:${IDL_DIR}:${IDL_DIR}/lib”
setenv IDL_PATH “${XFLASH3_DIR}:$IDL_PATH”

特别提醒,一定要注意以上各行的顺序哦!前后不可以颠倒。完成后保存,对其执行source命令,这样就一劳永逸地解决了环境变量的设置问题。不出意外的话,xflash3就可以使用了,只消在csh下进入idl,然后输入xflash3即可:

让我们把二维Sedov解的输出数据画一画:

咦,上图看起来貌似有点不对劲?明明激波壳层应该是各向同性的正圆么,怎么会略带棱角呢?好吧,FLASH它又在傲娇了。根据使用手册的说明,如果自适应网格设置的层数不够多(这个例子用了6层,保持正圆需要更多),换句话说是在激波波面处分配的格点不够密,所得结果就不会是正圆……然后更多的层数意味着更多的格点,更多的格点意味着调用更多的处理器,于是为了保证结果的准确性,就需要动用能力更强的计算机……还是那句话,这货真的是被超算宠坏了啊!你当我这小本子是美国国家实验室的计算中心啊!真心伺候不起啊!还什么自适应网格,想当初在计算天文课程上,不是照样有同学用均匀网格搞定Sedov解,也没见人家算出什么棱角么!

再胡乱算个激波管玩一玩,这个看着倒还正常:

之后好景不长,整个平台开始抽风,先是MPICH2时好时坏,原因不明:

紧跟着,./setup它居然也莫名其妙地崩溃了!setup.py这个文件到现在本人还没有做过丝毫的修改好么!作为准Python盲,真的是彻底不知道应该做些什么了!

就上述问题打电话给自己在某高校软件学院任教的老爹求助,老爹表示对于并行运算他也完全无力。一顿分析之后的初步判断是,这些问题疑似由软件包之间的版本兼容性导致,毕竟并行运算是在充分压榨处理器的性能,各软件包之间稍有不合就有可能导致严重后果。算了,本人投降了,不在自己的计算机上收拾它了,反复折腾这一通就当是熟悉配置过程了,横竖一开始也没有指望在这台小本子上正经用FLASH搞什么研究。下面直接把它移植到组里或者是天文台里的服务器上好了,希望在更好的平台上,FLASH能跑得舒服些,不要再耍出种种脾气了吧。

FLASH真正让人开心之处是其物理和网格划分算法分离的架构,这是FLASH3开发过程中的一场革命,据说当时人力时间都花费了颇多,苦头也是没少吃。现在看来,这个决定是极其英明的,因为它让FLASH4新型自适应网格算法的引入大大简化了。对于使用者来说,至少对于本人来说,物理与网格的分离意味着只需要了解如何修改物理过程相关代码就可以求解具体问题了,至于如何化差分如何划分解域网格如何实现并行运算,那统统都与自己无关啊无关~~~

接下来除了在服务器上配置相关环境,还需要抓紧时间啃掉FLASH使用手册,至少是啃完自己用得到的部分。另外还有自学Python,至少是要做到对其略知一二吧。所以,任重道远啊!

No Comments

No comments yet.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

首页 | 天文 | 科学 | 摄影 | 模型 | CV | 版权声明 | 联系站长
京ICP备05002854号-2 Powered by WordPress Version 2.0.6
Licensed under Creative Commons Licenses

porno izle