1. 试验前必须弄清楚的几个底层问题1.1 Piggy_Packages 在这套试验里到底帮你解决了什么先说个现象。很多第一次接触 WRFDA 三维变分同化的人最容易卡住的地方反而不是同化理论本身而是“环境装不起来”和“一跑就报错”。WRFDA 对底层依赖库的版本要求非常苛刻netCDF 的 C 接口和 Fortran 接口必须保持一致MPI 的编译器要和构建 WRFDA 时用的一致甚至连 zlib、png、jasper 这些中间库的编译选项都不能随意改。稍有不慎编译阶段就给你来一个不明不白的段错误或者在运行阶段直接提示“Cannot open file”这种你根本不知道去哪查的提示。Piggy_Packages 这套工具链说白了就是把 WRF、WPS、WRFDA 以及各种依赖库的编译安装和模块加载固化成了标准流程。你可以把它的作用理解为“帮你把战场提前打扫干净”它把依赖库安装到统一目录、把环境变量用模块文件管理起来、把每个环节的编译选项都测试过一轮。你在跑三维变分同化试验时不需要再花两周时间去折腾“为什么 wrfda 编译不过去”而是直接进入核心业务——也就是准备观测资料、设计试验方案、分析同化效果。另外还有一点很多人在 Windows 上用虚拟机或者 WSL 跑 WRFDA性能损失明显。Piggy_Packages 的主流部署场景是 Linux 集群或高性能计算节点它已经帮你把跨节点运行、MPI 并行环境的配置都处理好了。这篇帮助文档七的定位就是在整个 Piggy_Packages 环境里走通一个 WRFDA 三维变分同化试验的完整闭环。1.2 为什么单独把三维变分试验拎出来写一篇WRFDA 系统里其实包含了多种分析方案包括三维变分3DVar、四维变分4DVar和混合集合变分Hybrid。我在实际教学和项目支持中观察到80% 以上的人第一次做同化试验都是从 3DVar 入手的。原因很直接3DVar 的计算代价低、对观测资料的要求相对宽松、程序结构也最容易调试。它不像 4DVar 需要额外处理切线性模式和伴随模式也不像 Hybrid 需要同时维护集合预报的扰动逻辑。而且三维变分试验往往是评估一个观测系统、一个误差协方差设置是否正确的最快路径。比如你想知道“如果在这个区域多放 10 个探空站对模式初始场有多大改善”直接做一组 3DVar 试验就能得到比较靠谱的答案。另外 WRFDA 里很多参数的默认值和工作原理也是围绕 3DVar 设计的把这套逻辑吃透了后面再切 4DVar 或者 Hybrid 就会顺很多。所以这篇文档的写法我决定走“实战先行”的路子先把一次完整的 3DVar 试验从准备到跑通再到结果分析的每一步都拆开讲透同时把 Piggy_Packages 环境里特有的注意事项单独标注出来。适合正在做 WRF 模拟、打算引入资料同化或者已经在跑 WRFDA 但总是出各种奇怪问题的同学参考。2. 试验设计一次三维变分同化到底在做什么2.1 三维变分同化的核心思想与角色定位三维变分同化的数学本质可以简单理解为一个带约束的加权最小二乘优化问题。目标函数长这样J(x) 1/2 (x - xb)^T B^(-1) (x - xb) 1/2 (y - H(x))^T O^(-1) (y - H(x))其中 xb 是背景场通常来自上一次预报或 GFS 分析场y 是观测值H 是观测算子把模式变量插值到观测位置并转换成观测量的映射B 是背景误差协方差矩阵O 是观测误差协方差矩阵。这个公式看起来抽象但落到实际试验里它就是两股力量的较量。第一项是背景项的约束告诉模式“不要偏离初始猜测太远因为背景场在大多数区域还是有可信度的。”第二项是观测项的约束告诉模式“观测站上测到的值是硬事实要尽量靠近。”B 矩阵与 O 矩阵的相对大小决定了分析场到底更相信背景还是更相信观测。三维变分里的“三维”是指空间三维意思是分析变量在水平方向和垂直方向上都参与变分求解但不涉及时间维度的资料同化。换句话说3DVar 是在某一个固定时刻把该时刻前后一个时间窗内的观测资料都“当作是这个时刻的观测”来处理不存在时间演变约束。这一点和 4DVar 有本质区别也是为什么 3DVar 更稳定、更省算力。2.2 单点试验理解 B 矩阵的最快方式我第一次接触 WRFDA 时带我的前辈没有让我直接跑真实观测的案例而是先让我做单点观测试验。所谓单点试验就是在模式区域内人为设定一个位置塞进去一条虚假的观测记录然后看分析增量analysis increment即 xa - xb在这个点附近如何从中心向外衰减。听起来很简单但这是检验 B 矩阵是否设置合理的黄金方法。举一个常见场景你在 namelist 里设置了 cv_options 3变分方案采用 CV3基于 NMC 方法统计的误差协方差但模式区域在热带或高分辨率区域默认的 B 矩阵尺度可能与你的网格分辨率严重不匹配。这时如果做单点试验你就会发现分析增量的影响范围要么太小——观测只影响周围一两个格点要么太大——一个单点观测竟然让半个区域都产生了明显扰动。这两种情况都说明 B 矩阵需要重新标定或者选择别的 cv_options。所以建议所有读者在正式做批量同化试验之前先做一个单点试验而且最好分别在冬夏两个时次、高低纬两个区域各做一组。这样可以直观判断 B 矩阵的空间相关尺度是否合理也能在后续排查问题时有一个基准对照组。2.3 试验分类冷启动、循环同化与批量试验三维变分试验按运行方式还可以分成三类实际工作中三类我都会用到但目的完全不同。第一类是单次冷启动试验。流程是获取背景场比如 GFS 0.5 度分析场→ 用 WPS 处理成 WRF 初边界条件 → 直接运行 da_wrfvar.exe 做一次同化分析 → 得到分析场 → 用 update_bc 更新侧边界 → 跑 WRF 预报。这适用于评估“同化某个时刻的观测能否改善初始场”。第二类是循环同化试验。流程是先做一段 WRF 预报作为下一时刻的背景场然后同化该时刻的观测得到的分析场再作为 WRF 预报的初始场预报几个小时后再次同化如此循环往复。这类试验更接近业务同化的模式计算量也更大但能更真实地评估同化系统的持续表现。第三类是批量试验也就是对多个时次、多组观测场景反复运行同一套同化流程做统计评估。批量试验最关键的是脚本化和自动化。我在用 Piggy_Packages 环境时通常会把整个试验流程写成一个 Bash 脚本按日期循环处理。这里有个小技巧每次试验都建立独立的工作目录命名统一为 exp_日期_方案标识避免在反复试验时把中间文件搞混。这个习惯帮我省了不知道多少返工时间。3. 实操环节从零跑通一次 WRFDA 3DVar 试验3.1 Piggy_Packages 环境下的目录规划与依赖加载拿到 Piggy_Packages V2026.1 环境之后第一件事不是急着跑程序而是把目录结构规划好。我的习惯是这样# 主目录 ~/piggy_exp/ |-- wrfda/ # WRFDA 主程序及链接文件 |-- wrf/ # WRF 主程序用于预报 |-- obs/ # 观测资料目录 |-- data/ # 背景场与静态数据 |-- scripts/ # 试验脚本 |-- exp_case01/ # 试验案例一 -- exp_case02/ # 试验案例二Piggy_Packages 一般会提供一个环境加载脚本加载之后 netCDF、MPI、WRFDA 相关的可执行文件路径都会自动设置好。你可以用下面这组命令确认环境是否加载正确module load piggy_packages which da_wrfvar.exe echo $NETCDF mpirun --version这里有一个关键点加载环境之后务必确认 da_wrfvar.exe 的路径是否指向你打算运行的那个 WRFDA 目录。因为如果系统里本来就有另一套 WRFDA 或者 WRF 工具链容易出现 PATH 覆盖的问题。尤其是你之前在别的项目里编译过 WRF环境变量可能会残留。我遇到过一次比较隐蔽的问题加载 Piggy_Packages 之后which da_wrfvar.exe 显示的是旧版本的路径导致跑了半天发现试验结果是旧程序算的直接白干。3.2 namelist 配置的核心参数逐项解析WRFDA 3DVar 试验的 namelist 文件是 namelist.input它放在运行目录下和 WRF 的 namelist.input 结构类似但多了很多同化专属的参数。下面这份是我多次试验后觉得最稳的基础配置直接可以对照修改record1 max_dom 1, start_year 2024, start_month 06, start_day 15, start_hour 12, end_year 2024, end_month 06, end_day 15, end_hour 12, interval_seconds 21600, analysis_type 3D-VAR, cv_options 3, var4d_bin 3600, rtminit_nbhood 75, /这里我最想强调的是 analysis_type 和 cv_options 这两个参数。analysis_type 必须设置为 3D-VAR注意不要漏掉中间那个连字符否则程序直接报错退出。cv_options 控制背景误差协方差的选择CV3 是默认方案用的是 NMC 方法统计出来的全球背景误差协方差对于大多数中纬度试验是够用的如果做的是热带或者区域高分辨率试验建议考虑 CV5 甚至 CV6但需要额外准备 BE 数据集。var4d_bin 是四维变分里的时间窗参数在纯 3DVar 模式下不会真正用到但 namelist 里通常还是会有这一项默认值建议保留 3600。顺便说一句很多初级用户看到 namelist 里那么多参数就慌其实 WRFDA 的 namelist 有比较完善的默认值机制改动项越少越不容易出错。新手阶段你只需要关注几个核心项时间、区域、分析类型、观测文件路径、背景场路径其他参数用默认值反而更稳。3.3 背景场和观测资料的前期预处理背景场这块最常用的是 GFS 的 0.5 度或 1 度分析场。流程是先用 WPS 的 ungrib.exe 把 GFS 的 grib2 数据解压成中间格式再用 metgrid.exe 插值到模拟区域。这一步和在普通 WRF 试验里完全一样但有一个细节需要注意WRFDA 需要的是“未扰动的背景场”也就是说不能直接用 WRF 跑出来的某个时刻的 wrfout 文件作为背景场除非你是做循环同化且已经有相应的边界处理逻辑。冷启动试验里背景场应该来自 WPS 的输出或者干净的 WRF 初始文件。观测资料方面3DVar 支持多种观测类型包括常规探空sound、地面报synop、飞机报airep、卫星辐射率radiance等。在试验初期我建议只使用常规探空和地面报先把流程跑通再逐步加入更复杂的观测类型。因为卫星辐射率的观测算子、质量控制逻辑都要复杂得多一旦出错很难定位问题。WPS 处理完成后会生成 met_em 文件然后用 real.exe 生成 wrfbdy_d01 和 wrfinput_d01。接下来的关键步骤是运行 WRFDA 的观测预处理工具去生成 obs 文件。常见做法有两种一是用 obsproc 工具把原始观测处理成 little_r 格式再读入二是直接准备 little_r 格式的观测文件。我个人的经验是先用一个最简单的观测文件哪怕只有一条记录把流程跑通再逐步增加数据量定位问题会容易很多。3.4 实际运行 da_wrfvar.exe 的完整流程环境检查无误、namelist 配置完成、背景场和观测文件都准备好之后就可以运行三维变分同化程序了。假设你已经在运行目录下做好了链接# 链接背景场和观测文件 ln -sf /path/to/wrfinput_d01 ./fg ln -sf /path/to/obs_gts_2015-06-15_12:00:00.3DVAR ./ob.ascii # 运行三维变分同化 mpirun -np 4 ./da_wrfvar.exe这里说一个新手容易踩的坑fg 这个文件链接名是固定的程序默认读取 fg 作为背景场输入。如果文件名不对程序会在日志里报找不到背景场的错。同理观测文件的默认读取名是 ob.ascii但也可以通过 namelist 里的 obs_filename 参数指定具体看 WRFDA 版本。运行过程会输出大量的标准输出信息关键要看几个指标。一是 cost function 的数值变化正常情况下每一轮迭代outer loopcost 值应该显著下降并且最后趋于收敛。二是观测余差observation departure的统计程序会输出 O-B观测减背景和 O-A观测减分析的均方根值。如果试验配置合理O-A 的均方根通常会比 O-B 小说明同化确实把分析场向观测方向拉近了一些。如果两者几乎没有差别甚至 O-A 比 O-B 还大那就要回头检查观测误差设置或背景场质量了。运行结束后目录下会生成多个关键文件。rej_obs_* 文件里记录了被拒绝的观测及其拒绝原因这是排查观测质量问题的第一手资料。wrfvar_output 是分析场主文件后续更新边界条件会用到。另外还有一个很重要的文件是 fort.900 或类似的诊断文件里面有每个观测点在同化前后的具体数值做单点试验时必须仔细看它。3.5 分析场输出与边界条件更新很多人在这一步直接把 da_wrfvar.exe 跑完就以为大功告成了实际上还差一个关键环节更新侧边界条件。同化过程只修改了初始时刻的分析场但模式预报时还需要侧边界条件随时间变化。如果分析的增量在边界附近和原始边界不一致预报一开始就可能在边界产生虚假的扰动波。WRFDA 专门提供了一个工具来解决这个问题叫做 da_update_bc.exe。运行方式很简单ln -sf ./wrfvar_output ./wrfvar_output ln -sf /path/to/wrfbdy_d01 ./wrfbdy mpirun -np 1 ./da_update_bc.exe运行完成后wrfbdy 文件里的边界条件就通过线性插值方式和分析场保持协调了。这里有个判断技巧执行完 update_bc 后可以对比更新前后 wrfbdy 文件里变量的数值变化如果边界处的位势高度场或温度场发生了大范围突变说明分析场的增量在边界处太剧烈需要考虑缩小同化影响半径或检查背景场。注意 da_update_bc.exe 通常建议用单核运行因为它不涉及大规模并行计算多核运行反而可能出现文件读写竞争。另外如果你做的是嵌套区域试验每一层都需要对应更新各自的 wrfbdy 文件很容易漏掉第二层和第三层。4. 高影响参数与误差协方差设置心得4.1 B 矩阵与 O 矩阵的那些“隐性权衡”三维变分同化里最容易让初学者困惑的不是程序怎么跑而是参数怎么调。你可以把 B 矩阵和 O 矩阵的关系想成天平B 大说明背景场不确定性大分析会更多地靠近观测O 大说明观测误差大分析会更多地保留背景信息。但真正的难点在于B 矩阵并不是只控制“总体权重”它还控制了空间相关尺度。一个格点上的观测增量如何向周围传播、传播多远、在垂直方向怎么衰减都是由 B 矩阵里对应的相关尺度参数决定的。WRFDA 的 CV3 方案里每个变量都有对应的水平相关尺度和垂直相关尺度参数。这些参数在 be.dat 文件里可以通过 WRFDA 自带的 da_tune.exe 工具或直接修改 be.dat 里对应记录来调整。我的经验是高分辨率模拟格距小于 10 公里通常需要把水平相关尺度适当调小否则分析增量会过度平滑而低分辨率模拟则相反尺度太小会导致分析场出现噪声点。不过要提醒一句调 B 矩阵是“牵一发而动全身”的操作。每改动一个参数都要重新做单点试验来检验效果千万不要反复在同一组批量试验里调整 B 矩阵的多个参数那样你最后根本说不清楚是哪个参数带来了改进。4.2 观测误差配置的黄金经验观测误差设置直接决定了一个观测值在同化中的“话语权”。误差设置太小这个观测就会被过度信任可能把局部小尺度噪声带到分析场里误差设置太大这个观测就形同虚设同化前后几乎没差别。WRFDA 里观测误差常见的设置方式有两种。一种是在 namelist 里通过 use_obs_errfac 和相关的 errfac 参数调整全局观测误差比例另一种是在观测文件里直接为每条观测记录指定误差。我建议新手最开始先不要轻易修改默认误差除非你做的是非常特殊的观测类型比如某些新型遥感资料。默认误差值通常来自长期的统计经验在很多区域和场景下是合理的。我曾经犯过一个错误为了追求同化效果把探空观测的误差统一缩小了一半结果单点试验显示分析增量大幅增大看起来“效果很好”但后续 WRF 预报里激发了很强的重力波噪声。后来才明白这是典型的过拟合观测分析场虽然更贴近观测但动力上已经不稳定了。5. 试验结果诊断与常见问题排查5.1 从输出文件判断同化是否成功的几个硬指标跑完一次同化试验后不能只看程序有没有报错退出还要看分析增量是否合理。下面几个指标是我每次跑完都会快速检查的第一查看 cost function 的收敛情况。日志里通常会有类似“cost function J 12345.67”的输出经过若干次迭代后J 值应当下降并稳定。如果 J 值振荡不降或者直接发散基本可以判定配置有问题最常见的成因是 B 矩阵奇异或观测文件里有极端异常值。第二检查 O-A 与 O-B 的统计。前面提过O-A 的均方根应该小于 O-B这说明同化起到了正向作用。如果在某个观测类型上 O-A 反而变大先检查该类型观测的质量控制是否把异常值都剔除了。第三分析增量wrfvar_output 与 fg 的差值的空间结构。单点试验时增量应该平滑地从中心向外衰减真实试验时增量应该在观测密集区更明显、在观测空白区接近零。如果增量呈现棋盘状噪声或大范围规则图案通常说明 B 矩阵相关尺度设置不当或者边界处理出了问题。5.2 高频报错与排查技巧速查表为了节省大家排查问题的时间我把实际运行中遇到频率最高的几类报错整理成了一览表。这里面有些是 Piggy_Packages 环境特有的问题有些是 WRFDA 通用的问题但都很典型。报错现象可能原因解决办法da_wrfvar.exe 启动后立即报段错误环境变量不一致MPI 或 netCDF 库不匹配重新加载 Piggy_Packages 环境确认 module 顺序提示找不到 fg 文件背景场链接名错误确认运行目录下有名为 fg 的链接或文件提示找不到 ob.ascii观测文件未链接或路径错误检查观测文件链接名和权限cost function 发散B 矩阵奇异或观测值异常检查 be.dat 是否完整用单点观测重试obsproc 处理观测时报格式错误little_r 格式不对对照官方 little_r 格式说明逐项检查da_update_bc.exe 运行后 wrfbdy 变量异常分析增量过大、边界不匹配缩小同化影响半径检查背景场是否合理程序卡住不退出且 CPU 利用率低文件 I/O 瓶颈或 MPI 进程分配不当检查磁盘空间减少进程数重试排查这类问题的通用原则是“分而治之”。先用最简单的环境单点观测、单核运行跑通再逐步增加复杂度这样每次引入一种变化出问题时就能精准定位。如果你一上来就用满配的观测数据和 128 核并行去跑一旦出错排查的时间基本是成倍增加的。5.3 单点试验结果不理想的调参方向如果你做了单点试验但结果不理想按下面这个顺序排查基本能覆盖绝大多数情况。如果增量范围过大导致整个区域都受到影响优先考虑调小 B 矩阵的水平相关尺度参数如果增量范围过小观测只影响了一两个格点说明相关尺度参数设置得过小或者增量实际上被垂直相关约束压住了需要检查垂直方向的误差协方差设置。如果增量位置不对比如应该出现在观测点附近结果却跑到区域另一头去了那基本可以确定是观测文件里的经纬度与模式投影不匹配或者是 fg 文件中的地图投影参数读取出错。还有一种不易察觉的情况如果观测文件中记录的探空测站高度与实际地形高度差异巨大程序可能因为垂直定位失败而把观测分配到错误的高度层。如果增量方向不对比如温度观测却引起了大范围的风场异常这通常不是错误而是 B 矩阵中变量之间交叉协相关的体现。CV3 方案中变量之间是有耦合关系的温度增量可以引发风速增量。问题在于耦合幅度是否合理。如果觉得交叉协相关过强就需要评估是否要换用控制变量解耦的方案。6. Piggy_Packages 环境里的独门实战技巧6.1 模块化加载与多版本切换的避坑思路Piggy_Packages 最大的优势之一就是模块化管理环境。同一个系统里可能同时存在多个版本的 WRF、WRFDA 和依赖库这在实际工作中非常有用。比如你要对比 WRFDA V4.5 和 V4.6 在同化效果上的差异不需要重新编译任何东西只需要切换模块再运行试验就行。但模块化带来的风险也很明显如果你在一个终端会话里加载了多个模块可能会出现环境变量冲突。我的建议是每个试验脚本开头只加载当前试验需要的模块并且在脚本结束时 add 模块或者清理环境。有次我在脚本里忘记清理环境后续脚本继承了前面脚本加载的旧版本 WRFDA 路径导致整批试验用的根本不是同一个版本最后统计结果完全没法用。你可以用下面这个方式在脚本里固定环境确保可复现source /path/to/piggy_packages/init.sh module purge module load piggy_packages/wrfda/4.6 module list固定模块版本文件是个好习惯每次试验都记录一下 module list 的输出回头结果有问题时能快速排查是不是环境变化导致的。6.2 批量试验的脚本化范式当试验规模上来之后手工一条一条敲命令完全不现实。我写批量试验脚本常用的思路是一个主控脚本负责循环调用各步骤每个步骤都是一个独立的子脚本或函数这样任何一步出错都可以单独重跑。下面是一个简化的主控循环模板可以随意扩展#!/bin/bash # 批量三维变分同化试验脚本 dates(2024-06-15_12 2024-06-16_00 2024-06-16_12) for d in ${dates[]}; do # 建独立工作目录 workdir./exp_${d} mkdir -p $workdir cd $workdir # 链接背景场、观测和 namelist ln -sf ../data/fg_${d} ./fg ln -sf ../obs/ob_${d}.ascii ./ob.ascii cp ../config/namelist.input ./namelist.input # 运行同化 mpirun -np 16 ../wrfda/da_wrfvar.exe log_${d}.out # 简单判断是否成功 if grep -q SUCCESS log_${d}.out; then echo ${d} finished successfully ../batch_progress.txt else echo ${d} failed ../batch_progress.txt fi cd .. done这个模板里值得注意的几个地方第一每个日期都建立独立的工作目录避免中间文件互相覆盖第二运行日志单独保存并重定向方便事后排查第三用 grep 判断运行是否成功把结果记录到进度文件中这样批量试验跑到一半中断时你知道哪些已经完成、哪些需要重跑。我还习惯在批量试验的最后加一个统计脚本自动从每个目录的日志里提取 O-B、O-A 的均方根值汇总到一张表格里。这样整个批次试验的结果一目了然不需要一个个目录进去翻日志。6.3 磁盘空间与文件管理经验WRFDA 试验的中间文件非常占空间。一个 wrfvar_output 文件可能就有几个 GB一批 30 天的循环同化试验跑下来几百 GB 的磁盘占用是家常便饭。我处理这个问题的方法比较简单粗暴重要文件保留中间文件定期清理。下面是我每轮试验结束后清理文件的具体策略。保留的文件包括wrfvar_output、rej_obs、log 文件、namelist.input、更新后的 wrfbdy。可删除的中间文件包括临时生成的 fort.* 文件、链接文件本身、运行过程中的备份文件。重灾区常常是联文件和各种调试输出。在 Piggy_Packages 环境里每个试验目录的中间文件如果不清理下一次试验链接文件时很容易误用到上一次的旧数据这个坑一定要留意。我每轮试验结束后清理文件的具体策略文件类型处理方式说明wrfvar_output保留分析场结果后续预报必需rej_obs_*保留质量控制的完整记录log 文件保留排查参数依据namelist.input保留记录试验配置fort.* 文件删除临时诊断文件体积大wrfbdy 更新版本保留预报必需obs 备份视情况删原始观测若在别处有备份可删7. 我踩过几次坑之后沉淀的经验7.1 第一次跑通全流程的最好路径如果你是从零开始接触 WRFDA 三维变分我强烈建议严格按“单点观测→单时次观测→批量循环”的顺序前进不要跳步。单点试验帮你理解 B 矩阵和增量传播特性单时次试验帮你掌握观测文件处理、质量控制、边界更新的全流程批量循环才真正进入科学评估的层面。每一步都稳扎稳打比直接上手完整业务配置要高效得多。具体来说单点观测可以先在 namelist 里把 time_window 设得很窄限定观测在该时刻附近然后在 obs 文件里构造一条探空或地面观测记录。跑完后重点看 fort.900 里面这一条观测的 O-A 值以及 wrfvar_output 的增量场。确认单点增量形状合理后再换一组真实观测跑单时次试验最后再扩展到批量试验。7.2 帮别人查问题前先做的一件事给同门或同事排查 WRFDA 问题时我必做的第一件事不是看 log而是看 namelist.input 里 start_hour 和 fg 文件的时间是否匹配。这听起来太低级了但真的发生过很多次有人把 00 时次的背景场和 12 时次的观测放在一起跑程序居然还能跑出动量学上看似合理的分析结果只是偏差非常大。WRFDA 对时间一致性有一定的容错逻辑不会直接报错这就导致问题隐藏得很深。另一点是看观测文件里的时间戳little_r 格式每一条观测都带有年、月、日、时、分、秒。如果观测资料是 UTC 时间而你背景场用的是地方时时间或者观测文件里时次和 namelist 不一致都会造成非常隐蔽的分析偏差。7.3 关于“同化效果不好”的判断标准很多初学者跑完一次同化试验看到 24 小时预报的 RMSE 没有比控制试验改善就着急去调参数。我的建议是先区分是同化没起作用还是预报评价指标覆盖不了同化的益处。前者说明你的同化配置有问题后者则可能是因为天气形势变化剧烈预报技巧本身就波动大需要做多次试验取统计平均才能看出稳定差异。更合理的评估方式是多时次批量试验把同化试验和控制试验的预报插值到观测站点上计算多个时刻的 RMSE 和偏差然后做显著性检验再下结论。只看一两个个例就断定同化效果好坏在科研和业务中都不靠谱。这套批量评估流程虽然前期代码工作多一些但一旦跑通后续换观测类型、换参数配置时评估成本就很低了。WRFDA 三维变分试验的学习曲线确实不低但一旦把环境、流程、诊断这几件事理清楚后面做 4DVar、Hybrid 甚至集合卡尔曼滤波思路都是相通的。希望这篇基于 Piggy_Packages V2026.1 环境的实战梳理能帮你少走一些弯路。