观潮 · 模式预报与气象 AI 观察
MPAS 降水和雪深被地形绑住：200 米以下 7 毫米、800 米以上 14 毫米，换微物理方案也是同样结果
> 一位用户拿 MPAS-A 的 60—3 公里变分辨率网格回报 2024 年 1 月中国南方冬季暴雪，发现降水与雪深几乎完全被地形高度控制：36 小时面平均降水从 200 米以下的约 7 毫米升到 800 米以上的约 14—15 毫米，雪深从低海拔接近 0 厘米升到 800 米以上约 10 厘米。换成另一种微物理方案后结论不变，于是怀疑是配置而非物理方案的问题。NCAR 方面的回复给出了一个明确抓手：config_nsmterrain默认是 1，建议提到 2 以增加地形平滑；用户照做重新生成静态场，却在init_atmosphere阶段撞上 SIGSEGV 段错误，作业在 512 GB 内存的节点上运行约一小时后中断，截至最后一层回复尚未确认能否跑通。
症状：降水与雪深随高度近乎线性抬高
发帖者用的是 MPAS-A，网格为 60—3 公里的变分辨率网格，个例是 January 2024 中国南方的冬季暴雪。为排除物理方案的偶然性，他跑了两组试验：一组用 Thompson 微物理，一组用 WSM6，动力框架与大尺度强迫完全相同，两者都用 convection_permitting 物理套件。
在 36 小时的评估窗口里，两组试验呈现出同样的高度依赖关系：
地形高度 · 面平均降水 · 雪深
200 米以下 · 约 7 毫米 · 接近 0 厘米
800 米以上 · 约 14—15 毫米 · 约 10 厘米
两套微物理方案在这个指标上没有出现分歧，因此发帖者判断问题不该归因于云微物理。
观测那一侧的麻烦：站点都在低处
与观测比对时有个结构性困难：绝大多数站点位于低海拔，观测采样本身不完整。但发帖人也指出，这次过程在低海拔地区造成了大范围强降雪，许多低海拔站观测到了可观的降水量和积雪累积。
他自己的措辞保留了分寸：模拟结果「显得比观测到的这次过程更受地形控制」，同时明确表示并不假定这种地形相关性一定是错的——地形抬升降水和山区更冷的温度本来就会物理性地增加降雪。他担心的是某个 MPAS 配置可能放大了这种地形依赖，或在低地与山地之间造出不真实的分离。
已经排除的一条路：地形数据本身
静态场使用的是标准的 WRF/WPS GEOG 静态数据集（Namelist 里 config_geog_data_path 指向该目录），地形来自 GMTED2010，不是自定义 DEM。这一点在后面官方判断里得到确认：标准的 WRF/WPS GEOG 地形（即 GMTED2010）对 60—3 公里网格生成 MPAS 原生网格地形是合适的，不必另换数据源。
NCAR 给的排查顺序
官方回复逐条回应了发帖者的六个问题，可以整理成一个可执行的顺序：
步骤 · 结论
1. 地形数据源 · GMTED2010 对 60—3 公里适用；地形强迫在此类个例中起关键作用，先查地形影响
2. `config_nsmterrain` · 默认值 1，建议提到 2，增加平滑、削弱小尺度起伏
3. `config_smooth_surfaces` · 应为 true
4. `config_blend_bdy_terrain` · 只对区域运行有效，全球运行不适用
5. 网格分辨率 · 60—3 公里对中国南方这类复杂地形的冬季风暴是合适的选择
6. 合理性检验手段 · 与观测对比是判断结果是否物理合理的有效办法；其他方法回复方表示不确定，建议查阅文献
回复还要求澄清一项关键信息：这是区域还是全球运行、用什么资料驱动。发帖者答复为全球 MPAS 运行（非有限区域），由 GFS 预报资料驱动。
照着改之后：`init_atmosphere` 崩了
发帖者按建议重新生成静态场，把地形平滑提高到 config_nsmterrain = 2，网格为 x20.835586。对应的 namelist 关键项如下：
```
config_start_time = '2024-01-21_00:00:00'
config_stop_time = '2024-01-23_00:00:00'
config_interface_projection = 'linear_interpolation'
config_geog_data_path = '/data/wangj/wyt/geog/'
config_landuse_data = 'MODIFIED_IGBP_MODIS_NOAH'
config_extrap_airtemp = 'lapse-rate'
config_block_decomp_file_prefix = 'x20.835586.graph.info.part.'
```
作业于 2026 年 10 月 16 日 00:03:15 CST 启动、01:02:55 CST 结束，36 个任务。日志在输出 Using option 'lapse-rate' for vertical extrapolation of temperature 之后抛出：
```
forrtl: severe (174): SIGSEGV, segmentation fault occurred
init_atmosphere_m 000000000067F094 for__signal_handl Unknown Unknown
```
节点内存为 512 GB。发帖者提到某个 AI 工具建议把 config_native_gwd_static 设为 false，并向官方确认是否可行。
没做的事
这条帖子里有几处明确的未完成状态，不应被略过：
- 尚无敏感性试验结论。 提高
config_nsmterrain是否能缓解地形过度控制，还没有跑出可对比的结果——因为静态场生成这一步还没跑通。 config_native_gwd_static = false是外部工具的建议，不是官方确认的做法。 官方回复的措辞是请求用户试完反馈，并自行推测config_native_gwd_static = true加config_nsmterrain = 1这组「应该可以」，同时请用户如果判断有误就指出。- 段错误的原因没有定位。 官方认为 512 GB 对这个个例应该够用，建议必要时增加处理器数量以获得更多内存，但没有给出根因判断。
- 合理性检验只给了方向。 对「如何区分真实的地形增幅与人为的地形过度放大」，回复方表示不确定是否有其他方法，建议查阅文献。
一句话判断
这是一条「地形强迫 → 先动平滑参数」的排查线索，官方明确指向 config_nsmterrain，但截至当层回复，改动本身还卡在静态场生成的段错误上，降水过度贴地形的问题既没有被证实也没有被排除。