做中尺度气象模拟的老哥应该都有这种体会驱动数据选得好不好直接决定整条WRF链路能不能跑通。ERA5这份再分析资料分辨率0.25°、逐小时输出最近几年几乎成了科研和工程项目的标配。今天这篇实战笔记我拿WRFV4.4搭配ERA5完整走一遍单层嵌套配置从数据怎么下载和处理到namelist.wps、namelist.input怎么写最后附上我踩过的一堆报错和排查方法。内容偏流水账式实操适合刚接触WRF但已经被各种教程绕晕的新手也适合想从多层嵌套降级到单域节省算力的老手参考。1. 项目背景与前置准备1.1 为什么用ERA5驱动WRFV4.4ERA5是欧洲中期天气预报中心ECMWF发布的第五代全球再分析资料空间分辨率0.25°×0.25°时间分辨率逐小时垂直方向从1000hPa到1hPa共137层。跟经常用的FNL和GFS比ERA5最大的优势是历史年代覆盖长且有稳定的重分析版本特别适合做过去个例的模拟、气候统计和极端天气复盘。WRFV4.4对ERA5的支持已经很成熟WPS里自带的Vtable.ERA5可以直接用不需要像老版本那样还要自己东拼西凑变量表。我之前用FNL跑一个台风个例GFS背景场在海上湿度偏差偏大换到ERA5之后台风路径和降水落区都好了不少。当然这不是说ERA5一定比FNL强但对很多区域个例来说ERA5的初始场和边界场细节确实更稳。再说单层嵌套。很多人一上手就喜欢搞三层嵌套d01套d02再套d03觉得网格越细越高级。实际跑下来经常是计算量翻好几倍报错也跟着翻倍。如果你的模拟区域不大、目标明确单层嵌套反而更务实只需要一个域、一份边界文件、一套物理参数跑起来轻松排查问题也快。我自己的项目里很多12km甚至9km分辨率的实验就是用单域完成的结果完全够用。1.2 软件环境与依赖清单先说环境。我这次用的是一台64核的Linux工作站系统是Ubuntu 20.04编译器是gfortran 9.4MPI用的是mpich。WRF和WPS的版本分别是4.4和4.4这俩要配套WPS版本太老会不认新的Vtable。编译之前先装依赖库netcdf-c、netcdf-fortran、jasper、libpng、zlib、hdf5。WRF需要netcdf-fortranWPS还需要jasper和libpng用来处理GRIB格式。如果你打算用CDO或Python处理数据再装一个conda环境里面放xarray、cdo、cfgrib就行。我用的是mamba装这些东西很快。环境变量这里容易踩坑我每次都检查这几项export NETCDF/opt/netcdf export PATH$NETCDF/bin:$PATH export LD_LIBRARY_PATH$NETCDF/lib:$LD_LIBRARY_PATH export JASPERLIB/opt/jasper/lib export JASPERINC/opt/jasper/include export WRF_DIR/home/user/WRFV4.4然后按顺序编译先WRF选“34”表示gfortrandistributed memory再选嵌套方式一般选“1”基本嵌套即可。接着编译WPS最后看到“The executables are ready”才算完。我见过太多人卡在WPS编译缺jasper基本就是JASPERLIB和JASPERINC没设置对或者32位库和64位库混了。2. ERA5数据下载与预处理2.1 CDS申请与下载参数选择ERA5下载走的是CDSClimate Data Store平台需要在ECMWF官网注册账号然后安装cdsapi库。申请过程不复杂拿到url和key之后写到~/.cdsapirc里就能用。下载驱动WRF的数据时我通常同时拉两个数据集气压层数据reanalysis-era5-pressure-levels和单层数据reanalysis-era5-single-levels。气压层变量选这些import cdsapi c cdsapi.Client() c.retrieve( reanalysis-era5-pressure-levels, { product_type: reanalysis, variable: [ geopotential, specific_humidity, temperature, u_component_of_wind, v_component_of_wind, vertical_velocity, ], pressure_level: [ 1000, 975, 950, 925, 900, 850, 800, 750, 700, 650, 600, 550, 500, 450, 400, 350, 300, 250, 225, 200, 175, 150, 125, 100, 70, 50, ], year: 2023, month: 01, day: [01, 02, 03, 04, 05, 06, 07, 08], time: [00:00, 06:00, 12:00, 18:00], area: [42, 105, 20, 125], format: grib, }, era5_pl.grib)注意area参数顺序是北、西、南、东也就是先纬度后经度。上面这个区域大概覆盖了华北到华中一块你要根据自己的模拟域中心去改。时间步长选6小时一次就够了如果做天气尺度模拟6小时间隔完全能支撑边界条件更新。单层数据里除了常规的10米风、2米温度、2米露点、海平面气压还必须包含土壤温度和土壤湿度c.retrieve( reanalysis-era5-single-levels, { product_type: reanalysis, variable: [ 10m_u_component_of_wind, 10m_v_component_of_wind, 2m_temperature, 2m_dewpoint_temperature, mean_sea_level_pressure, sea_surface_temperature, skin_temperature, soil_temperature_level_1, soil_temperature_level_2, soil_temperature_level_3, soil_temperature_level_4, volumetric_soil_water_layer_1, volumetric_soil_water_layer_2, volumetric_soil_water_layer_3, volumetric_soil_water_layer_4, sea_ice_cover, snow_depth, ], year: 2023, month: 01, day: [01, 02, 03, 04, 05, 06, 07, 08], time: [00:00, 06:00, 12:00, 18:00], area: [42, 105, 20, 125], format: grib, }, era5_sl.grib)有一段时期我偷懒没下土壤变量结果real.exe跑完wrfinput里的土壤湿度全是初始默认值模拟出的近地面温度直接偏了2℃。后来规规矩矩把4层土壤温度、4层土壤体积含水量都拉下来问题才解决。所以这一步不要省。2.2 GRIB文件与Vtable选择下载完成后先检查文件是不是正常。我习惯用grib_ls或者wgrib2看一眼比如grib_ls era5_pl.grib | head -50这一步能确认变量名、气压层数量、时间是否齐全。如果发现变量shortName和Vtable对不上后面ungrib肯定报错。接下来进入WPS目录把下载的GRIB文件软链接过去cd /home/user/WPS4.4 ln -sf /path/to/era5_pl.grib . ln -sf /path/to/era5_sl.grib . ./link_grib.csh era5_pl.grib era5_sl.griblink_grib.csh会生成一堆GRIB链接文件名字类似GRIB:2023-01-01_00到GRIB:2023-01-08_18。注意它按文件名里是否包含日期时间戳来生成前缀如果CDS下载的文件名不含日期就需要手动把文件重命名成带日期格式或者用link_grib.csh配合-p参数设置前缀。我一般直接下载时在脚本里把文件名改成era5_pl_202301.grib这种然后再手动建链接目录。关键一步是选择Vtable。WPS自带的Vtable在ungrib/Variable_Tables/目录下找到Vtable.ERA5复制到运行目录ln -sf ungrib/Variable_Tables/Vtable.ERA5 Vtable然后编辑namelist.wps里的ungrib段设置ungrib out_format WPS, prefix ERA5, /运行./ungrib.exe ungrib.log tail -f ungrib.logungrib会把气压层和单层数据统一处理成中间格式文件文件名形如ERA5:2023-01-01_00。如果下载的是NetCDF格式ungrib直接读不了。这里有两个解决办法一是回到CDS下载时改选GRIB格式二是用CDO先把NetCDF转成GRIB。我个人强烈建议下载时直接选GRIB省得后面转换时数据单位、网格定义出幺蛾子。2.3 数据缺失与时间处理技巧ERA5下载最让人头疼的就是排队和断流。一个大区域、多变量、多时次的数据在CDS队列里排队半小时是很正常的。网络断掉就得重新下单非常磨人。我的做法是写一个带重试的Python脚本把每个月的请求拆开下载完一个再下下一个。同时下载完成后写个校验文件检查日期的完整性for f in ERA5:2023-01-01_00 ERA5:2023-01-01_06 ERA5:2023-01-01_12 ERA5:2023-01-01_18; do ls -lh $f doneungrib生成的中间文件如果缺某一时次后面metgrid一定会报错。所以我会一次性把整个模拟时段的文件都检查一遍。还有一个坑如果你想跑10天但时间区间只下了8天那么lid这2天的边界条件根本不存在real.exe跑到一半就会报“Could not find matching time in input file”。这种问题只能靠细心没有捷径。3. WPS单层嵌套配置从geogrid到metgrid3.1 单层嵌套的域设置思路单层嵌套说白了就是只定义一个domain没有父域和子域的关系。跟多层嵌套比它少了parent_grid_ratio、i_parent_start这些参数的手动配合跑起来省心很多。但省心不代表随便画。域的位置和大小还是得按物理逻辑来模拟中心尽量对准研究区域域的边界最好离目标区至少5到10个网格距离否则边界条件会直接污染目标区域的模拟结果。比如你要看某个城市周边的暴雨只把城市圈在域里边界跨在山脉上那初始场和边界场在陡峭地形处非常容易产生虚假重力波。网格尺寸和网格数也要匹配。经验公式是时间步长约等于6倍网格距单位公里比如dx12kmdt建议72秒左右。网格数太多会导致单步计算量暴涨我见过有人把300×300的网格放在单层跑结果内存不够直接卡死。一般单层域e_we和e_sn在150到250之间比较合适。3.2 namelist.wps逐项解释下面是我常用的一套单层嵌套的namelist.wpsshare wrf_core ARW, max_dom 1, start_date 2023-01-01_00:00:00, end_date 2023-01-08_18:00:00, interval_seconds 21600, io_form_geogrid 2, / geogrid parent_grid_ratio 1, i_parent_start 1, j_parent_start 1, e_we 181, e_sn 181, geog_data_res default, dx 12000, dy 12000, map_proj lambert, ref_lat 30.0, ref_lon 110.0, truelat1 30.0, truelat2 60.0, stand_lon 110.0, geog_data_path /home/user/WPS_GEOG / ungrib out_format WPS, prefix ERA5, / metgrid fg_name ERA5, io_form_metgrid 2, /这里max_dom1就是单层嵌套的开关。parent_grid_ratio、i_parent_start、j_parent_start虽然对单域没有实际意义但必须保留WPS4.4版本检查不到这些字段会直接退出。投影方式对中纬度区域我基本用lambert低纬度地区可以考虑mercator极地区域用polar。truelat1和truelat2一般设成模拟区域上下边界的纬度stand_lon设成区域中心经度。这些参数影响网格变形不要随便填。geog_data_path要指向地理静态数据目录WPS_GEOG里面必须有geogrid用到的地形、土地利用数据。如果路径错了geogrid会提示找不到HGT_M之类的地形源这一步必须先跑通。执行./geogrid.exe看到Successful completion of geogrid就说明geo_em.d01.nc生成成功。接着按之前配置运行ungrib最后运行metgrid./metgrid.exemetgrid成功后会生成met_em.d01.2023-01-01_00.nc等一系列文件同时终端会输出处理进度。注意检查met_em文件覆盖了完整模拟时段一个都不能少。3.3 ungrib与metgrid的执行与检查这里补两个细节。第一ungrib运行前务必确认Vtable链接正确。如果Vtable指向了别的数据集模板ungrib处理到一半会报变量找不到。我习惯运行后直接打开ungrib.log搜索“ERROR”和“Warning”正常的话只会出现“Data processed”之类的提示。第二metgrid其实是一个纯前处理步骤不做任何物理计算但它的文件命名和后缀必须跟WRF的real.exe对接上。最直观的检查方法是ls met_em*看看时间戳是否跟namelist.wps里start_date、end_date一致。如果发现文件日期偏了一天多半是interval_seconds或日期字符串格式写错了。另外metgrid会读取geo_em.d01.nc里的地形和土地利用信息所以geogrid和metgrid必须用同一套WPS目录和同一个namelist.wps不能前面一个版本后面一个版本否则报错信息会让人摸不着头脑。4. WRFV4.4 namelist.input单层嵌套配置实战4.1 时间积分与网格参数设置WPS处理完真正决定模拟质量和稳定性的就是namelist.input。单层嵌套的namelist.input相比多层嵌套没有那么多嵌套块但核心参数一个都不能错。我的12km单域标准配置如下time_control run_days 0, run_hours 12, run_minutes 0, run_seconds 0, start_year 2023, start_month 01, start_day 01, start_hour 00, end_year 2023, end_month 01, end_day 02, end_hour 00, interval_seconds 21600, input_from_file .true., history_interval 60, frames_per_outfile 1, restart .false., io_form_history 2, io_form_restart 2, io_form_input 2, io_form_boundary 2, /这里run_days、run_hours加起来是积分时长但我发现很多新手会误以为只填积分时长就行其实WRF用start_*和end_*来确定整个模拟窗口。real.exe会同时参考WPS生成的met_em文件和namelist.input里的start/end两边不一致就会报错。interval_seconds必须和WPS里的设置一致也就是21600秒6小时这是边界条件更新的间隔不能乱改。history_interval 60表示输出间隔60分钟一次。如果你模式输出太密磁盘会爆炸单层12km一般是1小时输出一次足够。接着是domainsdomains max_dom 1, e_we 181, e_sn 181, e_vert 50, dx 12000, dy 12000, p_top_requested 5000, num_metgrid_levels 38, num_metgrid_soil_levels 4, /e_vert50表示垂直方向50层这对12km模拟够了。如果想看边界层细节更清楚可以加到60甚至70层但计算成本会增加。p_top_requested5000表示模式顶设在50hPa对应ERA5气压层数据里50hPa那一层如果下载数据顶层只到100hPareal就直接报错。num_metgrid_levels38这里要跟实际气压层数对上。我在2.1节下载的气压层列表有26层但ERA5原始是137层ungrib处理时会根据你下载的气压层数生成中间数据。这里num_metgrid_levels要填你下载并处理后的实际气压层数量。我上面列的是26层但实际跑不同项目会变。保险办法处理完ungrib后用ncdump -h met_em.d01.2023-01-01_00.nc | grep num_metgrid_levels看一下真实值然后填进去。别硬抄别人的配置。4.2 物理参数化方案选择物理方案这块单层12km我常用的组合是physics mp_physics 8, ra_lw_physics 4, ra_sw_physics 4, radt 10, sf_sfclay_physics 1, sf_surface_physics 2, bl_pbl_physics 1, bldt 0, cu_physics 5, cudt 5, num_soil_layers 4, aer_opt 0, /mp_physics8是Thompson微物理方案适合云降水和中尺度模拟尤其在12km网格下表现稳定。ra_lw_physics4和ra_sw_physics4是RRTMG长波和短波方案算得快结果也不错。sf_sfclay_physics1是MM5相似理论近地面层方案跟sf_surface_physics2Noah陆面过程是经典搭配。bl_pbl_physics1是YSU边界层方案在中尺度模拟里用得很广泛。cu_physics5是积云参数化方案Grell-Freitas。12km网格其实处在对流可分辨和不可分辨的过渡区用不用积云参数化一直有争议。我的经验是如果是夏季强对流个例可以试试cu_physics0也就是关闭积云参数化看对流能不能被模式显式解析出来。但对大多数业务仿真实战开着Grell-Freitas更稳。这些方案不是绝对的但新手别一上来就乱调。先用一组成熟组合把整个流程跑通再根据模拟结果一个个换方案对比。4.3 real.exe与wrf.exe运行注意事项运行real.exe之前把met_em文件软链接到运行目录cd /home/user/WRFV4.4/test/em_real ln -sf /path/to/met_em.d01.* .然后./real.exe跑完看rsl.out.0000末尾出现SUCCESS COMPLETE REAL_EM INIT就说明初始化和边界条件生成成功。正常会生成wrfinput_d01和wrfbdy_d01两个文件注意单层嵌套也要有wrfbdy_d01这是有限区域模式的边界条件不能少。如果real.exe报错最常见的是“Mismatch between namelist and wrfbdy”。这个问题通常有两个来源一是start_date或end_date跟WPS不一致二是e_we、e_sn、dx这些网格参数跟geo_em或met_em不一致。逐一核对就行。接着运行wrf.exempirun -np 24 ./wrf.exe实时监控输出tail -f rsl.out.0000每次时间步迭代都会输出一行时间看到某个时间点不再前进大概率是崩了或卡住。这时转去查rsl.error.0000里面会有更详细的信息。单层嵌套的CFL条件一般用dt 6 * dx_km估计比如12km就用72秒保守点用60秒。如果模式运行几个时间步就报CFL先降时间步长再看是不是地形太陡或者初始场在边界处有数值噪声。5. 关键报错排查与避坑实录5.1 数据流环节常见报错速查我整理了一份我自己排查时常用的报错速查表基本覆盖了ERA5驱动WRFV4.4整个流程的高频问题。报错位置典型报错信息常见原因解决办法ungrib.exeERROR: Error in ext_pkg_write_field输出中间文件权限不足或磁盘满检查运行目录写权限清理旧文件确认中间文件名不冲突ungrib.exeERROR: Vtable: variable X not foundVtable与GRIB变量名不匹配用grib_ls检查变量shortName替换正确的Vtable或修改Vtablemetgrid.exeERROR: Cannot open file met_em...ungrib没跑通或时间戳不一致检查中间文件是否生成确认日期与namelist一致real.exeERROR: Could not find matching time in input filemet_em文件缺失对应时次检查WPS的start/end和interval缺哪个补哪个real.exeERROR: Mismatch between namelist and wrfbdynamelist.input与WPS配置不一致核对所有时间、网格参数保证两边数值完全一致wrf.exeERROR: Wrf Allocate_arrays: Error opening file: wrfbdy_d01wrfbdy_d01不存在先跑通real.exe生成wrfbdy_d01wrf.exeforrtl: severe (174): SIGSEGV内存不足或数组越界减少并行进程数检查e_vert和内存占用或减小模拟域wrf.exeCFL数值不稳定减小dt检查地形和嵌套边界降低p_top_requested5.2 ERA5专有报错与数据坑ERA5数据虽然好用但坑也不少。第一个坑是变量shortName对不上。ERA5在CDS里的变量名跟WPS的Vtable.ERA5默认变量名不完全一致比如单层下载时写的是soil_temperature_level_1而Vtable里可能要求sotl或者STL1。遇到这种情况不要着急改Vtable先查Vtable.ERA5里具体写的什么shortName然后去CDS下载脚本里对应用那套名字。第二个坑是气压层数量。WRF要求num_metgrid_levels和ungrib实际生成的气压层数一致。有人从网上抄了个namelist填num_metgrid_levels 38但自己下载的ERA5只选了20层real就会报错或直接crash。我用了一个土办法real.exe跑之前先看met_em文件里的层数ncdump -h met_em.d01.2023-01-01_00.nc | grep num_metgrid_levels然后把输出值填进namelist,基本不会错。第三个坑是单层和气压层数据的时间对齐。有时候气压层下载成功单层数据因为CDS排队问题少了一个时次metgrid不会提醒但real和wrf跑到某个时刻就会因为缺少土壤场数据而报错。所以下载完成后最好写个小脚本把两个文件里的时间列表提取出来对比一下。5.3 运行崩溃与结果异常排查WRF跑着跑着NaN或者风场异常这类问题最让人抓狂。我的经验是先看是不是初始场问题。把wrfinput_d01里的2米温度和10米风跟ERA5原始数据对比一下如果差太多大概率是ungrib处理时变量单位或缺失值出了问题。地形数据也可能是元凶。geogrid用的WPS_GEOG如果路径配错或者地形分辨率设置得太粗糙模式会在陡峭区域产生虚假重力波。典型表现是跑几个小时后格点风速出现正负交替的振荡然后CFL崩掉。这时候检查geo_em.d01.nc里的HGT_M看看地形是否合理。还有一个容易被忽略的是p_top_requested。想把模式层顶抬高但又没有下载更高层的气压层数据real会强行外推造成模式顶层数值噪声。我曾经把p_top_requested设成500050hPa结果数据顶层只有100hPa模式顶上的风场乱成一团。后来老老实实把气压层下载到50hPa问题才解决。5.4 一次完整排查实战记录说一个我最近真实碰到的排查过程。用ERA5驱动WRFV4.4跑12km单层嵌套real.exe正常wrf.exe跑了几百步之后在某个时次直接报forrtl: severe (408): segfault。我第一反应是内存不够于是把并行进程数从48降到24重跑还是崩在几乎同一个时间点。这就不是简单的资源问题了。我打开rsl.error.0000发现崩的时候有类似“NaN detected”的提示。接着检查wrfout文件发现崩点前几个输出时刻在模拟域西南角出现了一个风速异常大的点。回头查met_em文件原来是下载ERA5时area设置的范围刚好切到一块地形很陡的山区ungrib和metgrid没报错但初始场在那个点上产生了很大的地转偏差。解决方法很简单把模拟域向东移动两个格点让边界避开陡峭地形重新跑一遍就稳定了。这件事给我一个教训报错排查不要只盯着WRF自身参数很多时候问题出在更早的WPS和ERA5数据处理阶段。最后再唠叨几句单层嵌套听起来比多层嵌套简单但要把ERA5数据从下载到模拟结果整个链路跑顺细节真不少。我个人这几年最大的体会是遇到报错先看数据有没有问题再看配置有没有前后不一致最后才怀疑模式代码。毕竟WRFV4.4本身已经很成熟绝大部分崩溃都出在前处理或者参数设置上。你先拿一个小区域、短时间窗口把整个流程跑通再去追求分辨率和大规模实验这样最省时间。后面我还会写一篇多层嵌套的配置对比和边界层方案调参记录各位可以先收藏这篇用得着的时候翻出来对一下。