写这篇的时候我刚帮一个师弟把他的 WRF-CMAQ 环境从“装到一半”状态救回来前前后后折腾了大半天。说实话这几年看过的 WRF-CMAQ 配置帖子不少但大多数要么只讲了 WRF 怎么装要么只给了 CMAQ 的环境变量很少有把“两套模型串起来”这条完整链路说清楚的。我最初接触这套模型时连续卡了三个晚上最后发现问题是 netCDF 库被装了两遍版本还不一致——这类问题特别典型也特别容易劝退新手。所以我决定把整个流程从头到尾重新捋一遍从环境配置的逻辑到编译器选型再到 WRF 安装、CMAQ 配置、测试案例运行全部按我的实际操作顺序来写争取做到可以照着一步步抄。1. 项目到底在做什么先搞懂 WRF 和 CMAQ 的分工逻辑WRF-CMAQ 并不是一个软件而是一条“气象模型 空气质量模型”的联动链路。WRFWeather Research and Forecasting Model负责模拟气象场包括温度、风场、湿度、气压这些CMAQCommunity Multiscale Air Quality Model则在 WRF 输出的气象场基础上模拟污染物的排放、扩散、化学反应和沉降过程。前者是“物理过程”后者更像“化学过程”。这套东西最典型的应用场景包括重污染过程的复盘模拟、减排方案的效果评估、空气质量预报、甚至政策决策支撑。它解决的核心痛点是——你想知道“如果把某个工厂的排放限值提高下风向城市的 PM2.5 会降多少”这种问题没法靠实测回答只能靠模型模拟。我从一开始就觉得新手必须想明白一件事WRF 和 CMAQ 之间有严格的上下游依赖关系。必须先跑通 WRF生成 CMAQ 需要的 met 文件再通过 MCIPMeteorology-Chemistry Interface Processor把 WRF 输出转成 CMAQ 能识别的格式最后才轮到 CMAQ 主程序CCTM上场。任何一步没接好后面都是空转。测试案例的意义就在这里。官方发布的“测试案例”并不是可选的锦上添花而是环境配置正确性的唯一校验手段。我见过太多人绕开测试案例直接跑自己的模拟结果出现各种摸不着头脑的错误——气压单位不对、网格错位、变量名不匹配归根结底是环境没对齐。1.1 核心需求拆解这套流程到底要解决什么问题把这个项目拆开看核心需求其实是三层。第一层是“环境可用”编译器、MPI、netCDF 等依赖库能装好ldd 检查没有缺失链接。这一层占整个项目耗时的 60% 以上大部分报错都发生在这里。第二层是“流程畅通”从 WRF 的预处理WPS到真实模拟real.exe再到 MCIP 转格式、CCTM 跑化学反应整条链路的运行脚本能够从头跑到尾。第三层才是“结果正确”你跑出来的臭氧浓度、PM2.5 分布跟观测值的对比在可接受误差范围内或者至少量级是对的。很多新手的问题是一上来就直奔第三层结果被第一层狠狠上一课。正确顺序一定是先环境 - 再案例 - 后业务别跳步。1.2 方案选型的理由为什么推荐官方测试案例作为起步点官方提供的测试案例通常包含了完整的数据包met 输入、排放输入、初始条件文件和对应的运行控制脚本。选择它作为起点不是为了“图省事”而是因为它是调试环境配置最干净、干扰最少的方式。测试案例的输入文件都是现成的出了问题几乎可以断定是环境或编译的问题而不是数据格式的问题。这个逻辑对新手特别重要。我自己调试 WRF-CMAQ 的经验是必须确保“变量隔离”——一次只变一个东西。你先用官方数据包跑环境没问题了再慢慢替换成自己的气象数据和排放清单。一步到位的结果往往是排错排到你怀疑人生。2. 环境配置新手最容易翻车的一个环节WRF-CMAQ 的环境配置核心就三件事编译器、MPI 库、netCDF 库。这三者必须版本匹配、编译链一致、路径清晰缺一个或者混了版本后面全崩。我强烈建议用 Linux 系统最好是 CentOS 7/8、Ubuntu 18.04/20.04或者国内的 OpenAnolis、麒麟这些兼容 CentOS 的发行版。如果手头只有 Windows我见过有同行用 WSL2Windows Subsystem for Linux跑通整个案例理论上可行但只能说“能跑”效率上不建议作为主力方案。编译器我首推 Intel 套件ifort icc mpiifort因为 WRF 和 CMAQ 官方对 Intel 的优化和支持都是最好的性能也明显优于 GCC。但 Intel oneAPI 的安装界面比老版本复杂不少环境变量需要自己手动 source 一下。次选 GCC 套件gfortran gcc mpif90好处是开源、免费、安装简单遇到问题排查帖子也多。坏处是性能差一些而且某些 CMAQ 模块对 GCC 的支持没有 Intel 那么完善。编译器和 MPI 有一个必须坚持的黄金规则全套编译器必须来自同一家。如果你用 ifort 编译程序那 MPI 必须用 Intel MPI或至少是用 Intel 编译器编译的 MPICH你用 gfortranMPI 就用 OpenMPI 或 MPICH 的 gfortran 版本。混搭的结果就是莫名其妙的段错误Segmentation Fault和浮点异常Floating Point Exception排查起来极为痛苦。netCDF 是这套模型的数据底层依赖。WRF 和 CMAQ 都用它来读写网格数据。这里有个血泪教训netCDF 必须用同一套编译器链统一编译而且 C 库和 Fortran 库必须分开装但增量安装——顺序是先装 zlib - 再装 hdf5 - 然后 netcdf-c - 最后 netcdf-fortran。别图省事用系统的包管理器直接 apt install 或 yum install 一个 netcdf 完事因为系统的 netcdf 多半没有 fortran 接口或者编译器跟你后面用的对不上。安装 netCDF 的时候我是这样配置的export DIR/usr/local/netcdf export CCgcc export CXXg export FCgfortran export F77gfortran export CPPFLAGS-I$DIR/include export LDFLAGS-L$DIR/lib # 编译 netcdf-c ./configure --prefix$DIR --disable-dap # 编译 netcdf-fortran ./configure --prefix$DIR注意不要把 netcdf-c 和 netcdf-fortran 分开编成两个独立的 prefix而是都用 /usr/local/netcdf这样 netcdf-fortran 安装时能自动识别 C 库的位置。2.1 系统级依赖清单装之前先确认这些东西有没有除开三大件还有些系统库是隐含依赖。如果缺失后续编译 WRF 或 CMAQ 会出现一些很怪的错误比如找不到某个头文件或者链接失败。我常用的系统依赖安装命令如下Ubuntu/Debian 系列sudo apt update sudo apt install -y build-essential gfortran m4 perl csh \ libpng-dev libjpeg-dev libtool autoconf automake \ zlib1g-dev curl wget bcCentOS/RHEL 系列则用 yumsudo yum install -y gcc gcc-c gfortran make m4 perl csh \ libpng-devel libjpeg-devel libtool autoconf automake \ zlib-devel curl wget bc这些库里有几个值得单独说m4netCDF、HDF5 的 autotools 构建系统强制依赖缺了 configure 脚本会直接报错。perlWRF 的 configure 脚本configure 命令本身是 Perl 写的缺了 Perl 连配置界面都出不来。cshCMAQ 的许多运行脚本是用 C Shell 写的.csh 脚本没有 csh 的话脚本直接无法执行会报“No such file or directory”之类摸不着头脑的错。libpng/libjpegHDF5 的可选依赖如果不装也能编译通过但后期某些并发输出功能可能受限。2.2 环境变量规划一次配好永久受益环境变量是 WRF-CMAQ 项目里最容易乱的地方没有之一。我见过的最常见翻车现场是打开新终端忘了 source 环境变量然后 LD_LIBRARY_PATH 不对程序一运行就报“error while loading shared libraries: libnetcdf.so.xx: cannot open shared object file”。这里我建议搞一个统一的环境变量脚本比如放一个wrf_cmaq_env.sh每次开新终端都 source 它一份#!/bin/bash # WRF-CMAQ 环境变量统一配置 export CCgcc export CXXg export FCgfortran export F77gfortran export F90gfortran # netCDF 安装路径 export NETCDF/usr/local/netcdf export PATH$NETCDF/bin:$PATH export LD_LIBRARY_PATH$NETCDF/lib:$LD_LIBRARY_PATH export CPPFLAGS-I$NETCDF/include export LDFLAGS-L$NETCDF/lib # MPI如果使用 OpenMPI gfortran 组合 export PATH/usr/local/openmpi/bin:$PATH export LD_LIBRARY_PATH/usr/local/openmpi/lib:$LD_LIBRARY_PATH # WRF 和 WPS 相关变量 export WRF_DIR/home/username/WRF export WPS_DIR/home/username/WPS export CMAQ_DIR/home/username/CMAQ注意几点路径量力而行不要照抄我的要改成你自己的实际安装路径。NETCDF这个变量名在 WRF 的 configure 阶段会被读取必须设置为 netcdf 的安装前缀目录但非常坑的是如果你设置NETCDF/usr/local/netcdf/bin这类带子目录的路径WRF 的 configure 会找不到。LD_LIBRARY_PATH是动态链接库搜索路径编译完的程序运行时靠它找 .so 文件。这里路径必须全部写绝对路径不要偷懒写相对路径。我当时还被一个问题坑了半天如果系统中存在多个版本的 netCDF比如 /usr/lib/x86_64-linux-gnu/ 下也有一个那么运行时加载的到底是哪个 .so 可以用ldd ./cctm.exe来看。如果 ldd 显示的不是你安装的那个 netcdf 路径说明 LD_LIBRARY_PATH 优先级有问题需要调整 export 顺序。3. WRF 的安装从下载到测试用例跑通WRF 的安装流程业界已经跑得很熟了但依然有几个容易踩的坑。我最推荐的路径是 WRF 4.x 系列目前 4.4 到 4.6 都比较稳搭配 WPS 4.x。下载地址在 GitHub 上可以找到不需要叙述太多直接 clone 或下载 release 版本的 tar.gz 即可。我习惯用 4.5 版本兼容性和稳定性比较均衡。另外如果想用一些新特性比如跑 RRTMG、新微物理参数各分支和版本支持程度略有差别先不用管跑通核心链路最重要。解压后进入 WRF 根目录运行./configure这一步会出一个交互式菜单问你选择什么样的编译平台和并行方式。不同的机器配置选项编号略有不同但要记住一个原则第 1 类Linux 平台的串行serial或并行smpar/dmpar。如果没有特殊需要建议选择DM par分布式内存并行也就是多节点并行这是 WRF 后期进行真实模拟的主流方式。单选编译器时如果你用了 Intel 工具链就要选包含 ifort 的那项如果是 GCC就选 gfortran 那项。不要在 configure 这一步偷懒乱选选错了后面 WRF 编译会出现大量诡异错误很多都是编译器和 MPI 不匹配导致的。选完 configure 后通常会要你确认嵌套还是非嵌套编译。一般选嵌套nesting, 1 basic。接着就是./compile em_real等它编译。编译时间取决于机器核心数一般 20 分钟到一个小时不等。编译完检查一下是否成功看看有没有生成main/wrf.exe、main/real.exe这些可执行文件。如果没生成说明编译失败需要回头排查依赖库。为什么这里我特别强调“确保 real.exe 和 wrf.exe 都生成”因为后面跑测试案例需要用到 real.exe 做初始化和边界条件处理而 wrf.exe 是真正进行模拟的模型主体。只生成一个后面就断在半路。3.1 WPS 的配置与测试数据WPSWRF Preprocessing System负责把外部气象数据比如 FNL 全球再分析资料插值到你的模拟区域网格上。它由三个程序组成geogrid地理网格生成、ungrib气象资料解压、metgrid气象资料水平插值到模拟网格。在测试案例环境下一般会提供预处理好的 met_em 文件或者其他格式的输入。WPS 的 configure 也需要单独运行cd WPS ./configure然后编辑namelist.wps设置模拟区域、时间窗、嵌套网格数等。对测试案例来说一般官方会给出对应的 namelist 样例直接参考修改就行。这里我必须提醒一个细节WPS 中的 geogrid 需要地理静态数据GEOGRID.TBL 等文件这些数据不在 WPS 源码包里需要单独下载。测试案例往往会跳过 geogrid 一步但如果你的 WPS 在geogrid.exe阶段报错概率最高的就是这个静态数据路径没配好。你需要检查namelist.wps里的geogrid_data_path是否指向真实存在的目录。3.2 WRF 的 namelist.input为什么测试案例最好别乱改WRF 跑测试案例时必须使用namelist.input。这个文件包含模拟起止时间start_* 和 end_*、时间步长time_step、网格尺寸e_we/e_sn、物理过程选项mp_physics、ra_lw_physics 等。对新手而言最忌讳的就是东改西改把物理方案换掉或者把时间步长改大。测试案例自带的数据是经过验证的它默认的设置通常能跑通如果你改了时间步长可能直接触发 CFL 条件失稳也就是计算发散wrf.exe 直接崩掉。我见过有人把 60 秒步长改成 180 秒然后模拟几十分钟后爆出“x is NaN”的错误最后折腾一整天发现是这里的问题。跑测试案例时我的建议是直接采用官方提供的 namelist.input 样例只把路径改成你的环境路径。如果必须修改只改输出频率history_interval这类无关痛痒的项。千万别动网格点数e_we/e_sn和时间步长除非你明确知道自己在做什么。4. CMAQ 的安装与配置比 WRF 更细致的一步CMAQ 是整个空气质量模拟的核心。它接收 MCIP 转换过的气象数据、排放源清单、初始/边界条件然后用化学机理比如 cb6r3、saprc07tic模拟污染物在大气中的变化。CMAQ 的版本目前官方推荐和测试较多的是 5.3.x 和 5.4。5.3.3 是经典版本许多排放处理和后续工具都沿用它的结构5.4 则更新了一些机制性能也更好。CMAQ 的安装流程比 WRF 还要“啰嗦”因为它的目录结构很讲究。官方源码解压后主目录下有CCTM、PREP、POST、UTIL等子目录。编译时不是直接make而是先进入CCTM/scripts目录通过运行bldit_cctm.csh来构建编译环境。bldit_cctm.csh里面有很多可配置项核心包括MECH选择化学机理默认可能是 cb6r3或者 aero6。EMIS排放源处理方式默认 DDM3D用于敏感性分析或标准方式。Compiler和 WRF 保持一致是 intel 还是 gfortran。MPI 设置是否支持并行。netCDF 路径库路径和 include 路径要正确。不同的编译器选择会生成不同的Makefile和模块对象文件。所以 CMAQ 编译也必须保持“同一套编译器链”的原则。如果你 WRF 用 gfortranOpenMPI 编译CMAQ 也建议用 gfortranOpenMPI最好不要一半一半混着来。在bldit_cctm.csh配置完、确认无误后运行它它会生成 CCTM 的 Makefile并自动编译。这一步耗时可能比 WRF 更长因为 CCTM 的模块非常多。编译完成后检查CCTM/scripts下是否生成了CCTM_v53_*或类似格式的可执行文件。提示CMAQ 编译过程中如果报错很大概率跟 netCDF Fortran 接口文件.mod 文件缺失或版本不对有关。这个问题的典型表现是“Error: Cannot open module file netcdf.mod ”此时你应该去检查 netcdf-fortran 是否真的装成功了以及编译器是否能找到$NETCDF/include目录。4.1 MCIP连接 WRF 与 CMAQ 的桥梁MCIPMeteorology-Chemistry Interface Processor是连接 WRF 输出与 CMAQ 输入的核心工具。它把 WRF 生成的三维气象场温度和风场做垂直坐标转换、地形跟随坐标转气压坐标同时计算出污染物体积分数、干沉降速度等 CMAQ 需要但 WRF 不直接输出的变量。MCIP 一般编译在CMAQ/PREP/mcip/src目录下通过 configure 编译生成mcip.exe。用 MCIP 时会在脚本里指定 WRF 输出的文件列表GRIDCRO2D、GRIDDOT2D、METCRO2D、METDOT3D 等然后 MCIP 会输出 METCRO3D、METDOT3D、METCRO2D 等 CMAQ 需要的文件。测试案例通常会把这些输入输出目录和文件准备好按要求填好对应路径就行。这里有个非常关键的概念需要了然于胸WRF 输出的坐标系统和 CMAQ 的需求不一定完全一致。MCIP 就是“翻译官”它做的事情包括坐标转换、单位换算、诊断量的计算。所以 MCIP 的配置如果错了后续 CMAQ 跑出来的数据一定不可信但这个过程不会报错只是静默地错——这一类错误是整个链条里最麻烦的。因此测试案例中关于 MCIP 的配置要逐项核对不要想当然。4.2 CMAQ 测试案例的选择与目录结构CMAQ 官方提供了一些 benchmark 测试案例最常用的包括2016_12emis2016 年 12 月的排放基准案例覆盖美国本土。2018_12emis2018 年 12 月的排放基准案例。以及更小规模的 WRF 单日示例。对新手来说我认为最好的选择是官方文档中“Single-Day Test Case”单日测试案例。它的数据量小、运行时间短、结果快速可验证。你可以先跑通它确认 CMAQ CCTM 无问题再换更大的案例。测试案例的数据包一般包括初始条件文件ICON边界条件文件BCON排放文件EMIS气象文件MCIP 输出以及配套的 run scriptrun_cctm.csh拿到之后把文件按目录结构放置好比如 ICON/、BCON/、EMIS/、MET/然后改写 run script 里的路径和日期参数接着就是运行。运行 CCTM 时我建议先测试单进程运行也就是把NPCOL、NPROW都配成 1确保端口顺畅再上 MPI 并行。这条经验非常重要——新手一上来就多核跑一旦出问题日志里看不到有用信息反而更难排查。先把单核问题排除干净再验证多核扩展效率更高。5. 测试案例运行从 WRF 到 CMAQ 的完整链路有了前面的准备现在开始走测试流程。我的推荐路径是先跑通 WRF 的单日理想/真实测试案例生成本地气象场。再跑 MCIP生成 CMAQ 的气象输入。最后跑 CCTM模拟完输出污染浓度。以下是我整理的一个典型测试案例运行顺序以 WRF MCIP CMAQ CCTM 为例。5.1 第一步跑 WRF 测试进入 WRF 主目录首先执行ln -sf /path/to/met_em_files .然后编辑namelist.input把start_year、start_month、start_day、start_hour和end_*改成测试数据的起止时间。接着运行./real.exe如果real.exe正常结束会生成wrfinput_d01和wrfout_d01之类的文件。此时查看rsl.out.0000日志看看有没有报错。如果显示成功再运行./wrf.exeWrf 运行期间观察输出日志。如果时间步进正常到最后一步会生成最终输出文件wrfout_d01_*。我当时第一次跑的时候连real.exe都报“ERROR: Could not open met_em file”后来才知道是路径问题。仔细看namelist.wps和namelist.input中的时间、网格尺寸也对不上直到把两个 namelist 的日期和网格都改成一致才顺利通过。5.2 第二步转 MCIP 文件以 MCIP 的 run script 为例里面对应了输出日期、气象输入文件列表、输出目录等配置。需要保证的是WRF 输出文件是wrfout_d01_YYYY-MM-DD_HH:00:00这种命名规则。MCIP 脚本中的日期时间必须与 WRF 一致。输出目录要预先创建好否则 MCIP 会报“cannot open output file”。运行脚本名一般是run_mcip.csh如果不是就找到以 .csh 结尾的 run 脚本。执行后观察输出目录下是否有METCRO3D等文件生成。MCIP 跑通后这些文件会被后续 CCTM 使用。5.3 第三步跑 CMAQ 的 CCTMCCTM 的 run script 通常叫run_cctm.csh。需要修改以下几处数据路径MET、ICON、BCON、EMIS 目录。日期起始日期和结束日期要与 MCIP/WRF 对齐。输出目录确保存在且有写权限建议看是否需要 mkdir。并行配置NPCOL、NPROW的设置必须满足NPCOL × NPROW 可用的 CPU 核心数。运行命令一般是./run_cctm.csh跑起来之后去看屏幕输出或日志文件。如果正常它会在指定输出目录生成CCTM_CONC_v53*之类的浓度文件。这个文件就是你最终做后处理和可视化的核心结果。5.4 怎么看测试案例是否“真的成功”很多时候脚本没报错程序也跑完了但结果其实是错的。这里教你几个快速判断测试案例是否合理的方法检查项判断标准说明进程退出码0 或正常结束标志非 0 代表运行异常日志末尾有“正常完成”或 echo Finished 之类不能只看没有报错输出文件大小不为 0且和平年代量级一致如果文件过小可能输入为空或提前终止浓度数值范围O3 白天在 10-80 ppb 量级PM2.5 在 1-100 μg/m³ 量级如果跑出天文数字多半是单位/输入问题以我过去经验最容易出问题的就是“输出文件生成了但数值全是 0 或 NaN”。这种情况通常指向气象输入问题或化学机理初始化失败。建议用ncdump -h查看输出文件头信息看看变量名和单位是否合理再决定是否进一步排查。6. 常见问题与排查技巧实录下面把这几年来遇到的高频问题做个汇总按出现频率从高到低列出来。这些问题不分先后但每个都值得收藏踩坑的时候回来对照。6.1 编译阶段问题速查现象可能原因解决办法configure 时找不到 netcdfNETCDF 环境变量未设置或路径不对重新 export NETCDF/usr/local/netcdf确认 include 和 lib 存在编译时报错找不到 nc.modnetcdf-fortran 未装或编译器不一致检查 netcdf-fortran 是否安装重新用同一编译器链编译链接时找不到 -lnetcdffLD_LIBRARY_PATH 未包含 netcdf/libexport LD_LIBRARY_PATH/usr/local/netcdf/lib:$LD_LIBRARY_PATHwrf.exe 编译生成但 real.exe 缺失编译器配置或 WRF 版本问题重新 ./configure选择正确的编译器再 ./compile em_realCCTM 编译时出现 F90 模块找不到排放库或 base 模块编译顺序问题检查 bldit_cctm.csh 中Bld选用模块路径确认make前模块库已生成编译阶段最怕的就是“报错信息看不懂就乱试”。我总结的核心原则是先确认依赖库正常再谈编译。用nfinfo或nf-config --all检查 netcdf 库的安装信息用which ifort或which gfortran确认编译器用mpirun --version确认 MPI 版本先消除环境层面的不确定性。6.2 运行阶段问题速查现象可能原因解决办法real.exe 报错“Could not find matching met_em file”namelist 时间或路径与 met_em 文件名不一致对照 namelist.wps 与 namelist.input严格保证日期时间一致wrf.exe 运行中途崩溃日志出现 NaNCFL 失稳、时间步长过大或地形数据异常减小 time_step比如 60 - 30或检查地形静态数据MCIP 报错“unable to open met file”WRF 文件未复制或路径写错检查脚本内 WRF 文件的绝对路径及文件权限CCTM 运行后输出文件全为 0 或很小排放文件或气象输入变量为空/错误用 ncdump 对比输入输出变量重点检查气压、温度CCTM 输出浓度量级异常单位问题或坐标系统错误检查 MCIP 输出中的单位确认运行脚本中的CTM_MAXSYNC之类参数每个案例都有其特殊性上面只是排查方向。真要给一个通用调试流程我会推荐出现异常时先看日志最后 50 行再定位是哪个程序段出问题然后回到输入数据用 ncdump 做一次变量健康检查最后才去改参数和重跑。6.3 一个非常隐蔽的坑并发文件描述符限制这个坑见到的稍微少一点但一旦踩到会非常影响心情。并行运行 CCTM 时如果进程数开得比较大可能会报“Too many open files”错误。这不是模型问题而是 Linux 的文件描述符限制不够用。解决方案是ulimit -n 65535或者写进 .bashrc 里免去每次手动设置的麻烦。你可以在重跑之前先用ulimit -a看下当前软限制和硬限制。我见过一台 40 核心的机器默认ulimit -n只有 1024跑 36 进程的 CCTM 时直接爆掉折腾很久才发现是这个问题。7. 新手启动清单我从踩坑中提炼的最小经验集如果你从来没有装过 WRF-CMAQ请按下面这份“最小启动清单”来走它可以帮你把项目控制在一天内完成基础跑通避免一开始就陷入泥潭。用 Linux 系统禁用 Windows 裸跑建议 WSL2 或虚拟机也慎重能物理机装就物理机装。除非有条件直接上服务器。一次只装一套工具链要么 Intel 全家桶要么 GCCOpenMPI 全家桶。宁可不花哨不要混搭。netCDF 按 zlib - hdf5 - netcdf-c - netcdf-fortran 顺序编译全部打到同一个 prefix不要 apt 安装系统自带的 netcdf。环境变量用一个脚本统一管理当前 shell 里 source 一次路径全部写绝对路径。WRF 选择 em_real 编译目标先跑通 WPS real.exe wrf.exe 的完整链路。CMAQ 用单日测试案例起步先单进程跑 CCTM确认输出文件数值合理后再启用多进程并行。每跑一步确认关键输出文件存在、非空、量级合理再进入下一步。回想我自己第一次跑通整个链路时最激动的其实不是看到臭氧浓度分布图而是看到日志文件里最后一行“Program completed normally”的瞬间。那意味着所有的编译器选择、库依赖、路径配置、namelist 设定全部对齐了整套系统在没有人为干预的情况下自己走完了从气象到化学的全过程。这个项目后续扩展的方向很多换自己的排放清单、加入嵌套网格、做数据同化、耦合化学机理……但前提都是这条基础链路足够稳固。希望这篇文章能帮你把第一步走得稳一点少走一些我当年绕过的弯路。
WRF-CMAQ从零配置到跑通全流程实践
写这篇的时候我刚帮一个师弟把他的 WRF-CMAQ 环境从“装到一半”状态救回来前前后后折腾了大半天。说实话这几年看过的 WRF-CMAQ 配置帖子不少但大多数要么只讲了 WRF 怎么装要么只给了 CMAQ 的环境变量很少有把“两套模型串起来”这条完整链路说清楚的。我最初接触这套模型时连续卡了三个晚上最后发现问题是 netCDF 库被装了两遍版本还不一致——这类问题特别典型也特别容易劝退新手。所以我决定把整个流程从头到尾重新捋一遍从环境配置的逻辑到编译器选型再到 WRF 安装、CMAQ 配置、测试案例运行全部按我的实际操作顺序来写争取做到可以照着一步步抄。1. 项目到底在做什么先搞懂 WRF 和 CMAQ 的分工逻辑WRF-CMAQ 并不是一个软件而是一条“气象模型 空气质量模型”的联动链路。WRFWeather Research and Forecasting Model负责模拟气象场包括温度、风场、湿度、气压这些CMAQCommunity Multiscale Air Quality Model则在 WRF 输出的气象场基础上模拟污染物的排放、扩散、化学反应和沉降过程。前者是“物理过程”后者更像“化学过程”。这套东西最典型的应用场景包括重污染过程的复盘模拟、减排方案的效果评估、空气质量预报、甚至政策决策支撑。它解决的核心痛点是——你想知道“如果把某个工厂的排放限值提高下风向城市的 PM2.5 会降多少”这种问题没法靠实测回答只能靠模型模拟。我从一开始就觉得新手必须想明白一件事WRF 和 CMAQ 之间有严格的上下游依赖关系。必须先跑通 WRF生成 CMAQ 需要的 met 文件再通过 MCIPMeteorology-Chemistry Interface Processor把 WRF 输出转成 CMAQ 能识别的格式最后才轮到 CMAQ 主程序CCTM上场。任何一步没接好后面都是空转。测试案例的意义就在这里。官方发布的“测试案例”并不是可选的锦上添花而是环境配置正确性的唯一校验手段。我见过太多人绕开测试案例直接跑自己的模拟结果出现各种摸不着头脑的错误——气压单位不对、网格错位、变量名不匹配归根结底是环境没对齐。1.1 核心需求拆解这套流程到底要解决什么问题把这个项目拆开看核心需求其实是三层。第一层是“环境可用”编译器、MPI、netCDF 等依赖库能装好ldd 检查没有缺失链接。这一层占整个项目耗时的 60% 以上大部分报错都发生在这里。第二层是“流程畅通”从 WRF 的预处理WPS到真实模拟real.exe再到 MCIP 转格式、CCTM 跑化学反应整条链路的运行脚本能够从头跑到尾。第三层才是“结果正确”你跑出来的臭氧浓度、PM2.5 分布跟观测值的对比在可接受误差范围内或者至少量级是对的。很多新手的问题是一上来就直奔第三层结果被第一层狠狠上一课。正确顺序一定是先环境 - 再案例 - 后业务别跳步。1.2 方案选型的理由为什么推荐官方测试案例作为起步点官方提供的测试案例通常包含了完整的数据包met 输入、排放输入、初始条件文件和对应的运行控制脚本。选择它作为起点不是为了“图省事”而是因为它是调试环境配置最干净、干扰最少的方式。测试案例的输入文件都是现成的出了问题几乎可以断定是环境或编译的问题而不是数据格式的问题。这个逻辑对新手特别重要。我自己调试 WRF-CMAQ 的经验是必须确保“变量隔离”——一次只变一个东西。你先用官方数据包跑环境没问题了再慢慢替换成自己的气象数据和排放清单。一步到位的结果往往是排错排到你怀疑人生。2. 环境配置新手最容易翻车的一个环节WRF-CMAQ 的环境配置核心就三件事编译器、MPI 库、netCDF 库。这三者必须版本匹配、编译链一致、路径清晰缺一个或者混了版本后面全崩。我强烈建议用 Linux 系统最好是 CentOS 7/8、Ubuntu 18.04/20.04或者国内的 OpenAnolis、麒麟这些兼容 CentOS 的发行版。如果手头只有 Windows我见过有同行用 WSL2Windows Subsystem for Linux跑通整个案例理论上可行但只能说“能跑”效率上不建议作为主力方案。编译器我首推 Intel 套件ifort icc mpiifort因为 WRF 和 CMAQ 官方对 Intel 的优化和支持都是最好的性能也明显优于 GCC。但 Intel oneAPI 的安装界面比老版本复杂不少环境变量需要自己手动 source 一下。次选 GCC 套件gfortran gcc mpif90好处是开源、免费、安装简单遇到问题排查帖子也多。坏处是性能差一些而且某些 CMAQ 模块对 GCC 的支持没有 Intel 那么完善。编译器和 MPI 有一个必须坚持的黄金规则全套编译器必须来自同一家。如果你用 ifort 编译程序那 MPI 必须用 Intel MPI或至少是用 Intel 编译器编译的 MPICH你用 gfortranMPI 就用 OpenMPI 或 MPICH 的 gfortran 版本。混搭的结果就是莫名其妙的段错误Segmentation Fault和浮点异常Floating Point Exception排查起来极为痛苦。netCDF 是这套模型的数据底层依赖。WRF 和 CMAQ 都用它来读写网格数据。这里有个血泪教训netCDF 必须用同一套编译器链统一编译而且 C 库和 Fortran 库必须分开装但增量安装——顺序是先装 zlib - 再装 hdf5 - 然后 netcdf-c - 最后 netcdf-fortran。别图省事用系统的包管理器直接 apt install 或 yum install 一个 netcdf 完事因为系统的 netcdf 多半没有 fortran 接口或者编译器跟你后面用的对不上。安装 netCDF 的时候我是这样配置的export DIR/usr/local/netcdf export CCgcc export CXXg export FCgfortran export F77gfortran export CPPFLAGS-I$DIR/include export LDFLAGS-L$DIR/lib # 编译 netcdf-c ./configure --prefix$DIR --disable-dap # 编译 netcdf-fortran ./configure --prefix$DIR注意不要把 netcdf-c 和 netcdf-fortran 分开编成两个独立的 prefix而是都用 /usr/local/netcdf这样 netcdf-fortran 安装时能自动识别 C 库的位置。2.1 系统级依赖清单装之前先确认这些东西有没有除开三大件还有些系统库是隐含依赖。如果缺失后续编译 WRF 或 CMAQ 会出现一些很怪的错误比如找不到某个头文件或者链接失败。我常用的系统依赖安装命令如下Ubuntu/Debian 系列sudo apt update sudo apt install -y build-essential gfortran m4 perl csh \ libpng-dev libjpeg-dev libtool autoconf automake \ zlib1g-dev curl wget bcCentOS/RHEL 系列则用 yumsudo yum install -y gcc gcc-c gfortran make m4 perl csh \ libpng-devel libjpeg-devel libtool autoconf automake \ zlib-devel curl wget bc这些库里有几个值得单独说m4netCDF、HDF5 的 autotools 构建系统强制依赖缺了 configure 脚本会直接报错。perlWRF 的 configure 脚本configure 命令本身是 Perl 写的缺了 Perl 连配置界面都出不来。cshCMAQ 的许多运行脚本是用 C Shell 写的.csh 脚本没有 csh 的话脚本直接无法执行会报“No such file or directory”之类摸不着头脑的错。libpng/libjpegHDF5 的可选依赖如果不装也能编译通过但后期某些并发输出功能可能受限。2.2 环境变量规划一次配好永久受益环境变量是 WRF-CMAQ 项目里最容易乱的地方没有之一。我见过的最常见翻车现场是打开新终端忘了 source 环境变量然后 LD_LIBRARY_PATH 不对程序一运行就报“error while loading shared libraries: libnetcdf.so.xx: cannot open shared object file”。这里我建议搞一个统一的环境变量脚本比如放一个wrf_cmaq_env.sh每次开新终端都 source 它一份#!/bin/bash # WRF-CMAQ 环境变量统一配置 export CCgcc export CXXg export FCgfortran export F77gfortran export F90gfortran # netCDF 安装路径 export NETCDF/usr/local/netcdf export PATH$NETCDF/bin:$PATH export LD_LIBRARY_PATH$NETCDF/lib:$LD_LIBRARY_PATH export CPPFLAGS-I$NETCDF/include export LDFLAGS-L$NETCDF/lib # MPI如果使用 OpenMPI gfortran 组合 export PATH/usr/local/openmpi/bin:$PATH export LD_LIBRARY_PATH/usr/local/openmpi/lib:$LD_LIBRARY_PATH # WRF 和 WPS 相关变量 export WRF_DIR/home/username/WRF export WPS_DIR/home/username/WPS export CMAQ_DIR/home/username/CMAQ注意几点路径量力而行不要照抄我的要改成你自己的实际安装路径。NETCDF这个变量名在 WRF 的 configure 阶段会被读取必须设置为 netcdf 的安装前缀目录但非常坑的是如果你设置NETCDF/usr/local/netcdf/bin这类带子目录的路径WRF 的 configure 会找不到。LD_LIBRARY_PATH是动态链接库搜索路径编译完的程序运行时靠它找 .so 文件。这里路径必须全部写绝对路径不要偷懒写相对路径。我当时还被一个问题坑了半天如果系统中存在多个版本的 netCDF比如 /usr/lib/x86_64-linux-gnu/ 下也有一个那么运行时加载的到底是哪个 .so 可以用ldd ./cctm.exe来看。如果 ldd 显示的不是你安装的那个 netcdf 路径说明 LD_LIBRARY_PATH 优先级有问题需要调整 export 顺序。3. WRF 的安装从下载到测试用例跑通WRF 的安装流程业界已经跑得很熟了但依然有几个容易踩的坑。我最推荐的路径是 WRF 4.x 系列目前 4.4 到 4.6 都比较稳搭配 WPS 4.x。下载地址在 GitHub 上可以找到不需要叙述太多直接 clone 或下载 release 版本的 tar.gz 即可。我习惯用 4.5 版本兼容性和稳定性比较均衡。另外如果想用一些新特性比如跑 RRTMG、新微物理参数各分支和版本支持程度略有差别先不用管跑通核心链路最重要。解压后进入 WRF 根目录运行./configure这一步会出一个交互式菜单问你选择什么样的编译平台和并行方式。不同的机器配置选项编号略有不同但要记住一个原则第 1 类Linux 平台的串行serial或并行smpar/dmpar。如果没有特殊需要建议选择DM par分布式内存并行也就是多节点并行这是 WRF 后期进行真实模拟的主流方式。单选编译器时如果你用了 Intel 工具链就要选包含 ifort 的那项如果是 GCC就选 gfortran 那项。不要在 configure 这一步偷懒乱选选错了后面 WRF 编译会出现大量诡异错误很多都是编译器和 MPI 不匹配导致的。选完 configure 后通常会要你确认嵌套还是非嵌套编译。一般选嵌套nesting, 1 basic。接着就是./compile em_real等它编译。编译时间取决于机器核心数一般 20 分钟到一个小时不等。编译完检查一下是否成功看看有没有生成main/wrf.exe、main/real.exe这些可执行文件。如果没生成说明编译失败需要回头排查依赖库。为什么这里我特别强调“确保 real.exe 和 wrf.exe 都生成”因为后面跑测试案例需要用到 real.exe 做初始化和边界条件处理而 wrf.exe 是真正进行模拟的模型主体。只生成一个后面就断在半路。3.1 WPS 的配置与测试数据WPSWRF Preprocessing System负责把外部气象数据比如 FNL 全球再分析资料插值到你的模拟区域网格上。它由三个程序组成geogrid地理网格生成、ungrib气象资料解压、metgrid气象资料水平插值到模拟网格。在测试案例环境下一般会提供预处理好的 met_em 文件或者其他格式的输入。WPS 的 configure 也需要单独运行cd WPS ./configure然后编辑namelist.wps设置模拟区域、时间窗、嵌套网格数等。对测试案例来说一般官方会给出对应的 namelist 样例直接参考修改就行。这里我必须提醒一个细节WPS 中的 geogrid 需要地理静态数据GEOGRID.TBL 等文件这些数据不在 WPS 源码包里需要单独下载。测试案例往往会跳过 geogrid 一步但如果你的 WPS 在geogrid.exe阶段报错概率最高的就是这个静态数据路径没配好。你需要检查namelist.wps里的geogrid_data_path是否指向真实存在的目录。3.2 WRF 的 namelist.input为什么测试案例最好别乱改WRF 跑测试案例时必须使用namelist.input。这个文件包含模拟起止时间start_* 和 end_*、时间步长time_step、网格尺寸e_we/e_sn、物理过程选项mp_physics、ra_lw_physics 等。对新手而言最忌讳的就是东改西改把物理方案换掉或者把时间步长改大。测试案例自带的数据是经过验证的它默认的设置通常能跑通如果你改了时间步长可能直接触发 CFL 条件失稳也就是计算发散wrf.exe 直接崩掉。我见过有人把 60 秒步长改成 180 秒然后模拟几十分钟后爆出“x is NaN”的错误最后折腾一整天发现是这里的问题。跑测试案例时我的建议是直接采用官方提供的 namelist.input 样例只把路径改成你的环境路径。如果必须修改只改输出频率history_interval这类无关痛痒的项。千万别动网格点数e_we/e_sn和时间步长除非你明确知道自己在做什么。4. CMAQ 的安装与配置比 WRF 更细致的一步CMAQ 是整个空气质量模拟的核心。它接收 MCIP 转换过的气象数据、排放源清单、初始/边界条件然后用化学机理比如 cb6r3、saprc07tic模拟污染物在大气中的变化。CMAQ 的版本目前官方推荐和测试较多的是 5.3.x 和 5.4。5.3.3 是经典版本许多排放处理和后续工具都沿用它的结构5.4 则更新了一些机制性能也更好。CMAQ 的安装流程比 WRF 还要“啰嗦”因为它的目录结构很讲究。官方源码解压后主目录下有CCTM、PREP、POST、UTIL等子目录。编译时不是直接make而是先进入CCTM/scripts目录通过运行bldit_cctm.csh来构建编译环境。bldit_cctm.csh里面有很多可配置项核心包括MECH选择化学机理默认可能是 cb6r3或者 aero6。EMIS排放源处理方式默认 DDM3D用于敏感性分析或标准方式。Compiler和 WRF 保持一致是 intel 还是 gfortran。MPI 设置是否支持并行。netCDF 路径库路径和 include 路径要正确。不同的编译器选择会生成不同的Makefile和模块对象文件。所以 CMAQ 编译也必须保持“同一套编译器链”的原则。如果你 WRF 用 gfortranOpenMPI 编译CMAQ 也建议用 gfortranOpenMPI最好不要一半一半混着来。在bldit_cctm.csh配置完、确认无误后运行它它会生成 CCTM 的 Makefile并自动编译。这一步耗时可能比 WRF 更长因为 CCTM 的模块非常多。编译完成后检查CCTM/scripts下是否生成了CCTM_v53_*或类似格式的可执行文件。提示CMAQ 编译过程中如果报错很大概率跟 netCDF Fortran 接口文件.mod 文件缺失或版本不对有关。这个问题的典型表现是“Error: Cannot open module file netcdf.mod ”此时你应该去检查 netcdf-fortran 是否真的装成功了以及编译器是否能找到$NETCDF/include目录。4.1 MCIP连接 WRF 与 CMAQ 的桥梁MCIPMeteorology-Chemistry Interface Processor是连接 WRF 输出与 CMAQ 输入的核心工具。它把 WRF 生成的三维气象场温度和风场做垂直坐标转换、地形跟随坐标转气压坐标同时计算出污染物体积分数、干沉降速度等 CMAQ 需要但 WRF 不直接输出的变量。MCIP 一般编译在CMAQ/PREP/mcip/src目录下通过 configure 编译生成mcip.exe。用 MCIP 时会在脚本里指定 WRF 输出的文件列表GRIDCRO2D、GRIDDOT2D、METCRO2D、METDOT3D 等然后 MCIP 会输出 METCRO3D、METDOT3D、METCRO2D 等 CMAQ 需要的文件。测试案例通常会把这些输入输出目录和文件准备好按要求填好对应路径就行。这里有个非常关键的概念需要了然于胸WRF 输出的坐标系统和 CMAQ 的需求不一定完全一致。MCIP 就是“翻译官”它做的事情包括坐标转换、单位换算、诊断量的计算。所以 MCIP 的配置如果错了后续 CMAQ 跑出来的数据一定不可信但这个过程不会报错只是静默地错——这一类错误是整个链条里最麻烦的。因此测试案例中关于 MCIP 的配置要逐项核对不要想当然。4.2 CMAQ 测试案例的选择与目录结构CMAQ 官方提供了一些 benchmark 测试案例最常用的包括2016_12emis2016 年 12 月的排放基准案例覆盖美国本土。2018_12emis2018 年 12 月的排放基准案例。以及更小规模的 WRF 单日示例。对新手来说我认为最好的选择是官方文档中“Single-Day Test Case”单日测试案例。它的数据量小、运行时间短、结果快速可验证。你可以先跑通它确认 CMAQ CCTM 无问题再换更大的案例。测试案例的数据包一般包括初始条件文件ICON边界条件文件BCON排放文件EMIS气象文件MCIP 输出以及配套的 run scriptrun_cctm.csh拿到之后把文件按目录结构放置好比如 ICON/、BCON/、EMIS/、MET/然后改写 run script 里的路径和日期参数接着就是运行。运行 CCTM 时我建议先测试单进程运行也就是把NPCOL、NPROW都配成 1确保端口顺畅再上 MPI 并行。这条经验非常重要——新手一上来就多核跑一旦出问题日志里看不到有用信息反而更难排查。先把单核问题排除干净再验证多核扩展效率更高。5. 测试案例运行从 WRF 到 CMAQ 的完整链路有了前面的准备现在开始走测试流程。我的推荐路径是先跑通 WRF 的单日理想/真实测试案例生成本地气象场。再跑 MCIP生成 CMAQ 的气象输入。最后跑 CCTM模拟完输出污染浓度。以下是我整理的一个典型测试案例运行顺序以 WRF MCIP CMAQ CCTM 为例。5.1 第一步跑 WRF 测试进入 WRF 主目录首先执行ln -sf /path/to/met_em_files .然后编辑namelist.input把start_year、start_month、start_day、start_hour和end_*改成测试数据的起止时间。接着运行./real.exe如果real.exe正常结束会生成wrfinput_d01和wrfout_d01之类的文件。此时查看rsl.out.0000日志看看有没有报错。如果显示成功再运行./wrf.exeWrf 运行期间观察输出日志。如果时间步进正常到最后一步会生成最终输出文件wrfout_d01_*。我当时第一次跑的时候连real.exe都报“ERROR: Could not open met_em file”后来才知道是路径问题。仔细看namelist.wps和namelist.input中的时间、网格尺寸也对不上直到把两个 namelist 的日期和网格都改成一致才顺利通过。5.2 第二步转 MCIP 文件以 MCIP 的 run script 为例里面对应了输出日期、气象输入文件列表、输出目录等配置。需要保证的是WRF 输出文件是wrfout_d01_YYYY-MM-DD_HH:00:00这种命名规则。MCIP 脚本中的日期时间必须与 WRF 一致。输出目录要预先创建好否则 MCIP 会报“cannot open output file”。运行脚本名一般是run_mcip.csh如果不是就找到以 .csh 结尾的 run 脚本。执行后观察输出目录下是否有METCRO3D等文件生成。MCIP 跑通后这些文件会被后续 CCTM 使用。5.3 第三步跑 CMAQ 的 CCTMCCTM 的 run script 通常叫run_cctm.csh。需要修改以下几处数据路径MET、ICON、BCON、EMIS 目录。日期起始日期和结束日期要与 MCIP/WRF 对齐。输出目录确保存在且有写权限建议看是否需要 mkdir。并行配置NPCOL、NPROW的设置必须满足NPCOL × NPROW 可用的 CPU 核心数。运行命令一般是./run_cctm.csh跑起来之后去看屏幕输出或日志文件。如果正常它会在指定输出目录生成CCTM_CONC_v53*之类的浓度文件。这个文件就是你最终做后处理和可视化的核心结果。5.4 怎么看测试案例是否“真的成功”很多时候脚本没报错程序也跑完了但结果其实是错的。这里教你几个快速判断测试案例是否合理的方法检查项判断标准说明进程退出码0 或正常结束标志非 0 代表运行异常日志末尾有“正常完成”或 echo Finished 之类不能只看没有报错输出文件大小不为 0且和平年代量级一致如果文件过小可能输入为空或提前终止浓度数值范围O3 白天在 10-80 ppb 量级PM2.5 在 1-100 μg/m³ 量级如果跑出天文数字多半是单位/输入问题以我过去经验最容易出问题的就是“输出文件生成了但数值全是 0 或 NaN”。这种情况通常指向气象输入问题或化学机理初始化失败。建议用ncdump -h查看输出文件头信息看看变量名和单位是否合理再决定是否进一步排查。6. 常见问题与排查技巧实录下面把这几年来遇到的高频问题做个汇总按出现频率从高到低列出来。这些问题不分先后但每个都值得收藏踩坑的时候回来对照。6.1 编译阶段问题速查现象可能原因解决办法configure 时找不到 netcdfNETCDF 环境变量未设置或路径不对重新 export NETCDF/usr/local/netcdf确认 include 和 lib 存在编译时报错找不到 nc.modnetcdf-fortran 未装或编译器不一致检查 netcdf-fortran 是否安装重新用同一编译器链编译链接时找不到 -lnetcdffLD_LIBRARY_PATH 未包含 netcdf/libexport LD_LIBRARY_PATH/usr/local/netcdf/lib:$LD_LIBRARY_PATHwrf.exe 编译生成但 real.exe 缺失编译器配置或 WRF 版本问题重新 ./configure选择正确的编译器再 ./compile em_realCCTM 编译时出现 F90 模块找不到排放库或 base 模块编译顺序问题检查 bldit_cctm.csh 中Bld选用模块路径确认make前模块库已生成编译阶段最怕的就是“报错信息看不懂就乱试”。我总结的核心原则是先确认依赖库正常再谈编译。用nfinfo或nf-config --all检查 netcdf 库的安装信息用which ifort或which gfortran确认编译器用mpirun --version确认 MPI 版本先消除环境层面的不确定性。6.2 运行阶段问题速查现象可能原因解决办法real.exe 报错“Could not find matching met_em file”namelist 时间或路径与 met_em 文件名不一致对照 namelist.wps 与 namelist.input严格保证日期时间一致wrf.exe 运行中途崩溃日志出现 NaNCFL 失稳、时间步长过大或地形数据异常减小 time_step比如 60 - 30或检查地形静态数据MCIP 报错“unable to open met file”WRF 文件未复制或路径写错检查脚本内 WRF 文件的绝对路径及文件权限CCTM 运行后输出文件全为 0 或很小排放文件或气象输入变量为空/错误用 ncdump 对比输入输出变量重点检查气压、温度CCTM 输出浓度量级异常单位问题或坐标系统错误检查 MCIP 输出中的单位确认运行脚本中的CTM_MAXSYNC之类参数每个案例都有其特殊性上面只是排查方向。真要给一个通用调试流程我会推荐出现异常时先看日志最后 50 行再定位是哪个程序段出问题然后回到输入数据用 ncdump 做一次变量健康检查最后才去改参数和重跑。6.3 一个非常隐蔽的坑并发文件描述符限制这个坑见到的稍微少一点但一旦踩到会非常影响心情。并行运行 CCTM 时如果进程数开得比较大可能会报“Too many open files”错误。这不是模型问题而是 Linux 的文件描述符限制不够用。解决方案是ulimit -n 65535或者写进 .bashrc 里免去每次手动设置的麻烦。你可以在重跑之前先用ulimit -a看下当前软限制和硬限制。我见过一台 40 核心的机器默认ulimit -n只有 1024跑 36 进程的 CCTM 时直接爆掉折腾很久才发现是这个问题。7. 新手启动清单我从踩坑中提炼的最小经验集如果你从来没有装过 WRF-CMAQ请按下面这份“最小启动清单”来走它可以帮你把项目控制在一天内完成基础跑通避免一开始就陷入泥潭。用 Linux 系统禁用 Windows 裸跑建议 WSL2 或虚拟机也慎重能物理机装就物理机装。除非有条件直接上服务器。一次只装一套工具链要么 Intel 全家桶要么 GCCOpenMPI 全家桶。宁可不花哨不要混搭。netCDF 按 zlib - hdf5 - netcdf-c - netcdf-fortran 顺序编译全部打到同一个 prefix不要 apt 安装系统自带的 netcdf。环境变量用一个脚本统一管理当前 shell 里 source 一次路径全部写绝对路径。WRF 选择 em_real 编译目标先跑通 WPS real.exe wrf.exe 的完整链路。CMAQ 用单日测试案例起步先单进程跑 CCTM确认输出文件数值合理后再启用多进程并行。每跑一步确认关键输出文件存在、非空、量级合理再进入下一步。回想我自己第一次跑通整个链路时最激动的其实不是看到臭氧浓度分布图而是看到日志文件里最后一行“Program completed normally”的瞬间。那意味着所有的编译器选择、库依赖、路径配置、namelist 设定全部对齐了整套系统在没有人为干预的情况下自己走完了从气象到化学的全过程。这个项目后续扩展的方向很多换自己的排放清单、加入嵌套网格、做数据同化、耦合化学机理……但前提都是这条基础链路足够稳固。希望这篇文章能帮你把第一步走得稳一点少走一些我当年绕过的弯路。
