观潮 · 模式预报与气象 AI 观察
WRF 重启后 sst_update 失效：时钟告警从重启文件继承 auxinput4_interval 被忽略
> 一段长气候积分因为输入文件丢失，需要在中间"跳过"1.75 天：原积分停在缺口前最后一个时次并写了重启文件，缺口的 42 小时单独重跑 WPS 与 real.exe。重启之后 wrf.exe 跑了 6 小时就崩，报"在 wrflowinp_d01 里找不到匹配的时次"。官方答复给出的是机制而非开关：WRF 重启运行时，时钟告警一律从重启文件派生，因此沿用上一次运行的设置——所以模型仍按旧节奏去 1866-10-01_06:00:00 找海温更新。而override_restart_timers覆盖不到sst_update的间隔。官方给的唯一出路是照着override_restart_timers的实现自己加一个控制sst_update时钟告警的选项，并明说这件事"繁琐且耗时"。
出问题的场景
报告人要做的是长时间气候尺度的 WRF 积分，开启时变海温（SST）。积分按 6 小时输入推进。中途一部分输入文件丢失，他不想整段重跑，于是改成"跨过缺口"的接法：
- 原积分跑到缺口前最后一个时次停下，写出重启文件
wrfrst_d01_1866-10-01_00:00:00； - 针对缺口的 42 小时单独跑 WPS 和
real.exe，生成新的wrflowinp_d01； - 从重启文件继续，指望 namelist 里新设的
auxinput4_interval = 2520（分钟，即 42 小时）能覆盖掉原来 6 小时的节奏。
namelist 里的相关设置是 auxinput4_inname = "wrflowinp_d<domain>"。
报错长什么样
模型正常启动，跑满 6 小时写出第一个 wrfout 之后失败：
```
Timing for Writing wrfout_d01_1866-10-01_06:00:00 for domain 1: 1.24212 elapsed seconds
d01 1866-10-01_06:00:00 Input data is acceptable to use: wrflowinp_d01
WARNING Time in input file not equal to time on domain WARNING
WARNING Trying next time in file wrflowinp_d01 ...
2 input_wrf: wrf_get_next_time current_date: 1866-10-02_18:00:00 Status = -4
d01 1866-10-01_06:00:00 ---- ERROR: Could not find matching time in input file wrflowinp_d01
NOTE: 1 namelist vs input data inconsistencies found.
FATAL CALLED FROM FILE: <stdin> LINE: 1297
```
两个细节值得注意。一是 Input data is acceptable to use 之后才报时次不匹配，说明文件本身读得进去，卡的是"找哪个时次"。二是 wrf_get_next_time 里的 current_date 已经跳到 1866-10-02_18:00:00——新生成的 wrflowinp_d01 只覆盖 42 小时的缺口，这个时次在文件里不存在，于是 Status = -4 收场。
报告人自己的判断是：auxinput4_interval = 2520 被忽略了，他怀疑原因是 sst_update=1；模型似乎退回默认值 auxinput4_interval = 360，所以第 6 小时就崩。他也翻过两个相似帖（auxinput4 error on wrf.exe (ecmwf hres) 和 Could not find matching time in input file when use sst_update），说那里的解法都不适用于他的情况。
官方给的根因
Ming Chen 的答复只有一层机制，但这一层就够解释现象：
> For WRF restart run, the clock-alarms are always derived from the restart file and thus follows the settings in the previous run.
即：重启运行时，时钟告警不是从 namelist 重新读的，而是从重启文件里继承的，因此沿用上一次运行的节奏。这解释了为什么 namelist 里写 2520 分钟没有生效——模型根本没去读它，它按旧设置在 1866-10-01_06:00:00 去找海温更新，而新的 wrflowinp_d01 里没有这个时次。
官方答复的边界
override_restart_timers用不了。 官方明确说这个选项对sst_update的间隔不起作用——它管不到这一路时钟告警。- 没有现成开关，也没给补丁。 官方给的方向是：去看
override_restart_timers是怎么实现的，照同样的方式自己加一个控制sst_update时钟告警的选项。同时直说，不熟悉 WRF 的 clock-alarm 系统的话，这件事 "tedious and time-expensive"。 - "2520 被忽略、退回默认 360" 是报告人的推断，官方没有确认。 原贴用的是 "What I think is happening" 与 "I suspect"；官方答复给的解释在 clock-alarm 继承这一层，没有复核 namelist 数值是否被改写。这两个说法不冲突，但把 360 当既定事实会越过原文。
- 帖子里没有验证过任何变通方案。 换输入数据重跑、整段重跑、改源码加选项——这三条在帖内都没有人试过或确认过。
一句话判断
这是一例"namelist 写了但没被读"的重启坑：凡是要跨过数据缺口改跑法的地方，先假定时钟告警来自重启文件而不是 namelist，sst_update 这一路目前没有官方开关可绕。