观潮 · 模式预报与气象 AI 观察
ndown 报「参考气压非单调递减」：etac 调到 0.005 也没用，问题出在 compute_vcoord_ld_coeffs
一个 WRF 4.8 + WPS 4.7 组合下的 ndown 崩溃案例：无论怎么调 eta 层数、etac 一路降到 0.005，都会撞上同一个 fatal error。提问者最后自己定位到问题出在 compute_vcoord_ld_coeffs 的调用环节，但到发帖时仍未解决。
报错长什么样
```
----- ERROR: The reference pressure is not monotonically decreasing
This tends to be caused by very high topography
FATAL CALLED FROM FILE: <stdin> LINE: 1249
```
这个错误信息本身给了两个提示：一是参考气压必须单调递减，二是"往往由很高的地形引起"。
常规手段全部无效
提问者的排查过程基本覆盖了能查到的所有常规建议：
尝试的方向 · 结果
调小 `etac` · 从 0.200000003 降到 0.1、0.05，**乃至更低，都没变化**
改变 eta 层数 · 在 33 到 51 之间试过，无效
改变数据集/分辨率 · 换了，无效
缩小初始域范围 · 原本域就比较大，缩小后依然崩
同时他确认了输入数据是没问题的：wrfout_d01_2026-07-11_00_00_00 可以正常读取。
运行环境是 WRF v4.8 配 WPS v4.7。他自己也留了个疑问：是否有人跑过这个组合。
一个反向证据：改 2-way 嵌套就能跑通
这是帖子里最有价值的一条信息。
提问者说"我等不及了，只好改成 2-way 嵌套运行，尽管原来并不是这个计划"，然后跑通了。他的记忆里 etac 已经试到过 0.005。
NCAR 方面在后续回复里指出，1-way 嵌套和 2-way 嵌套的 namelist 本来就不该有太大差别，除了 max_domains 这一个参数。他说自己当时没保留 namelist.wps，所以只附了 WRF 的文本副本。
这条信息之所以关键，是因为它把排查范围缩小了一大截：如果 2-way 能跑、1-way 不能跑，且两者 namelist 只差 max_domains，那么问题大概率不在物理配置，而在1-way 嵌套特有的那套输入准备链路上——也就是从 wrfout 转成 wrfdaux 的那一步，或者与 fg 相关的处理。
报错的三层信息怎么读
这条 fatal 只有三行，但每行给的信息量不同：
行 · 给出的信息 · 可靠性
`ERROR: The reference pressure is not monotonically decreasing` · 症状本身：参考气压序列不是单调递减 · 确定，这是硬报错
`This tends to be caused by very high topography` · 归因提示：往往由很高的地形引起 · **是"倾向"，不是判定**
`FATAL CALLED FROM FILE: <stdin> LINE: 1249` · 触发位置 · 注意 `<stdin>` 这个形式
第二行值得特别小心。它写的是 tends to be caused by，也就是"往往由……引起"。提问者的实验恰好证明了这条提示的局限：他把域缩小到海边一小块没有山地的区域，错误信息只变了措辞，仍然崩。也就是说"高地形"这个归因在这个案例里不成立。
第三行的 <stdin> 也值得留意——这说明报错位置的呈现形式是经过处理的，不是直接的源文件行号。所以想精确定位到 WPS 源码里的哪一行，不能只靠这条 FATAL 信息。
提问者自己挖到的位置
提问者在发帖前做了一些 digging，说自己认为问题起源于调用 vert_cor 时的 compute_vcoord_ld_coeffs。
具体来说，帖子里提到问题出在从 vert_cor 调用 compute_vcoord_ld_coeffs 的环节，同时他也明确说了不知道该怎么改——知道在哪，但不知道怎么改。
这里有一个客观事实需要说清：vert_cor 及其内部的 compute_vcoord_ld_coeffs 是 WPS 里计算垂直坐标与质量坐标系数的核心例程，不是 ndown 专属的路径。也就是说这个位置被卡住，意味着问题在 WPS 侧的 eta 垂直坐标构造，而不在 ndown 的 ndown.exe 本身。
一个可以自己先做的对照实验
帖子里给出的信息虽然不完整，但已经足够支撑一个有价值的对照设计。按信息量排序，最值得先做的是这三组：
第一组：WPS 版本对照。 提问者的环境是 WRF v4.8 + WPS v4.7，而他自己提到"有升级没有包含在内"。WRF 4.8.0 的 release notes 明确写了这一版耦合了更新的 WPS v4.7.0，但反过来说，WPS 4.7 是与 WRF 4.8 配套发布的版本，不是与 WRF 4.7 配套的版本。这里存在版本错配的可能，值得先把 WPS 版本与 WRF 版本的实际配对关系理清。
第二组：eta 层的几何本身。 报错说"往往由很高的地形引起"。如果域内包含高地形（青藏高原、安第斯山这类），eta 层的几何在某些配置下可能确实构造不出严格单调递减的参考气压。帖子里提问者试的是改层数和改 etac——注意 etac 是 eta 顶层的无量纲比例系数，从 0.2 降到 0.005 意味着把顶层压到极低，这会带来另一个副作用：层间距被极度压缩，浮点精度可能不足以保证单调性。所以"降到 0.005 也没用"这个观察本身，并不能排除 eta 层几何。
第三组：wrfout → wrfdaux 的转换结果。 既然 2-way 能跑通，说明 wrfout 本身的数据是可用的。那么差别就在 ndown 的前处理上——检查 fg 文件里的地形高度场，以及 geo_em/wrfdaux 里 eta 层的实际取值。
为什么「报错行号 <stdin> LINE: 1249」这条信息靠不住
FATAL 信息里的 LINE: 1249 看起来像源码行号，但 <stdin> 这个来源名说明它是经过处理后呈现的。WPS 里报这个错的例程会被不同的编译路径内联或展开，同一个错误在不同编译器下可能给出不同的行号。
所以想靠这条信息去源码里定位，方向本身就是错的。帖子给出的可用线索只有两条：compute_vcoord_ld_coeffs 这个例程名，以及它是从 vert_cor 里被调用的。这两条是提问者自己 digging 出来的，不是从报错信息里读到的。
帖子给出的最有价值的一条设计建议
NCAR 回复里有一句容易被忽略但很实用的话：既然不管域大小都看到同样的错误，就先用最小的那个配置，而且特别提醒"域太小会产生不合理的结果"。
提问者此前的做法是"逐步缩小到海边一小块"，方向是对的，但 NCAR 的补充是：要缩到能复现错误的最小规模，而不是缩到最极端的规模。域缩小到极致时，边界条件处理本身就可能引入新问题，反而干扰判断。
这条建议对任何"改配置改到崩"的排障都适用：缩减到能稳定复现的最小配置，而不是缩减到自己都觉得不合理的配置。
三个版本的搭配关系值得先理清
这个案例涉及两组版本关系，容易混淆：
组合 · 状态
WRF v4.8 + WPS v4.7 · 提问者用的组合，也是 WRF 4.8.0 release notes 里明确要求的搭配
WRF v4.7 + WPS v4.7 · 版本号看起来更"整齐"，但 WPS 4.7 是随 WRF 4.8 一起发布的
也就是说 WPS 4.7 并不是 WRF 4.7 的配套版本。提问者提到"有升级没有包含在之前上传的文件里"，这句话指向的正是某个组件版本发生了变化，但具体是哪个组件、变成哪个版本，帖子里没写。
在遇到这类报错时，第一步应该是把三个 namelist（namelist.wps、namelist.input，以及版本对应关系）写在手边，而不是先调参数。帖子里 namelist.wps 恰好没保留，导致 NCAR 无法判断 WPS 侧配置。
作者承认的限制
帖子一共 5 层，最终没有结论。 NCAR 方面最后的回复是要了更大域的 namelist，并且指出"因为不管域大小你都看到同样的错误，我们先从最小的配置开始"。提问者最后一条说"有一些情况阻止我之前上传更新后的文件"，然后附上了 8 月份的 WPS 和 WRF namelist，并提到有一项升级没有包含在之前上传的文件里——这句话被截断了，之后就没有后续。
所以这个案例的准确状态是：定位到了 compute_vcoord_ld_coeffs，修复方法未知。
2-way 能跑通只是 workaround，不代表 1-way 的问题被解释清楚了。 提问者自己也承认，他记得 etac 试到过 0.005，但那是回忆，不是当时的记录。
namelist.wps 没有保留。 提问者明确说了没保存这个文件，所以无法确认 WPS 侧的实际配置。这一条限制很关键——报错发生在 WPS 侧 eta 垂直坐标构造的环节，而恰恰是这一侧的配置没有被记录下来。
etac 降到 0.005 这个观察不能被当作排除依据。 它是回忆性质的，且 etac 是 eta 顶层的无量纲比例系数，从 0.2 压到 0.005 会让层间距被极度压缩，浮点精度可能本身就不足以保证单调性。换句话说，"降到 0.005 也没用"这件事，既不能证明 eta 几何有问题，也不能证明它没问题。
一句话判断
这个案例的价值在于它划清了一个边界：etac 调到多小都没用，说明问题不在"参数不够小"这一类，而在 WPS 侧 eta 垂直坐标的构造环节（compute_vcoord_ld_coeffs）。帖子本身没有结论，如果你在 4.8 + 4.7 组合上遇到同样报错，最快的进展点是先确认 WPS 版本与 WRF 版本是否配套，再直接检查 wrfdaux 里 eta 层的实际取值，而不是继续往下调 etac。