观潮 · 模式预报与气象 AI 观察
NCAR 冻结 WRF 开发之后：社区往 4.7.1 里插 OpenACC 指令的这半年
> NCAR 在帖子里明确回复「已决定冻结 WRF 开发，因此参与 WRF-GPU 实现不是我们的优先级」。与此同时，社区出现了一个叫 FahrenheitResearch/wrf-gpu-port 的仓库：用 Python 脚本往 WRF 4.7.1 的 .f90 源码里插 OpenACC 指令，让动力核心的 small_step、big_step、diffusion、module_em 几部分跑在 GPU 上，物理参数化和平流还没做。有人编译成功但 5090 上完全看不到 GPU 被调用，有人能看见显存被填、占用率爬升，然后在第一个时间步之后静默挂死、没有任何报错。作者本人后来下场道歉并说明项目已下线转为私有开发。
缺的是哪一块
WRF 官方没有一条 GPU 路线，商业方案（帖子里点名 TempoQuest AceCast）要收费。NCAR 的回复把这条路堵得更明确：他们不知道这些 wrf-gpu 代码，且因为 WRF 开发已冻结，参与 WRF-GPU 实现不在优先级里，只能希望社区有人提供更多进展。
这条冻结还牵出一串后续提问：决定是什么时候做的、还会不会有 4.8.1 来修 bug、会不会有正式公告、GitHub 上 WPS 和 WRF 待处理的合并请求会不会被推上去。NCAR 的答复只有一句「我们很快会发公告」。有用户要求至少让最后一版 WRF 和 WPS 稳定下来，另有用户提出希望把欧洲的 AIFS 和 AIGFS 数据正确接进 WPS。
脚本做什么：往源码里插 OpenACC
这个仓库不是重写，而是打补丁：Python 脚本把三类 OpenACC 指令（ kernels、 data、 routine）插进 .f90 源文件，目标是最新的稳定版 WRF，也就是 4.7.1。覆盖范围是动力核心里的 small_step、big_step、diffusion 和 module_em 几处，明确不含物理参数化和平流。
硬件清单给得比较具体：RTX 3090 / 4090 / 5090，以及 A100、H100、H200、B200。与商业方案的区别是免费。
实际跑起来的三种反馈
使用者 · 现象
发起帖者（5090） · 编译成功，但看不到任何 GPU 使用的迹象
第二位（4080 Super） · 编译通过，文档互相矛盾；能看见进程、显存被填、占用率上升，第一个时间步后静默挂死
第三位 · 跑通了几次测试，转而提需求
第二位的描述最细，也最能说明这类补丁当前的成熟度：
- 仓库里有多份 readme，彼此冲突得厉害，还和命令行里的提示对不上；
- 文档说打完补丁要再跑一次 compile em_real，但那样只是把普通 WRF 重新编译一遍；补丁之后的提示才说要跑一个叫 compile_patched.sh 的脚本；
- 文档声称补丁会确保平流被关掉，实际上并没有；
- 折腾完之后，英伟达监视器里能看到 WRF 可执行文件、显存被填、GPU 占用在爬升，但算完第一个时间步之后就停住、静默挂住，没有错误、没有任何提示。
作者本人下场说明了什么
项目作者后来在帖子里道歉，并交代了背景：他是做强化学习的机器学习研究者，每次新的前沿大模型出来都会给它几个高难度任务，其中一个就是「给 WRF 写 GPU/CUDA kernel」。仓库之所以公开，纯粹是为了省事——他用了 8 台社区租用的 GPU 实例，不想在这些机器上放自己的 GitHub 凭据，也不想每次起新实例都等一小时的慢速同步。
他说这个阶段的目的已经达到，之后转到自己搭的本地服务器上私有开发，并预计新一代模型会有更好的长上下文处理能力。对当时试用过这个「坏掉的项目」的人，他的说法是现在状态好得多，并估计再过一个月左右能有一个真正能干点事、而不只是把显存填满的版本。
同一位作者还给出了另一个项目：ArWen，一个类 WRF-ARW 的 GPU 原生区域天气模式，声称与 WRF v4.6.1 做过对比验证。
城市夜间温度和 geo_em 这两条具体需求
有一条需求很实际：能不能支持已有的 geo_em 静态文件。使用者的场景是在自己的 WRF 运行里加入了定制的土地利用、土壤和高程数据，用 GPU 版本复现不出来。作者的回复是这是第一次收到这类请求，赶不上当天要发的 1.6，但会放进 1.7，预计当周末出。
另一条是城市夜间温度偏差。使用者说当前的 ArWen 不支持城市参数化、Noah LSM 的 mosaic 土地利用，也不支持 WUDAPT 土地利用类别，导致预报里城市区域夜间最低气温被系统性高估。他同时提到自己在 GEOGRID.TBL 里关掉地形平滑，以便更好地刻画小山谷里的夜间冷空气堆积，配合 UW 边界层方案（bl_pbl_physics=9）在中欧的模拟里效果最好。
针对这条，帖子里出现一条关于 WRF-GPU v0.4.0 的回复，称其已支持城市气候区分类、单层城市冠层方案、多层城市能量平衡方案，以及 UW 边界层方案，但 Noah 的地表 mosaic 还不支持。声明部分说这是独立、开源、与 UCAR/NCAR 无隶属关系的 WRF-ARW 移植版本，大部分内容针对 WRF-ARW 第四版做过逐位或统计一致性的对比，但不保证完美，需要 Ampere 及以上的英伟达 GPU。需要说明的是，这条关于 v0.4.0 的说明在本轮采集的多个不同主题帖子里都出现过，措辞高度一致。
边界与还没解决的部分
- NCAR 官方路线仍然缺席。 冻结决定之后是否公告、4.8.1 是否发布、待处理合并是否推进，帖子里都还没有答案。
- 打补丁这条路本身不稳定。 文档互相矛盾、编译流程分叉、平流未按说明关闭、跑起来挂死且无报错——这些都是帖子里记录的现状。
- 覆盖范围只在动力核心。 物理参数化和平流不在补丁范围内，这意味着对多数业务场景来说还不能用。
- 城市与土地利用支持不完整。 城市参数化、mosaic 土地利用、WUDAPT 类别在 ArWen 侧缺失，在移植版本侧也只是部分支持。
- 暂无官方性能或一致性基准。 帖子里没有给出加速比或与 CPU 版本对比的量化结果，各方说法都停留在「能跑」「挂住」「很快」这类描述上。
一句话判断
这条帖子的价值不在给出可用的 GPU 版 WRF，而在把现状摆清楚了：官方冻结、社区自发补位、补丁只覆盖动力核心且仍会挂死，而真正卡住业务化的是城市参数化、定制静态数据和物理过程这三块。