只要做空气质量数值模拟WRF-CMAQ 这个名字就是绕不开的一道坎。CMAQ 是核心的化学传输模型负责把污染物从排放、输送到化学转化、沉降的全过程算出来WRF 则在前端提供逐时气象驱动场外加一份可靠的排放源清单三者合在一起才能支撑起一次 PM2.5 重污染个例复盘或者一个城市的臭氧污染成因分析。这篇文章是我对照 CMAQ 用户指南第 13 章UG_ch13做的梳理把模型架构、模块分工、实操流程和常见坑串成一条线。适合刚接触模型的研究生、想从气象转做空气质量的工程师以及工作中需要看懂模拟结果的环境咨询从业者。看完之后你脑子里应该能立起 WRF 到 MCIP 再到 CCTM 再到后处理这条完整链路知道每个环节的输入输出是什么也知道真跑起来会把时间丢在哪些地方。1. WRF-CMAQ 到底是什么气象场、排放源与化学机制组成的三角联动1.1 这不是一个黑箱子而是一条生产流水线先说结论WRF-CMAQ 不是单个执行程序而是一套多段式流水线。WRF 输出气象场MCIP 把气象场翻译成 CMAQ 能读的化学接口文件排放处理模块把各种格式的源清单变成网格化的机制物种最后 CCTMChemical Transport Model在三维网格上求解化学传输方程输出每个网格逐时的污染物浓度。任何一段断了后面全部白跑。这条流水线每一步的文件流转关系很明确。WRF 跑完会生成 wrfout_d01、wrfout_d02 这类文件MCIP 读取它们输出 METCRO3D、METDOT3D、METBDY3D、METCRO2D 等一组接口文件排放处理输出的是包含各化学物种排放率的网格文件CCTM 同时读取这两类数据再配上初始条件 ICON 和边界条件 BCON最后生成 CCTM_CONC 浓度文件、CCTM_DRYDEP 干沉降文件和 CCTM_WETDEP 湿沉降文件。后处理要做的就是从这些输出里提取变量、对比站点、画图。很多人被 CMQA 的各种文件后缀搞晕其实就是没想清楚“谁产生文件、谁消费文件”这条关系链。我在帮师弟排查问题时发现他卡在不知道 CMAQ 项目目录里 build、scripts、data 三大文件夹各自的职责于是拿到模型之后的第一件事不是编译而是对着目录结构发呆。记住一条原则CMAQ 的模块化设计本来就是让你可以分头折腾的气象、排放、化学机制各自独立处理最后在 CCTM 汇合。所以理解流水线关系比记住每个程序的名字更重要。1.2 为什么气象场质量几乎决定了模拟的成败气象场对空气质量模拟的影响怎么说都不为过。边界层高度从 500 米涨到 1500 米污染物垂直扩散空间放大了三倍地面浓度立刻能掉一半风向偏了 20 度污染带就从城市中心偏到郊区风速估算差个 30%区域输送的路径和到达时间就完全不同。降水更是气态污染物的“清洗剂”一场中等强度的雨可以把硝酸盐和硫酸盐湿沉降掉很大一部分。这些气象过程的模拟误差会直接传导到化学过程和浓度输出里。我在实际案例里对比过不同气象驱动方案下的 PM2.5 模拟结果同一套排放清单、同一个 CMAQ 版本仅仅因为 WRF 参数化方案不同日均浓度可以相差 30% 到 50%。所以老手拿到一份模拟结果第一反应不是调化学机制而是先看气象场跑得对不对风场有没有明显偏差、边界层日变化是否合理、降水落区和实况差多少。气象场不行后面 CMQA 算得再精细也只是在一个错误的基础上构建另一个错误。这一点毕业论文里可能不会教你但实际项目里几乎每次都会遇到。2. 三个核心模块谁管谁WRF、MCIP 与 CCTM 的职责边界2.1 CCTM 内部到底在算什么一个网格里的“浓度收支”如果把一个网格想象成一个水池CCTM 算的就是“某种污染物浓度在这个水池里怎么变”。进水的项是水平输送从周围网格带进来的污染物和本地排放出水的项是水平输送带走的部分和垂直方向扩散出边界层的部分水池内部同时进行着气相化学反应有的物种在生成、有的物种在消耗底部还有干沉降不断移走物质天上下雨时湿沉降又清掉一批。一天之内这十几个过程同时运行CCTM 用算子分裂的方法把它们逐个处理每一步都尽量保证质量守恒。CCTM 支持的化学机制主要有 CB碳键机制和 SAPRC 两大系列。CB6r3 是当前很常见的碳键机制版本把几百上千种 VOCs 按照碳键结构归纳成几十个物种从而把大气化学简化成可以数值求解的方程系统。气溶胶模块 ae6、ae7 则负责描述硫酸盐、硝酸盐、铵盐、黑碳、有机气溶胶的生成、增长和清除。选择机制时排放处理里的物种映射必须与 CCTM 的机制保持一致不然模型启动阶段就会报错。这个坑在 4.3 节我会专门展开。通俗地说CCTM 的核心是在每个网格、每一层、每个时间步里同时处理平流、扩散、化学反应、排放、沉降空间上覆盖整个模拟域时间上通常是逐小时输出。所以它对计算资源的要求很高也是整条流水线里最耗时的一环。实际跑一个三层嵌套、7 天案例CCTM 转起来动辄就是十几个小时甚至几天跑之前做好资源规划和文件备份很有必要。2.2 MCIP 和排放清单连接气象与化学的两座桥MCIP 是 Meteorology-Chemistry Interface Processor 的缩写它的工作说白了就是把 WRF 的气象输出“翻译”成 CMAQ 需要的气象驱动。WRF 输出的 wrfout 里虽然包含温度、风、湿等基本要素但 CMAQ 的气相化学、气溶胶和沉降模块需要的远不止这些它还需要行星边界层高度、摩擦速度、Monin-Obukhov 长度、感热通量、潜热通量以及 2 米温度、2 米比湿、10 米风这类近地面参数。MCIP 会从 wrfout 里抽取出基础变量经过诊断计算和垂直插值后生成 CMQA 能直接读取的接口文件。MCIP 输出的文件再强调一次METCRO3D 是各层三维气象场METDOT3D 是水平风在格点上而不是格心上的分量METBDY3D 是边界气象场METCRO2D 是地表二维参数。命名看起来绕但用途各不相同。如果 MCIP 处理时网格设置出了问题比如投影参数和 WRF 不一致CCTM 通常会在启动阶段或运行中途直接报错而且报错信息不会明说“你的 MCIP 错了”只会提示找不到某些变量或文件读取出错排查起来很费劲。另一座桥是排放清单处理。这一步是 CMAQ 整条链路里最容易出偏差的环节。一份原始清单可能是吨/年、吨/月、千克/小时这些五花八门的单位你得统一单位并拆成逐小时排放率NOx 要按比例拆成 NO 和 NO2VOCs 要按照化学机制里定义的物种一一对应不同行业、不同地区要用不同的时间分配曲线比如交通源在工作日和周末的高峰时刻完全不同。这个环节处理不好CCTM 运行再稳定模拟浓度也和实测对不上。3. 从零跑通一个 7 天个例模拟WRF、MCIP、排放与 CCTM 实操记录3.1 环境准备与版本选型先说环境。CMAQ 和 WRF 都是典型的 Linux 下数值模型常用环境是 CentOS/Rocky Linux 或 Ubuntu 服务器编译器可以用 Intel ifort 也可以 gfortran。需要提前装好的底层库包括 netCDF-C、netCDF-Fortran、MPIOpenMPI 或 MPICH、zlib、HDF5以及最关键的 I/O API 库。I/O API 是 CMAQ 读写 netCDF 文件的底层依赖编译时必须与后续 CCTM 使用同一套编译器和环境变量否则跑起来会出现文件读写不匹配的怪问题。版本选型建议CMAQ 5.3.3 是目前社区文档和讨论最多、最稳的一个版本适合新手起步CMAQ 5.4 对气溶胶机制做了明显更新新增了更多有机气溶胶物种机制更全但编译和调试的资料相对少一些。WRF 用 4.3 或 4.4 以上都没有问题关键是确认与 MCIP 的接口兼容。我个人的习惯是不追最新版本等社区的坑填得差不多了再升级。毕竟模型是工具不是用来折腾编译器的。版本组合优点缺点WRF 4.3 CMAQ 5.3.3社区资料多、坑少、编译顺利机制和过程代表性稍旧WRF 4.4 CMAQ 5.4气溶胶机制更新、结果物理过程更全编译与调试资料少、算得更慢WRF 4.6 CMAQ 5.4气象场精度更高依赖库版本要求高、环境配置复杂3.2 WRF 配置要点嵌套域、时间步长和 CFL 约束WRF 部分很多人已经很熟我挑和 CMAQ 强相关的地方说。做城市尺度模拟一般设置三层嵌套d01 覆盖整个区域水平分辨率 27 kmd02 覆盖省份或重点区域9 kmd03 覆盖目标城市3 km。namelist.wps 里的 geogrid 设置和 namelist.input 里的 dx、dy、e_we、e_sn 必须完全对齐嵌套关系要满足子域边界落在父域网格线上否则 metgrid 阶段就会警告甚至出错。时间步长是 WRF 最容易翻车的设置。3 km 网格用 60 秒是比较稳的组合9 km 网格可以用 180 秒左右。很多人为了省时间3 km 域直接把 dt 拉到 90 秒甚至 120 秒平时没事一旦遇到强对流或大风天气立刻触发 CFL 条件不满足的报错之前算的内容全白费。CFL 条件是数值稳定性的底线核心意思是每个时间步内信息传播的距离不能超过一个网格。所以水平分辨率越高dt 就得越小这个关系没法绕过。气象驱动数据一般用 GFS 或者 FNL 再分析场FNL 分辨率更高模拟效果通常更好一些。namelist.input 里的 num_metgrid_levels 要和 WPS 处理时保持一致别随手填一个数字否则 real 阶段会报出非常奇葩的垂直层不匹配错误。跑完 WRF 之后先检查 wrfout 文件里的风速、温度、降水是否合理再进下一步 MCIP省得后面木已成舟才发现气象场就是歪的。3.3 MCIP 处理与排放清单准备MCIP 的 namelist 里最关键的三项WRF 输入路径、输出路径、网格范围。网格范围必须从 WRF 的 namelist 里原样复制尤其是投影参数如果是兰伯特投影中心经度、两条标准纬线、起始点经纬度一个都不能错。MCIP 处理完成后先检查生成文件的时间范围是否覆盖你要的模拟时段再检查文件里有没有缺测或异常值。这一段如果错了CCTM 的报错会很莫名其妙。排放清单准备这一步新手最容易卡住。如果手里有已经网格化的排放数据比如常见的 MEIC 清单或者其他区域清单产品就需要做两个关键动作时间分配和化学物种映射。时间分配解决“一天 24 小时的排放怎么分布”的问题不同源类别用不同曲线化学物种映射解决“清单里的 CO、NMHC、NOx 怎么对应到 CB6r3 机制里的几十个物种”的问题。这一层处理做完才输出 CCTM 直接可读的网格排放文件。如果只有源源清单比如点源坐标和年排放量则还需要做空间分配也就是根据人口、路网、土地利用等代理变量把源排放分摊到每个网格。这个环节工作量很大也很容易出系统性偏差。我第一次做河北某城市的案例时把交通源全部堆到了高速公路上结果主城区模拟浓度明显偏低街道尺度的空间分布完全失真。现在我的习惯是先跑通流程用现成的网格清单把链路串起来之后再细化空间分配分步骤推进比一步到位靠谱得多。3.4 CCTM 运行参数与结果输出CCTM 的运行脚本一般是 run.cctm.* 这样的脚本里面最关键的几个变量是机制名称、模拟起始时间、运行天数、边界条件和初始条件。机制名称要和排放清单的物种映射一致比如都用 CB6r3_ae6_aq。边界条件如果做短期的区域模拟用 CMAQ 自带的默认 profile 也够但背景浓度给低了会导致模拟值系统性偏低臭氧的背景值默认给 20 ppb 左右比较常见具体要看模拟区域和季节。初始条件可以从前一天模拟结果里读也可以让模型自己 ramp-up 几天后进入稳定状态。并行计算设置上单节点多核可以用 NPCOL 和 NPROW 控制进程网格。比如分配 36 个核可以设 NPCOL6、NPROW6实测下来行数和列数越接近通信开销越小整体效率越高。跑起来之后记得保存运行日志我一般用 tee 同时输出到屏幕和文件方便出错后回溯。CCTM 跑完会在输出目录下生成 CCTM_CONC_v53_gmt_* 之类的文件可以用日志文件确认结束状态不要只看文件是否存在。CCTM 输出的是 I/O API 格式的 netCDF 文件里面包括 O3、NO2、PM2.5、PM10、SO2、CO 等常规物种浓度单位通常是 ppm 或者 ug/m3。如果只想要一次性的结果直接读 CCTM_CONC 就行。如果要做长期评估还需要把逐小时结果汇总成日均值或日最大 8 小时臭氧均值这是后处理里最基本的动作。3.5 后处理与验证用监测站点数据说话后处理的第一步是提取模拟值跟国控站监测数据做对比。Python 里用 netCDF4 库读 CMAQ 输出文件找到离站点最近的网格点把逐小时模拟序列拉出来再和监测时间序列画在一张图上。常用的统计指标包括平均偏差 MB、归一化平均偏差 NMB、归一化平均误差 NME、相关系数 R、均方根误差 RMSE。论文里最常放的表就是这几项不同污染物版本的验收口径不一样但思路都差不多模拟值和站点值时间变化趋势要基本一致量级上不能偏太多。画图工具上空间分布图可以用 Python 的 Cartopy 或 Basemap站点时间序列用 Matplotlib 就够了。分析场景比较灵活的时候也可以用美国环保署开源的 VERDI 工具它能直接读 CMAQ 输出文件并做切片、差值和多情景对比交互式探索时比写脚本方便得多。我的习惯是探索性分析用 VERDI正式出图出表用 Python 脚本前者省时间后者可复现、可交给流程自动化。4. 常见问题与排查技巧实录4.1 CFL 报错时间步长怎么调才不翻车CFL 报错是 WRF 阶段最常见的噩梦。典型症状是运行到中途突然跳出“CFL violated”或者计时器报错的提示然后任务终止。原因要么是时间步长太大要么是模拟区域地形过于复杂导致局地风速极值。处理方式最直接的就是把 dt 减半3 km 域从 60 秒减到 30 秒9 km 域从 180 秒减到 90 秒如果问题依旧再继续往下减。还有一种情况是垂直层设置太密集导致近地面层风场梯度大此时还需要适当调整垂直坐标拉伸系数。经验上dt 要同时参考水平分辨率和天气形势来定。夏季强对流多发时段3 km 域用 60 秒都未必保险遇到大范围雷暴天气直接降到 40 秒更稳妥。反正多算几个小时比中途崩溃重新跑要划算。如果你发现每次崩都在同一个时段那基本可以确定是那个时段里有强风或强对流过程针对性地减小 dt 就能解决完全不用改物理方案。4.2 模拟浓度整体偏低先从排放清单找原因模拟浓度系统性偏低的排查顺序第一永远看排放清单。很多新手的案例里把吨/年的总量直接当成克/秒去用数量级差了上千倍模拟浓度能高才奇怪。第二看时间分配有没有真正生效如果排放文件里每个小时都是同一个值说明时间分配这一步没有做或者代码路径没走对。第三看边界条件给的背景浓度是否合理臭氧背景值给太低整个模拟区域就像泡在没有污染物的空气里一样。我在实际项目中遇到过一种隐蔽情况排放清单空间范围和模拟域不完全重叠导致部分区域排放为 0。那种情况模拟图会非常醒目地出现一块干净得像风景区一样的区域而监测站恰好落在那块区域对比结果自然惨不忍睹。检查方法是把排放文件画出来和模拟域边界核对确保每个网格都有值。排放是浓度的源头源头错了后面调化学参数和扩散参数都是白费力气。4.3 化学机制物种不匹配启动即报错的元凶CCTM 启动时如果报 species not in file、找不到某些变量或者读取 CAM_ABFLAG 之类文件时出错多半是排放清单和 CCTM 的化学机制不一致。比如排放处理时用的是 CB05 机制物种CCTM 却选了 CB6r3两者在 VOC 物种的拆分上差别很大很多物种对不上号。解决办法是统一机制要么排放处理跟着 CCTM 走要么 CCTM 换回和排放处理一样的机制。排查技巧先看 CCTM 日志里第一类报错发生在哪个文件读取阶段再回去查排放文件里的变量列表。netCDF 文件里的变量名是可以直接列出来的比如用 Python 的 netCDF4 库把变量名打印出来一眼就能看出有没有 CB6r3 需要的物种。这个排查顺序能省下大量时间。我曾经因为排放文件里缺了异戊二烯的一个中间物种让模型在启动后十分钟才崩日志又没有明确提示折腾了两天才定位到物种映射文件漏了一行。4.4 嵌套网格偏移与输出为空嵌套网格对不齐是 CMAQ 里一个非常“鬼”的问题。典型表现是模拟出的浓度场在嵌套边界处出现明显断层或者整个浓度场相对监测站点有系统性偏移。原因几乎都出在 MCIP 或者 CCTM 的网格定义和 WRF 不一致尤其是投影参数里中心经度或标准纬线抄错一位小数图层放大了以后偏移就很明显。排查方法是把 CMAQ 域的经纬度网格画出来叠到 WRF 地形图上手动检查边界是否重合。别嫌这个步骤麻烦它比任何日志都直观。还有一种“输出为空”的情况。CCTM 跑完CCTM_CONC 文件也生成了但里面没有数据或者跑到一半日志就停住。优先检查磁盘空间很多大内存模型跑到最后一刻因为磁盘满了才静默失败其次检查运行日志结尾有没有 ERROR 关键字别只看“completed”字样。真实项目里输出被中断比编译失败更难发现因为所有前置文件都好好的只有结果文件缺失这时候回溯日志、确认每个任务结束状态就非常重要。我个人在实际操作中最深的体会是WRF-CMAQ 的上手曲线不是陡而是长。前期的编译和配置确实磨人但它很少考验智商更多是考验耐心和条理。另外一个坚持了很久的习惯是每个版本的 namelist、runscript、编译记录都单独备份目录名带上日期和备注。三个月后回看模拟结果如果当时的配置已经找不到了你基本就得从头再来。做模型测试时也别指望一步到位先跑通、再跑好用单层 3 km 域跑通一个 7 天案例远比一上来就铺三层嵌套然后卡在排放数据处理上有价值。把这条流水线的框架刻在脑子里之后剩下的就是一个个细节去磨磨到最后你会发现CMAQ 的运行逻辑其实非常规整报错也大多有迹可循。