简介flexpart.tar.gz是Flexpart 10.4大气粒子轨迹模型的完整源码资源包面向从事大气扩散模拟、气溶胶输运研究的科研人员及需要部署模型的环境工程师重点解决在Ubuntu 18.04下源码编译安装时依赖库众多、版本配置容易冲突的难题。压缩包内共718个文件大小约328.8MB文件类型十分丰富既有Fortran核心源程序和makefile构建配置也有控制文件、气象场样本grb、csv、历史日志还有html、rst、md等格式的说明文档可满足从代码阅读到实际编译的多层次需求。目前已有606人学习下载适合具备Linux基础并希望深入掌握模型编译细节的读者。包内保留了多个makefile变体与不同时期的编译日志能直观对比不同配置选项带来的差异帮助定位常见错误同时围绕libemos、HDF5、NetCDF、eccodes等关键依赖可以完整理解各库在数据读写、格式转换与压缩处理中的实际作用显著降低自主编译的门槛。 拿到 flexpart.tar.gz 这个压缩包的时候我其实已经预感到要折腾一阵子。干我们这行的都懂气象模型从来不是解压就能跑的你面对的是一串编译选项、一堆依赖库、还有永远对不上的气象场数据。但说实话FLEXPART 这个拉格朗日粒子扩散模型在污染物溯源、火山灰扩散这些场景里确实太好用了值得花时间把环境搭起来。这篇文章就把我从拿到 flexpart.tar.gz 到跑通第一个算例的完整过程记录下来中间踩过的坑、绕过的弯路也一并写出来另外还会分享一个衍生技巧如何把 conda 编译环境也打包成 tar.gz用来免去重复编译的麻烦。不管你是做空气质量模拟的研究生还是要集成 FLEXPART 的工程师这篇应该都能给你省下不少时间。1. 先说清楚 flexpart.tar.gz 到底是个什么1.1 FLEXPART 是干嘛的FLEXPARTFLEXible PARTicle dispersion model是一套开源的大气拉格朗日粒子扩散模型由挪威大气研究所NILU联合多个欧洲机构开发维护。它跟 WRF-Chem、CMAQ 这类欧拉网格模型的思路完全不同欧拉模型是把大气剖成一个个固定网格在每个格点上求解偏微分方程组而 FLEXPART 把污染物拆成成千上万个“粒子”让每个粒子跟着气象场里的风走再用随机扰动模拟湍流的扩散效果。你用肉眼想象一下河流里撒一把木屑木屑顺着主流往下漂同时被漩涡带着左右晃动最后你在下游数一数每个河段漂到多少木屑。FLEXPART 干的就是这件事只不过把河换成了大气。这一套方法天然适合做长距离输送和溯源分析。比如某天监测站点测到高浓度二氧化硫你想搞清楚污染物到底是从哪个工业区飘过来的FLEXPART 可以把粒子在时间上反向跑算出“可能来源区域”的概率分布。同样火山灰扩散预报、放射性核素示踪、花粉过敏原浓度预测、温室气体排放源反演这些场景里 FLEXPART 都是被反复验证过的工具。学术圈里用它发文章的非常多业务单位里也有不少把它嵌进预报流程做痕量物质迁移预警。1.2 为什么开发团队选择用 tar.gz 发布源码先说一下 tar.gz 本身。“tar” 是磁带归档的缩写最初就是为了把一堆文件打包成一个整体方便备份gzip 是后面的压缩层负责把打包后的体积压小。两者合起来就是最常见的 Unix/Linux 源码分发格式。FLEXPART 目前是以源码压缩包的形式在官网发布页面提供下载文件名通常就是 flexpart-x.y.z.tar.gz 这种风格。为什么是 tar.gz 而不是预编译好的二进制安装包原因很实际FLEXPART 的编译结果跟操作系统、Fortran 编译器版本、NetCDF 库实现都有关系开发团队不可能针对每种环境都预编译一份二进制文件。把源码交给你你在自己的机器上编译反而能针对本机 CPU 指令集做优化跑起来性能也更好。另外模型本身就是开源项目源码分发也方便用户查看具体算法、修改参数、二次开发。至于为什么用 tar.gz 而不是 zip纯粹是 Linux 生态的习惯——tar.gz 在 Linux 和 macOS 下不需要额外装工具就能解压配合 gzip 压缩率也不错包体积小下载也快。从使用角度看拿到 flexpart.tar.gz 之后要经历解压、编译、配置气象场、写输入文件、运行、分析结果这一整条链路。下面按实际动手的顺序来讲。2. 从 tar.gz 到跑通第一个算例完整实操2.1 解压前先检查环境先确认机器上有没有必要的工具链gfortran --version nc-config --version nf-config --version如果 nc-config 或 nf-config 提示找不到说明 NetCDF 相关开发库还没装。FLEXPART 读气象场和写输出都依赖 NetCDF所以必须先把 netcdf-c 和 netcdf-fortran 装齐。在 Debian/Ubuntu 上可以这样装sudo apt install gfortran libnetcdf-dev libnetcdff-dev在 CentOS/RHEL 上改用 yum/dnf 装对应的包。这里有个小经验netcdf-fortran 和 netcdf-c 是两个不同的包很多人只装了 libnetcdf-dev结果编译时死活找不到 NetCDF 的 Fortran 模块就是这个原因。如果系统自带的 gfortran 版本太老或者你不想污染系统环境推荐用 conda 建一个独立的环境专门放编译器和依赖库这跟后面第 4 节要讲的 conda 环境打包是连贯的。用 conda 装conda create -n flexpart-env -c conda-forge gfortran libnetcdf netcdf-fortran conda activate flexpart-env检查完环境之后找一个磁盘空间足够的位置解压。气象场数据动辄几个 GB 到几十个 GB建议把 flexpart 的安装目录和数据目录分开不要把几千个 GRIB 文件和解压后的源码塞在同一个目录下不然以后想清理都分不清哪个是哪个。解压这一步没什么悬念tar -xzf flexpart.tar.gz cd flexpart-10.4顺手看一下包内有什么ls -la一般会有 src 目录、文档、示例配置文件。建议先读一下 README 或者 RELEASE_NOTES里面会注明版本特性、依赖库的最低版本要求。这些信息在官网文档里也可能有但源码包里的版本和线上文档经常存在时间差以包内为准。2.2 编译过程中的关键配置FLEXPART 的编译方式随版本差异比较大。老一点的版本9.x主要靠修改 makefile 里的编译器路径和编译选项10.x 开始逐步统一最新的 11.x 则推荐用 CMake。自己动手编译之前先确认手上是哪一个版本别拿别人博客里的命令硬套。以比较常见的 FLEXPART 10.4 为例进入 src 目录后一般会看到 makefile 或者 makefile.mac。你需要打开 makefile找到 Fortran 编译器的定义改成 gfortranFC gfortran同时确认 NetCDF 头文件和库文件的路径有没有写对。用 conda 环境编译的话这些路径通常都在环境目录下的 include 和 lib 里建议用 nf-config 自动获取nf-config --fflags nf-config --flibs把输出的参数直接填到 makefile 里基本就能解决路径不对的问题。配置完成之后执行make clean make这里有个容易踩的坑第一次编译报错时很多人直接改完 makefile 又 make结果因为之前的中间产物缓存还在问题根本没被重新编译到。我的习惯是先 make clean 再重新 make保险又省心。编译结束后在 src 目录或主目录下会生成一个可执行文件通常叫 flexpart。验证一下./flexpart如果没有输入文件它会报缺少文件之类的错误这其实是好事说明程序本身能启动。如果直接报 error while loading shared libraries: libnetcdff.so.12那就是运行时动态链接库路径的问题用 ldd 检查一下ldd ./flexpart | grep netcdf如果发现库找不到简单粗暴的办法是设置 LD_LIBRARY_PATH指向 netcdf-fortran 所在的 lib 目录。2.3 输入文件准备与最小算例FLEXPART 的运行不是靠命令行参数传一堆东西而是靠一组输入文件。刚接触的时候最容易懵的就是这些文件之间的关系。拿 10.x 来说常见的输入文件包括 pathnames、COMMAND、AVAILABLE、RELEASES、SPECIES、OUTGRID、AGECLASS 等。它们看起来多其实各自管一块pathnames 告诉程序各个输入输出文件放在哪里COMMAND 定义模拟起止时间、输出步长RELEASES 定义释放粒子的时间地点物种AVAILABLE 列出所有气象场文件的时间覆盖OUTGRID 定义输出网格。这里要特别提醒不同版本的 pathnames 文件里需要写的行数、顺序并不一样最靠谱的办法是打开源码里对应的读取模块比如 readpathnames.f90看它到底按什么顺序读哪些路径。我一开始照着网上的教程写 pathnames结果程序启动后半天没反应后来一查才发现版本不一样少写了一行后面所有文件的路径全部错位。为了快速验证编译没白费你可以先用示例数据跑一个最小算例。有些源码包自带的测试用例目录里就有现成的输入文件直接复制过来改一下路径就能跑。如果没有就手工写一个极简配置用 ERA5 或 GFS 的一小段气象场释放一个网格点上的少量粒子输出间隔设大一点跑一个短时间模拟。这样既能验证编译结果也能熟悉输入文件格式。运行起来之后程序会打印每个输出时间步的进度信息。正常的话输出目录下会生成多个 NetCDF 文件里面存了不同时间步的浓度场。到这一步你手里的 flexpart.tar.gz 才算真正变成了能用的工具。3. 运行 FLEXPART 时最常遇到的几个坑3.1 路径写错导致一切白费FLEXPART 对路径非常敏感而且它不会给你特别友好的报错。常见的情况pathnames 里的目录末尾少了那个 “/”某个输入文件路径写成了相对路径而程序启动时的工作目录又不是你预想的那一个AVAILABLE 文件里指向的气象场目录跟实际文件存放位置对不上。这些错误很多时候都表现为程序启动后立刻退出或者卡在某一步反复打印 File not found。我建议在第一次跑通之前做两件事一是统一用绝对路径别贪图方便写相对路径二是在 pathnames 文件里把每个路径都手动检查一遍确保对应的文件和目录真实存在。用脚本批量检查也行while read line; do if [ -e $line ]; then echo OK: $line; else echo MISSING: $line; fi done pathnames这条命令会把 pathnames 里每一行当成路径检查MISSING 的就是问题所在。虽然是笨办法但排查路径问题特别有效。3.2 气象场数据的匹配问题跑通最小算例之后接下来最让人头疼的就是气象场数据。FLEXPART 需要的气象场不是随便拿一个 NetCDF 或 GRIB 文件就能喂进去的它要求数据有特定的变量、层级、时间分辨率并且时间范围必须覆盖整个模拟窗口。具体来说有两个高频错误一是气象场的时间覆盖范围小于模拟时间程序跑到某个时刻突然报错说没有下一时刻的数据二是气象场数据的时间间隔太大比如只有 6 小时间隔但粒子扩散模拟需要更细的时间插值。第二个问题不一定是报错可能是结果精度不合理。最好先用脚本检查 AVAILABLE 文件里登记的起止时间同时确认模拟窗口确实落在里面。另外从 ECMWF 官网下载的原始数据通常还需要通过 FlexExtract 这样的工具做裁剪和格式转换把 GRIB 转成 FLEXPART 能识别的格式。这个环节很容易被忽略因为很多教程直接跳过了数据预处理。如果你是从网上找的现成气象场也要先确认格式和版本兼容不然程序很可能读到一半就崩了。3.3 并行编译与性能调优粒子扩散模型天生适合并行每个粒子的轨迹在大部分时间都是独立的可以把粒子群拆成多份让不同线程或者进程分别算最后再合并统计。FLEXPART 在这方面支持 OpenMP 和 MPI 两种方式具体用哪个要看编译时有没有启用对应的 flag。如果你是单台机器跑OpenMP 是最省事的选择。编译时加上-fopenmp运行前设置export OMP_NUM_THREADS8然后观察运行时间和 CPU 占用率。粒子数量越多、模拟时间越长并行收益越明显。我有一次做火山灰扩散模拟粒子数开到 200 万单线程要跑十几个小时开了 16 线程之后不到一个半小时就跑完效果相当可观。不过要注意线程数并不是越大越好开得太多线程调度和内存带宽反而会成为瓶颈。实际使用时可以拿同一段模拟做不同线程数的对比测试找到拐点。如果你是跑批量业务或者需要在集群上跑MPI 版本会更有优势但配置复杂度也上去了需要额外安装 OpenMPI 或 MPICH并且编译环境要匹配。建议先单机 OpenMP 跑通再考虑 MPI 扩展。4. 衍生技巧把 conda 编译环境也打包成 tar.gz4.1 为什么要动 conda 环境前面编译 FLEXPART 的时候提到可以用 conda 建环境这一步在单机上确实方便。但如果你像我一样单位有好几台服务器要部署每次都在新机器上从头 conda 建环境、装依赖、编译一遍时间成本就很高了。尤其是编译过程中踩过一遍坑、终于调好了 NetCDF 和 gfortran 版本搭配之后你会特别想把这套“能用的环境”原封不动搬到另一台机器上。conda 环境本质上就是一组目录里面放着编译器、共享库、可执行文件理论上可以打包迁移。这就是热词里说的“conda 环境 tar.gz 创建环境”的常见需求——把一个环境打包成 tar.gz到新机器解压后直接激活使用省掉从零搭建的流程。对于 FLEXPART 这种依赖库一大堆、版本还敏感的模型来说这个技巧尤其适用。4.2 两种打包思路conda-pack 与原生 tar第一种也是最推荐的方式用 conda-pack 工具。先安装conda install -c conda-forge conda-pack然后打包环境conda pack -n flexpart-env -o flexpart-env.tar.gzconda-pack 会把环境里所有文件打包关键在于它会记录环境的前缀路径这样在目标机器上解压到别的位置之后它会自动改写路径信息让环境还能正常激活使用。这是它比直接 tar 更省心的原因。第二种方式是直接压缩环境目录tar -czf flexpart-env.tar.gz -C $CONDA_PREFIX .这种方式的优点是简单粗暴不需要额外装工具但缺点也很明显环境里的很多二进制文件是用绝对路径编译的打包前环境在/home/user/miniconda3/envs/flexpart-env到了新机器解压在/data/conda/envs/flexpart-env很多库的 RPATH 匹配不上启动时可能报找不到共享库。如果你想用这种方式就必须保证目标机的路径和原机器完全一致这在实际部署中往往很难做到。所以我的建议是日常自己备份用 tar 直接压一下没问题跨机器迁移优先用 conda-pack。4.3 解包后常见问题与处理解包 conda 环境这一步也有讲究。conda-pack 解压到目标机器的 conda 环境目录比如$CONDA_BASE/envs/下然后用conda activate flexpart-env激活。如果解压到别的目录需要设置环境变量的方式激活或者用conda-unpack命令完成路径修正。常见问题第一是 glibc 版本不一致。conda 环境的包通常会自带较低版本的依赖但如果你是系统编译器直接编译的程序动态链接到系统的 glibc换到更老的系统上很可能跑不起来。这类问题大多报错为version GLIBC_2.XX not found。所以迁移前要确认目标机器的系统版本不能太旧。第二个常见问题是 libgfortran 版本不匹配。gfortran 编译器本身是 conda 里的可如果 FLEXPART 是系统 gfortran 编译的运行时就会找系统里的 libgfortran跟 conda 环境没关系。为了避免这种混乱我建议从编译到运行全程只用一个工具链要么全用系统包要么全走 conda 环境。实测下来全程 conda 环境打包的方案最干净也是最容易复现的。还有一个很伤的问题架构不匹配。x86_64 机器上打包的环境不能迁移到 ARM 机器上这是硬性的conda-pack 也无能为力。在集群内部迁移之前最好先确认所有节点都是同一架构。5. 几个提升效率的小经验先分享一个关于备份的习惯。我每次把环境的版本调稳定、FLEXPART 编译通过并跑通一个基准算例之后都会立刻做一次 conda-pack 备份并且把打包好的 tar.gz 和基准算例的输入输出一起存档。这样万一哪天环境被搞乱了或者要换机器直接解包就能恢复到能用的状态不用重新走一遍排错流程。第二个经验是写一个简单的环境变量脚本。FLEXPART 不同算例的输入文件分散在各自目录里跑起来很容易搞混。我会在每个算例目录下放一个setenv.sh里面设置好FLEXPART_PATH、DATA_PATH、OMP_NUM_THREADS同时激活对应的 conda 环境。换算例的时候 source 一下就切到对应的运行环境比每次手动敲一串 export 要稳得多。最后想说网上关于 FLEXPART 的教程虽然不少但版本之间差异很大照抄哪篇都可能有坑。我个人的习惯是拿到源码包之后先把 README、RELEASE_NOTES 和目录结构扫一遍再动笔改配置。很多看起来奇怪的问题其实在源码注释里都写了原因。玩这种科研模型耐心读源码比到处搜教程更管用。希望这篇围绕 flexpart.tar.gz 的完整过程记录能让你少走点弯路。本文还有配套的精品资源点击获取