简介面向需要在大气科学、环境模拟领域部署Flexpart的科研人员与Linux用户压缩包提供了Flexpart 10.4的完整源码用于解决Ubuntu 18.04下源码编译安装过程中的依赖配置难题。压缩包共718个文件、约328.8MB目录中包含Fortran源程序、Python处理脚本、Shell构建脚本、Makefile、HTML/RST说明文档、GRIB气象输入样例、CSV输出以及按日期命名的运行日志覆盖源码、配置、编译、测试、输出的完整闭环。已有606人学习下载对初窥源码编译或需复现粒子扩散模型的用户有较高参考价值。通过梳理其中的代码结构、配置文件与依赖关系可以更清晰地理解libemos、HDF5、NetCDF、eccodes、grib_api、jasper等组件的具体作用减少因库版本不匹配导致的安装失败。尤其适合在已有笨重容器环境或需要自定义编译选项时手动复现整套科学计算工具链并为后续二次开发或模型参数调试提供可查找的源码依据。 很多课题组、事业单位和环保公司内部流通的 FLEXPART 模型基本都是以flexpart.tar.gz这种源码压缩包的形式出现。FLEXPART 是拉格朗日粒子扩散模型的代表性工具被广泛用于大气污染溯源、火山灰扩散模拟、沙尘输送分析这类场景而 tar.gz 是 Linux 生态里最典型的源码打包格式这两者一组合意味着你手头是一份需要自行解压、配置、编译才有机会跑起来的科学计算源码包。这篇文章我会沿着解压检查—环境准备—编译配置—测试运行—问题排查这条主线把我在实操中踩过的坑、积累的技巧一次说清楚。不管你是刚接触 FLEXPART 的新人还是被 tar.gz 源码包折腾过几次的科研工程师照着这篇走能少走不少弯路。1. 先看清这个包里装的是什么1.1 FLEXPART 到底是干什么的FLEXPART 全称是 FLEXible PARTicle dispersion model由挪威大气研究所NILU维护是一款开源的大气粒子扩散模型。它最核心的思路是把污染物想象成大量微小粒子然后利用气象场数据驱动这些粒子在大气中运动最后统计粒子的轨迹和浓度分布。这个思路用一句话解释就是与其把污染物当成一团连续流体去解偏微分方程不如直接追踪成千上万条粒子路径。每个粒子都被风场吹着走同时叠加湍流扩散的随机扰动最终得到的结果就是污染物的空间分布和输送路径。实际用途很多。比如某个城市某天 PM2.5 突然爆表你想知道污染到底是从哪来的FLEXPART 可以反向追踪粒子的来源区域又比如火山喷发之后飞机会不会受到影响、火山灰会往哪个方向飘这类预警业务也会用到 FLEXPART。因为模型核心用 Fortran 编写源码量不小所以官方分发的基本都是编译源码这就注定了它不可能像 Windows 软件一样双击安装而是得走一套解压、配环境、编译、运行的流程。1.2 为什么源码包偏偏是 tar.gztar.gz 这个名字拆开看tar 是打包工具它把一堆文件和目录合成一个文件会保留文件的权限信息和目录结构gzip 是压缩工具负责把 tar 包再压小一点。合起来tar.gz 是 Linux 生态里最标准的源码分发格式几乎所有主流科学计算模型都长这样WRF、CMAQ、CAMx包括 FLEXPART 都是如此。很多人习惯用 Windows 的 WinRAR 或者 7-Zip 解压 tar.gz然后传到 Linux 服务器上这个操作我劝你尽早戒掉。原因在于 tar 格式不只是装文件它还会记录 Unix 权限位、软链接信息和文件归属。Windows 解压工具通常不关心这些解压完再传上服务器经常出现权限丢失、软链接失效的问题。最典型的现场就是你在服务器上执行./configure或者make系统提示 Permission denied查半天发现是源文件权限位变成了 644 或 777完全不对。在解压之前先用这条命令看看到底是什么内容tar -tzf flexpart.tar.gz | head -50-t是列出包内文件列表-z表示按 gzip 解压读取-f指定文件。这一步能让你在正式动手之前先看清楚目录结构、有没有 README、有没有 tests 目录心里有个数。1.3 解压前先花两分钟检查文件真正开始解压之前我建议你先做两个小检查。第一个是看文件大小和类型ls -lh flexpart.tar.gz file flexpart.tar.gzfile命令会告诉你这个文件真实的格式输出类似gzip compressed data就说明文件本身没坏。如果输出是ASCII text或者HTML document那十有八九下载链接给错了实际拿到的是一张网页或者一个文本错误信息。第二个是校验 md5 值特别是从别人手里拷贝的安装包md5sum flexpart.tar.gz如果文件来自官方或者同事对照一下对方给出的 md5 值是否一致能排除文件在传输过程中损坏的情况。这个习惯对源码包特别重要因为源码包损坏后编译报错会很奇怪报错位置千奇百怪排查起来非常浪费时间。检查无误之后下一步才是正式解压。2. 解压与编译环境准备2.1 标准解压操作FLEXPART 源码包通常建议解压到自己的用户目录或者专门的软件目录下不要往系统根目录塞。我的习惯是建一个~/models目录统一管理mkdir -p ~/models tar -xzf flexpart.tar.gz -C ~/models cd ~/models/flexpart-C参数指定解压目标目录非常实用。解压完成后第一件事不是找 makefile而是先看有没有 README 或者 INSTALL 文件ls -la很多源码包的 README 里就写着编译依赖、版本要求、测试方法花五分钟读一遍比瞎试半小时再回头看文档高得多。FLEXPART 的目录结构一般会有src源代码、tests测试用例、Docs文档这类目录。不同版本布局可能会有细微差别但无论什么版本核心编译入口都在源码主目录或src目录下。还要注意一个知识盲区tar.gz 解压后文件权限通常已经预设好了你不需要也不应该用chmod把整个目录都改成 777。保持源码包原始的权限位编译工具才不容易出奇奇怪怪的问题。2.2 编译依赖gfortran 与 netCDFFLEXPART 大部分版本依赖几个关键组件缺一个都不可能编译成功这里列一下依赖作用检查命令gfortran 或 ifortFortran 编译器核心编译工具gfortran --versionmake构建工具读取 makefile 执行编译make --versionnetCDF-C 库读取和写出 NetCDF 格式气象/输出文件nc-config --versionnetCDF-Fortran 库Fortran 接口链接 netCDF 文件nf-config --version其中最折腾人的是 netCDF。很多服务器上已经装了 netCDF-C但 Fortran 接口库没有装结果编译时一直报netcdf.mod not found。如果你用到的是比较新的 FLEXPART 版本还需要确认 netCDF-C 和 netCDF-Fortran 的版本是匹配的否则链接阶段会出现undefined reference之类的错误比如NF90_CREATE找不到。检查完依赖之后还要留意这些库的安装路径。当 FLEXPART 的 makefile 里写死默认路径比如/usr/local/include而你的 netCDF 是自己编译安装到/opt/netcdf/include时编译肯定找不到头文件。正确的做法是先确认库路径后面改 makefile 时直接按实际路径填。2.3 用 conda 把编译环境打包成 tar.gz这里要重点说一个和 tar.gz 关系很深的实用技巧当你需要把 FLEXPART 的整套编译环境迁移到另一台机器上尤其是迁移到没有外网、无法直接用 conda 装包的超算节点时用 conda-pack 把环境打包成 tar.gz 再迁移是效率最高的方式。具体步骤不复杂。先在源机器上安装 conda-packconda install -c conda-forge conda-pack然后打包你建好的 FLEXPART 编译环境比如环境名是flexpenvconda pack -n flexpenv -o flexpenv.tar.gz打包完成后把这个 tar.gz 文件拷到目标机器在目标机器的 conda 环境目录下解压mkdir -p ~/miniconda3/envs/flexpenv tar -xzf flexpenv.tar.gz -C ~/miniconda3/envs/flexpenv最后在环境里执行一次conda unpack修正各库的路径信息让环境里的库能定位到新机器的位置conda activate flexpenv conda-unpack这个技巧我实际用下来觉得特别稳因为 FLEXPART 对 netCDF 这类库的版本比较敏感如果新机器上缺依赖重新编译 netCDF 能熬掉你一个下午。直接把整个 conda 环境打成一个 tar.gz 搬过去相当于把编译好的依赖链整体迁移省掉太多麻烦。2.4 环境变量的记录习惯编译过程中还容易忽略的一点是环境变量。很多管理员通过module load来加载编译器每次登录都要重新加载如果你把module load的命令记下来写在自己的部署笔记里下次换终端或者换人操作就不会一脸懵。另外如果你把自己编译的 netCDF 库目录加到了LD_LIBRARY_PATH尽量把这个变量也记录下来。FLEXPART 是动态链接编译的运行时如果找不到 libnetcdf.so启动会直接报错。把这些路径信息存成一份deploy_notes.txt下次迁移或重装时对照着看能省下不少排查时间。3. 编译安装 FLEXPART 完整实操3.1 理解 FLEXPART 的配置入口编译 FLEXPART 之前最好先弄清楚它的运行文件体系。FLEXPART 运行时不光靠一个可执行文件它还要读取一系列配置文件常用到的包括pathnames指定模型输出目录、临时目录、气象数据目录是运行时第一个找的文件。CONTROL有些版本叫COMMAND控制模拟参数的 namelist 文件包括模拟时间段、输出间隔、释放物种等参数。RELEASES定义每次释放的物质类型、释放位置、开始结束时间和释放总量。SPECIES物种属性定义文件描述化学物质的分子量、沉降速度等参数。AVAILABLE告诉模型哪些时间段的气象输入文件是可用的。新手最容易犯的错误是直接执行./FLEXPART然后报错找不到文件原因就是没在正确的目录下启动或者pathnames文件不存在。第一次编译完我建议直接用源码包tests目录下自带的测试用例来跑不用自己改参数避免把配置问题混进环境问题里。3.2 修改编译配置并执行 make进入src目录后打开 makefile 文件重点关注几个关键变量。不同版本的 FLEXPART makefile 略有差别但核心配置基本都是这几个FC gfortran FCFLAGS -O2 -fopenmp NETCDF_INCLUDE -I/opt/netcdf/include NETCDF_LIB -L/opt/netcdf/lib -lnetcdff -lnetcdf如果你用 ifort 编译FC改成语境里实际加载的编译器如果服务器上没有单独装 netCDF而是通过 conda 安装的那你可以在 conda 环境内用nc-config --cflags和nc-config --libs拿到实际的路径参数nc-config --cflags nf-config --flibs拿到输出后把对应参数填入 makefile。这一步是编译 FLEXPART 最核心的地方配置对了基本一次过配置错了会反复报头文件找不到或者链接失败。我的习惯是先不急着改太多用make默认配置试一次让编译系统自己判断缺什么再根据报错信息回头改 makefile。正式编译的时候我建议不要用全核并行保守一点cd src make -j2-j2用两个核编译就够了。FLEXPART 某些源文件编译时内存占用很大尤其在优化级别较高的情况下如果机器内存紧张并行度开太高反而容易把编译器挤爆出现假死的状态。编译一旦成功src目录下会出现一个名为FLEXPART的可执行文件这个就代表主程序构建成功。编译过程中如果出现Error关键字的日志不要慌从第一条真正的报错开始排查后面跟着的往往只是连锁反应。3.3 运行自带测试用例并验证结果编译成功之后先跑测试用例确认模型整体可用。FLEXPART 源码包通常自带一组测试数据比如tests/test_001这种目录结构。进入测试目录后按照测试目录内的 README 或脚本提示把刚编译好的FLEXPART可执行文件路径填进测试脚本。以我的经验来看运行命令往往是这样的形式./FLEXPART pathnames注意pathnames是运行时第一个参数FLEXPART 会根据文件内容找到配置文件路径、气象输入目录和输出目录。测试跑完后检查输出目录重点看二进制输出文件是不是 0 字节。比如partposit_*.bin或者grid_*.nc这类文件只要大小不是 0说明粒子轨迹模拟在时间推进上是正常的。如果输出里面包含 NetCDF 格式的文件比如grid_conc.nc可以用下面的命令快速检查内容是否正常ncdump -h grid_conc.nc | head -30能看到变量定义和维度信息说明 netCDF 输出的数据结构没有问题。测试用例跑通就代表整个软链路的编译和配置已经打通后面替换成自己的气象数据和配置文件只是时间问题。4. 常见问题与排查技巧实录4.1 高频错误速查表我在不同服务器上编译和运行 FLEXPART 遇到过不少问题整理成了一张速查表如果你是第一次碰这个模型建议先把这张表存在手边。报错信息可能原因解决办法gzip: stdin: not in gzip format文件不是真正的 tar.gz可能下载不全或拿到的是网页用file判断真实格式重新下载make: gfortran: Command not found没有安装 gfortran 或未加载编译器模块apt install gfortran或module load gccFatal Error: Cannot open module file netcdf.modnetCDF-Fortran 接口库没装或路径没配安装 netcdf-fortran在 makefile 里指定NETCDF_INCLUDEundefined reference to nf90_create_netCDF-C 和 netCDF-Fortran 版本不匹配换用匹配的库版本重新编译 netCDF 全家桶Complaint: could not find pathnames运行目录下缺少pathnames文件把测试目录中的 pathnames 复制到运行目录或指定绝对路径expected floating point in namelist CONTROLCONTROL 文件里数值格式不对常见于手动编辑时丢失了小数位用原版配置测试确认无误后再按模板修改4.2 几个花钱买不来的避坑习惯编译 FLEXPART 这类源码包我总结出几条自己的习惯分享给你。第一条尽量不用 root 账号编译和运行模型。用 root 跑编译没问题但之后运行时 FLEXPART 会往输出目录写大量临时文件如果你用 root 跑过一次输出文件的所有者会变成 root下次换普通用户跑同一目录时权限就成了大坑。建议单独创建flex用户或者至少用归属自己的普通账号去跑模型。第二条不要在共享目录比如/home下的公共盘或者类似/tmp这种共享存储空间上直接解压编译。共享目录的粘滞位、用户权限配得很严格编译中间文件可能被其他用户干扰也可能因为配额不足导致 make 中断。在自己的用户目录或者/workspace这种私有工作目录下操作最省心。第三条遇到编译错误不要急着改代码。FLEXPART 是开源成熟模型绝大部分编译问题都是环境依赖问题或者路径配置问题而不是源码本身有问题。检查顺序应该是文件完整性 → 依赖版本 → makefile 配置 → 编译日志首条报错。按这个顺序来基本上能解决九成问题。第四条跑长时间模拟的时候把输出重定向到日志文件里nohup ./FLEXPART pathnames run.log 21 这样就算终端断开模型也能在后台继续跑日志信息留档也方便回放排查。我遇到过几次因为终端会话断开导致模型中断的尴尬情况后来一律养成 nohup 的习惯就没再犯过。最后再分享一个小技巧。拿到任何陌生的 tar.gz 源码包不要急着解压先用tar -tzf把包内文件列表扫一遍花点时间阅读 README确认依赖版本之后再做下一步。这个习惯让我在科研工具链的部署上少走了很多弯路也希望这篇经验能帮到正在和flexpart.tar.gz较劲的你。本文还有配套的精品资源点击获取