1. 先说这次踩坑FNL数据与num_metgrid_levels的“对不上”最近跑WRFWeather Research and Forecasting Model的时候被一个看起来特别不起眼的参数卡了整整一天——num_metgrid_levels。报错信息翻来覆去就那么几句一会儿是“nlevels specified (27) not equal to nlevels in data file (34)”一会儿又是“The number of levels in metgrid output does not match namelist”。我一度以为是软件装坏了甚至把WPS和WRF整个重新编译了一遍结果问题原封不动。后来冷静下来才意识到问题出在我用的FNL再分析数据上——不同版本、不同来源的FNL数据垂直层数根本不一样而我手里的namelist.input还沿用着旧脚本里的层数设置。先给不熟悉的读者补个背景。FNL是NCEP发布的一套全球分析资料全称是Final Operational Global Analysis很多做中尺度气象模拟的朋友都拿它当WRF的初始场和边界场。它比早期NCEP再分析资料分辨率更高、时效也更好尤其是0.25度版本的FNL几乎成了近实时模拟的“标配”。而num_metgrid_levels这个参数是WRF运行时namelist.input里domains部分的一个关键项它的作用是告诉real.exe你手里的metgrid数据也就是met_em文件里面到底包含了多少个三维气压层。先说结论省得大家后面绕弯子num_metgrid_levels的值应当等于你的FNL数据经过ungrib和metgrid之后实际写进met_em文件里的三维层数。它不是模式的分层数不是你在namelist.input里随便拍脑袋填的。很多人第一次遇到这个报错第一反应是去改e_vert实际上这个参数和e_vert完全是两回事——e_vert是WRF模式自身的eta分层数代表着模式内部想用多少层来模拟大气而num_metgrid_levels是外部再分析数据喂进来的层数表示的是“输入数据有多少层”。这俩一个管输入一个管模式自身结构谁也不能替代谁。这篇东西我打算按“问题怎么出现 - 为什么会出现 - 怎么诊断 - 怎么修复 - 常见坑”的顺序来写。如果你正在被这个报错折磨可以直接跳到第4节如果你想搞清楚底层逻辑建议从头看一遍因为这个问题的根源几乎都是对FNL数据本身不够了解。2. 为什么FNL数据的层数如此“善变”搞清楚num_metgrid_levels为什么容易对不上先要理解FNL数据本身有多“善变”。很多用户以为FNL是一种固定格式的数据只要文件名写着fnl里面的垂直层数就应该是固定的。实际上NCEP这些年在FNL产品上做过多次调整数据结构、水平分辨率、垂直层数都变过。你从不同渠道下载的数据哪怕都叫FNL内部结构也可能不同。2.1 FNL家族不同分辨率、不同时期层数不同目前大家在模拟里常用的主要有两类FNL一类是老一代的1度数据通常标记为fnl_1x1或类似命名这一类数据在2015年之前非常普及很多老教程、老脚本都是基于它写的另一类是0.25度数据标记为fnl_0p25或fnl_0.25分辨率更高但数据结构和层数变化也更复杂。从垂直层数上看老版本的1度FNL数据ungrib之后得到的中间文件常见是26层或27层而0.25度的FNL数据由于NCEP调整了等压面层的定义和数量ungrib之后常见是34层。注意我这里用了“常见”两个字为什么不敢把话说死因为FNL在不同年份、不同月份、甚至不同批次发布的数据垂直层数都可能有差异。NCEP在升级GFS模式的时候会连带调整FNL产品的输出层今天你下载的数据是34层过几个月再下载同一类型的FNL可能就变成了35层或别的数值。这在气象圈里是真实发生过的事情也正因为如此网上的教程里关于num_metgrid_levels该填多少答案五花八门。2.2 num_metgrid_levels到底该听谁的既然FNL层数不固定那num_metgrid_levels应该听谁的答案是听数据本身的。你的FNL数据经过WPS处理后实际得到多少层这个参数就填多少。它不是靠记忆或者抄别人脚本能解决的必须实测。有人可能会问既然ungrib之后要经过metgrid插值那metgrid会不会把层数改掉正常情况下不会。metgrid.exe做的事情主要是把ungrib生成的三维数据从等压面坐标转换到模式区域的规则网格上垂直方向仍然保留原始的等压面层数然后原封不动写进met_em文件。所以整个链条的逻辑是这样的FNL原始grib2文件里的三维等压面层数 - ungrib中间文件FILE文件的层数 - met_em文件里的层数 -num_metgrid_levels需要填的数值。中间没有哪一个环节会无中生有地增加或减少层数除非你的操作有问题比如漏了文件、用错Vtable这些后面讲。弄明白这条逻辑链很多困惑就迎刃而解了。你之所以会在real.exe阶段看到num_metgrid_levels不一致的报错本质上就是这条链节上某一环出了问题要么是namelist里写死了旧数值要么是多个时次的数据本身不一致要么是数据在下载或处理过程中产生了缺损。2.3 另一个隐藏陷阱Vtable与数据源不匹配除了FNL本身层数变化之外还有一个经常被忽视的因素Vtable的选择。WPS里的ungrib.exe本身并不关心你用的是FNL还是ERA5它只认Vtable。Vtable的作用是告诉ungrib怎么从grib2文件中提取变量名和垂直层级。如果你用FNL数据但Vtable用的是Vtable.GFS这没问题因为FNL本来就是GFS模式的分析产物变量组织方式基本兼容但如果你不小心把数据源混了比如某些时次用了ERA5或者CFSR数据却仍然用Vtable.GFS去跑ungenrib那就很容易出问题。轻则变量提不全重则中间文件的层数不对或者变量名错位最后反映到num_metgrid_levels上就是各种莫名其妙的报错。我见过一个真实的案例某位同学从不同镜像站下载FNL数据其中一部分是0.25度另一部分文件名看着像0.25度实际是旧版1度数据但Vtable用的都是同一个。ungrib跑完以后不同时次的FILE文件层数不一样前面几个时次27层后面几个34层metgrid生成met_em文件时一路报错最后real根本跑不起来。这种问题靠改参数是救不了的只能从源头把数据统一。提示每次换数据源、换数据版本之后不要想当然沿用旧的namelist.input。把FNL数据层数当成一个需要重新验证的变量而不是一个固定常量才能彻底摆脱这类问题。3. 三层诊断法快速确认你的数据到底有几层遇到num_metgrid_levels报错第一步不是去改参数而是先搞清楚你的数据现在到底有几层。我总结了一套“三层诊断法”从原始数据一路查到met_em文件整个过程不超过十分钟但能精准定位问题在哪一环。3.1 诊断第1步从原始grib2文件入手如果你手头的FNL数据还是grib2格式可以用wgrib2或者grib_ls先看一眼。我这里推荐wgrib2处理NCEP的grib2文件时它最顺手。比如你想看某个FNL文件里等压面层的分布可以这样操作wgrib2 fnl_20240101_00_00.grib2 | grep : | awk -F: {print $6} | sort -u这条命令的原理是把所有记录的层级信息提出来排序去重后显示。如果输出里有一大串数字而且明显是气压值比如1000 975 950 925 900 ... 10 7 5 3 2 1数一下有多少个这就是原始气压面的层数。注意有些变量是地面层或者边界层变量提出来的时候要过滤掉只看气压层相关的记录。另一种更直观的办法是利用grib_ls如果安装了ecCodesgrib_ls -p typeOfLevel,levelRange -w typeOfLevelisobaricInhPa fnl_20240101_00_00.grib2这条命令只筛选等压面层输出的条数基本就是三维层数。如果命令报错或者没有输出说明数据里等压面层的组织方式可能比较特殊那就直接跳到第2步看ungrib的产物。3.2 诊断第2步检查ungrib中间文件ungrib跑完以后会生成以FILE:开头的中间文件如果你在namelist.wps里设置了io_form_metgrid2或者ungrib的输出格式是netCDF那就可以用ncdump直接查看层数。这是我最推荐的一步因为ungrib已经帮你把原始grib2里乱七八糟的变量组织成了标准的中间格式层数一目了然ncdump -h FILE:2024-01-01_00 | grep -i lev正常来说输出里会有一行类似lev 34 ;的定义。这就是中间文件实际的三维层数。我强烈建议把所有时次的FILE文件都查一遍因为只查一个时次可能会漏掉“多时次不一致”的情况for f in FILE:*; do echo $f: $(ncdump -h $f | grep -i lev ); done如果每个时次输出的层数都相同说明ungrib这一环没问题如果有的时次是34有的时次是27那恭喜你找到问题了——你的数据源混用了。这时候改参数没用要把异常时次的数据找出来替换掉。3.3 诊断第3步核对met_em文件属性如果ungrib中间文件这一步看起来没问题但real.exe还是报错那就需要检查metgrid的产物——met_em文件。met_em文件是一个netCDF格式文件里面有几个全局属性直接记录了WPS处理过程中的关键设置其中就包括num_metgrid_levelsncdump -h met_em.d01.2024-01-01_00.nc | grep num_metgrid_levels这里输出的是一个整数值比如num_metgrid_levels 34 ;这个值就是real.exe将来要读到的层数。如果你的namelist.input里填的也是34那就应该能正常跑如果namelist里填的是27就会报“nlevels specified (27) not equal to nlevels in data file (34)”。所以这一步是最有“裁决力”的因为它直接对应报错信息里的nlevels in data file。多个时次时建议一次性扫描所有met_em文件for f in met_em.d01.*.nc; do echo $f: $(ncdump -h $f | grep num_metgrid_levels); done只要所有时次的met_em属性一致且与namelist.input里的数值一致这个问题就算彻底排除了。4. 实操修复从WPS到WRF的完整处理流程诊断确认之后修复就顺理成章了。根据我的经验修复过程其实就三件事清理旧产物、统一数据源后重建中间文件、把namelist.input里参数改成实测值。下面按完整流程走一遍。4.1 清理现场删除旧的中间文件和met_em很多人在排查时忽略了一个细节WPS运行后生成的FILE文件和met_em文件是“残留”的。如果你换了数据源或改了参数后直接重跑ungrib和metgrid有些文件因为时间戳或缓存的原因并不会被覆盖导致你排查的时候看到的还是旧数据。为了避免这种“幽灵文件”干扰我建议在处理问题之前先把现场清理干净。在WPS目录下执行rm -f FILE:* met_em.*如果你不确定自己有没有误删重要文件可以先看一眼ls FILE:* met_em.* 2/dev/null | wc -l确认一下数量再删。这个操作不会影响geogrid的输出所以可以放心执行。删完之后这一步的价值在于保证后面重新生成的每个文件都是基于当前数据和当前配置的排查结果可信。4.2 统一数据源并重建WPS中间文件清理现场后最关键的一步是确认所有时次用的FNL数据是同一版本、同一分辨率、同一来源。这一步不要只看文件名最好用前面的诊断方法逐个验证。确认无误后重新做链接和ungrib./link_grib.csh /data/fnl/fnl_20240101_00_00.grib2 /data/fnl/fnl_20240101_06_00.grib2 ./ungrib.exe这里注意一点link_grib.csh可以一次传多个文件也可以使用通配符但顺序很重要ungrib会按照链接的顺序逐个处理生成FILE文件。建议在脚本里把文件名写全或者用排序后的通配符避免时次乱掉。ungrib跑完之后立刻用第3节的方法检查所有FILE文件的层数。这一步不能省因为ungrib失败时经常只生成部分时次的FILE文件如果不检查就直接跑metgrid后面real.exe还是会报错。确认层数全部一致后再运行metgrid./metgrid.exemetgrid跑完之后同样立刻检查met_em文件里的num_metgrid_levels属性。这一步的检查结果就是我们配置namelist.input的依据。4.3 修改namelist.input并重跑real.exe现在打开WRF目录下的namelist.input找到domains部分把num_metgrid_levels改成刚才从met_em属性里读到的值。例如domains time_step 60, max_dom 1, e_vert 45, num_metgrid_levels 34, p_top_requested 5000, ... /这里有一个非常容易踩的坑有些人在修改num_metgrid_levels的时候顺手把e_vert也改了以为两者要保持一致。实际上不需要。e_vert是WRF模式内部垂直分层的数量你可以设置成45层、50层、60层这取决于你的模拟需求和计算资源与外部数据层数没有直接关系。real.exe读取met_em数据的34层之后会通过垂直插值把它们映射到你设定的45层eta坐标上。所以这两个参数各有各的职责别混为一谈。修改完namelist.input后重新运行real.exe./real.exe如果一切顺利会生成wrfinput_d01和wrfout_d01等文件然后就可以继续跑wrf了。这里建议在跑real的时候不要直接后台运行先在前台跑一次看到正常结束退出再纳入批处理脚本。因为real的报错信息一闪而过后台运行容易错过关键日志。4.4 自动化校验脚本参考手工操作跑一次没问题但如果你的工作流涉及很多时次、很多天的数据以后每次下载完FNL都担心层数变化那就太累了。我建议写一个简单的校验脚本把所有时次的met_em层数属性一次性拉出来比对。下面是一个Python脚本参考用到了netCDF4库import glob import netCDF4 as nc files sorted(glob.glob(met_em.d01.*.nc)) levels set() for f in files: ds nc.Dataset(f) nlev ds.getncattr(num_metgrid_levels) levels.add(nlev) print(f, nlev) ds.close() if len(levels) 1: print(All files have num_metgrid_levels , levels.pop()) else: print(WARNING: inconsistent num_metgrid_levels:, levels)把这段脚本放在WPS目录下每次跑完metgrid后执行一遍如果输出所有时次层数一致就可以放心进入real.exe如果不一致脚本会直接报警。这个小工具帮我省了无数次半夜排查的时间真心推荐给大家。注意自动化校验的前提是io_form_metgrid2也就是metgrid输出netCDF格式。如果你的配置用的是旧的热带二进制格式ncdump和netCDF4都读不了建议统一改为2方便后续排障。5. 常见问题速查与实战心得最后把这类问题常见的报错现象、可能原因和解决办法整理成一个速查表方便大家对照定位。表格里无法覆盖所有细节但基本囊括了我这些年遇到的90%情况。5.1 典型报错和解决对照表报错现象大意出现阶段可能原因解决思路ERROR: nlevels specified (27) not equal to nlevels in data file (34)real.exenamelist.input里num_metgrid_levels与met_em层数不符以met_em属性值为准修改num_metgrid_levelsERROR: The number of levels in metgrid output does not match namelistreal.exe同上本质是同一种情况同上部分时次met_em正常部分报错metgrid或real数据源混用不同时次FNL层数不同找出异常时次重新下载统一版本数据重建中间文件ungrib生成的FILE文件层数明显偏少ungribFNL文件缺失气压层变量链接文件时漏掉部分文件检查FNL原始文件是否完整重新link和ungribncdump找不到lev维度诊断阶段FILE文件不是netCDF格式或ungrib输出格式非netCDF确认io_form_ungrib设置改用其他方式检查如wgrib一直报错但参数已改对real.exemet_em文件存在旧缓存未重新生成删除FILE和met_em旧文件重跑WPS5.2 几个容易忽视的细节第一不要迷信网上的教程数值。很多博客和论坛帖子会直接告诉你“FNL数据固定填34”或“固定填27”这类建议在某个时间点可能是对的但FNL产品在持续更新今天填34能跑下次下载数据可能就要改成35。我现在的习惯是每次拿到一批新FNL数据都会先跑一小段测试用第3节的命令确认层数之后再开始批量处理。这个习惯帮我避免了好几次连夜重跑数据。第二注意区分“层数”和“垂直坐标类型”。FNL数据里除了等压面层还有位势高度层、边界层等变量ungrib在提取的时候只把Vtable里定义的气压层变量当作三维场处理。如果你下载的FNL数据刚好缺少某个气压层的变量或者数据文件在传输过程中损坏了ungrib可能把某个层的变量跳过导致中间文件层数少一层。这种问题用ncdump检查FILE文件时很容易发现因为层数会比预期少而且报错时通常伴随变量缺失的警告。遇到这种文件直接重新下载不要浪费时间修复。第三数据源统一性怎么强调都不过分。我见过最隐蔽的问题是用户从两个镜像站下载数据文件名看起来一模一样甚至文件大小也差不多但内部层数不同。这种情况靠肉眼根本看不出来只能靠校验脚本把每个时次的层数拉出来对比。所以我把上面那段Python校验脚本当成了固定流程的一部分每次跑WRF都必须执行一遍防患于未然。第四如果你的问题发生在运行real.exe之前也就是metgrid阶段就报错那大概率不是num_metgrid_levels参数本身的问题因为WPS阶段并不读namelist.input。这时候要回头检查ungrib中间文件看看是不是变量缺失或者Vtable配置错误。很多人在这个阶段翻车是因为他们用Vtable.GFS处理了非GFS来源的数据或者中间文件根本没生成成功。第5也是我个人觉得最实用的一点把num_metgrid_levels当成一个“活参数”。在写批处理脚本时不要把它硬编码在namelist.input里而是通过自动检测met_em属性动态生成配置文件。比如可以用一行shell先读取出层数再替换模板文件里的占位符NLEV$(ncdump -h met_em.d01.$(date %Y-%m-%d)_00.nc | grep num_metgrid_levels | awk -F {print $2} | tr -d ;) sed -i s/^ num_metgrid_levels.*/ num_metgrid_levels ${NLEV},/ namelist.input虽然写法简陋了一些但核心思想是对的让数据自己告诉你该填多少而不是让脚本去猜数据。这一招在批量处理多年数据、自动化运维模拟系统的时候特别管用。踩过这次坑之后我的所有WRF自动化流程里都加入了这层校验之后再也没有因为num_metgrid_levels的问题在半夜被叫醒过。