观潮 · 模式预报与气象 AI 观察
MPAS 换一个 CPU 数就挂死：128 和 512 都能跑，唯独 256 卡住，答案在 METIS 分区文件
一个 MPAS 变网格（60-15 km）的并行配置问题：128 个 CPU 能跑，512 个 CPU 能跑，唯独 256 个 CPU 会挂死——而且不只是 restart，cold start 用 256 个也跑不了。作业没有任何报错，就是停在那里不动。
这个帖子只有 5 轮问答就结束了，没有最终结论。但 NCAR 在第二轮给出的一句话已经把答案指向了 METIS 分区文件。帖子的价值在于这句话，以及它为什么能直接排除掉最容易被误认的那个方向。
症状：一张实验矩阵
提问者给的实验矩阵是这样的：
场景 · CPU 数 · 结果
cold start · 128 · 成功
cold start · 256 · **挂死**
cold start · 512 · 成功
restart（restart 文件由 128 CPU 生成） · 256 · **挂死**
restart（restart 文件由 128 CPU 生成） · 128 · 成功
他的原始描述是「the job just hangs there without any error」——作业就停在那里，不报错。日志文件已附在帖子里。
"挂死"而不是"报错"这一点很关键。 分区不匹配不会触发 MPAS 的输入校验，因为从程序角度看，你给的进程数和它读到的分区文件在语法上都是合法的；问题在于分区里记录的块分配与实际进程数不匹配，导致某个进程永远等不到它需要的数据，通信请求悬着不返回。这种故障没有断言失败、没有 NaN 触发、没有 MPI 超时报错，所以日志尾部看不到任何线索——唯一的症状就是时间在走、作业不动。
NCAR 给出的那条线索
第二轮 NCAR 的回复提了两件事：一是请描述实验配置，并问能否用 256 个 CPU 从 cold initialization 跑一遍——如果冷启动也挂，问题就跟 restart 无关；二是给出一条关键信息：
> 对于冷启动，只要有兼容的 x4.535554.graph.info.part.xxx 文件，我可以用任意数量的 CPU。
提问者随后确认用的是 variable mesh 60-15 km，文件名就是 x4.535554。这一条把 METIS 的图编号和分区文件命名对上了。
为什么 512 能跑通本身就是答案
这一条值得单独讲，因为它是最容易被绕进去的地方。
提问者最初的假设是：restart 文件由 128 CPU 生成，用 256 CPU 去读会有结构性问题。这个假设有一个反例——512 同样不是生成 restart 时的 CPU 数，却能跑通。
所以逻辑上只剩两种可能：
解释 · 对 512 的预言 · 实际
「restart 文件与生成它的进程数绑定」 · 512 应该也挂 · ✗ 512 能跑
「当前进程数下有没有对应的分区文件」 · 128/512 有文件，256 没有 · ✓ 与观察一致
排除了第一种，第二种就成了唯一解释。 NCAR 那句"只要有兼容的 .part.xxx 我可以用任意CPU 数"反过来读就是：没有对应分区文件的话，任意数量的 CPU 都不能用，冷启动也一样——这和提问者第三轮观察到的"cold start 用 256 也不行"完全吻合。
换句话说，决定权在文件在不在，而不在配置对不对。也正因为这样，512 能跑不代表"任意非 128 的进程数都行"，它只说明 512 那份分区文件恰好存在。
METIS 分区文件是什么，为什么它会缺
MPAS-Atmos 的并行分解依赖 METIS 生成的分区文件，命名规则是 x4.<graph_id>.graph.info.part.<nprocs>：
片段 · 含义
`x4` · 对应 namelist 里 `&metis` 的 `4`，即四边形分区
`535554` · METIS 内部的图编号，由网格拓扑结构决定
`part.<nprocs>` · 这份分区针对的进程数
分区是在一个特定进程数下生成的，它记录了每个进程负责哪些网格块、以及块之间的通信关系。换进程数就意味着现有分区不再匹配。
关键在最后那个 part.<nprocs>：你实际能用的进程数，取决于你本地有多少个不同 nprocs 后缀的文件。 MPAS 通常会为若干个常见分解配置预生成分区文件，但不是连续覆盖。帖子里出现的"128 行、512 行、256 不行"正是这种离散覆盖的典型表现——看起来毫无规律，其实就是文件在不在。
还有一层容易连带出错的地方：图编号 535554 是由网格拓扑结构算出来的。换了网格或改了 &metis 段，旧的分区文件即使 .part. 后缀对得上，也会因为对应的图不是同一个而不可用。所以生成新分区之前，得先确认 x4.<graph_id> 这个前缀和你当前的网格配置一致。
排查这个症状应该先看什么
帖子信息不完整，但已经足够把范围缩到很小。按可行性排序：
第一，直接列出你有哪些分区文件。
```
ls .graph.info.part.
```
把实际存在的 .part.<nprocs> 后缀列出来，和你想用的进程数对照。绝大多数"换个 CPU 数就挂"的案例在这一步就结束了。
第二，确认日志里到底读到了哪个分区。 MPAS 的运行日志在启动阶段通常会打印读取的分区文件路径。如果日志里根本没有出现你期望的那个 .part.<nprocs>，答案已经明确了——比"为什么挂了"更直接。
第三，为目标进程数生成分区。 如果 &metis 段配置得当，可以用 gen_hex 或 MPAS 自带的分区生成流程为你的目标进程数生成分区文件。这条路径的可行性取决于 METIS 是否已正确编译安装。
第四，如果必须跨进程数 restart，路径是有的。 MPAS 支持在 restart 时重新分区，但这不是默认行为，需要在 namelist 里显式配置。帖子里 128 → 512 跑通说明这条路至少在某两个数之间是通的，值得对比两次 namelist 的差别。
时间成本对比
动作 · 耗时 · 能排除什么
`ls *.graph.info.part.*` · 1 秒 · 目标进程数没有分区文件（本案最可能的答案）
查 rsl.error 启动段 · 1 分钟 · 是否读到了期望的分区文件路径
对比两次 namelist · 10 分钟 · 是否某个 option 与进程数相关
第一条放第一位，是因为它的信息量/成本比最高：如果目标进程数的分区文件不在，这一秒就能定案，后面所有排查都不必做。反过来，如果文件确实存在，那问题在别处，前两条都不会给你答案——这时才值得往下走。
时间线：这次交流一共五轮
轮次 · 谁说了什么
1 · 提问者：用 128 CPU 生成的 restart 文件，用 256 CPU 跑会挂；128 CPU 跑同一文件成功
2 · NCAR：请描述实验配置，并问能否用 256 CPU 从冷启动跑一遍——如果冷启动也挂，就与 restart 无关；同时给出"有兼容分区文件即可用任意 CPU 数"
3 · 提问者：冷启动用 256 也不行；但 128 和 512 可以。另外指出冷启动需要兼容的 `x4.535554.graph.info.part.xxx`
4 · NCAR：请补充实验类型和 namelist 选项（可附文件），会尝试复现
5 · 提问者：variable mesh 60-15 km，文件名就是 `x4.535554`；NCAR 回复会当天查看并回复
提问者在第三轮和第五轮给出的网格配置与文件名，是整个帖子的关键信息。
作者承认的限制
帖子没有结论。 NCAR 提出的三项信息需求里，只有"256 CPU cold start 是否也挂"得到了确认答复；namelist 选项和成功运行那次日志都没给，所以没人能真正复现这个问题。NCAR 最后一句是"我今天看看再回复"，之后没有下文。
"512 能跑"是记录下来的事实，但"为什么 512 有分区而 256 没有"没有得到解释。 所以这个现象不能推广成"任何非 128 的进程数都行"。
帖子覆盖的是 variable mesh 60-15 km 这一个配置。 该配置下 METIS 生成的图编号（535554）与分区数的组合，可能和其他配置不同，不能直接套用到自己的网格上——分区文件必须和自己的网格配置严格对应。
原文全文只有 280 词左右。 上面的 METIS 原理说明属于补充背景，不是帖子的原始内容；帖子本身给的事实仅限于实验矩阵和那句关于分区文件的回复。这也是这篇能写到的边界。
一句话判断
"某些进程数能跑、某些挂死"这类问题的答案几乎总是分区文件缺失，而不是科学配置问题：先 ls .graph.info.part. 确认目标进程数有没有对应的 METIS 分区文件，这一秒就能定案。
这个帖子最好的地方是它演示了一次用反例排除错误假设的过程——512 能跑通这个事实，直接否掉了"restart 文件与生成进程数绑定"这个看起来最合理的猜测，把方向引到了分区文件上。提问者到帖子结束都没走到 ls 那一步。