CIME 故障排除流程

11.1. 故障排除案例创建

通常，create_newcase 错误会报告到终端，并应提供一些关于错误原因的指导。

如果 create_newcase 因通用错误失败，首先检查命令行参数是否与接口规范匹配。查看帮助文本以复习用法。


$ create_newcase --help

11.2. 故障排除 cime 脚本中的问题

如果基于 python 的 cime 脚本以神秘的方式崩溃，可以通过使用 --debug 选项重新运行脚本来获取更多信息。

11.3. 故障排除作业提交

与提交或启动相关的多数问题都是特定于站点的。case.submit 脚本的批处理和运行方面是由解析 $CASEROOT/env_batch.xml 文件中的变量创建的。

采取以下步骤检查问题：

查看 $CASEROOT/env_batch.xml 中的批量提交选项。确认它们与特定站点的批量环境一致，并且队列名称、时间限制和硬件处理器请求合理且与案例一致。
确保使用正确的批量作业工具来提交 case.submit 脚本。根据批量环境，它可能是 bsub、qsub 或其他命令。同时确认是否需要使用重定向“<”字符。关于 case.submit 提交作业的信息显示在标准输出流的末尾。

11.4. 运行时问题排查

要检查运行是否成功完成，请检查 cpl.log 文件的最后几行，查找类似 SUCCESSFUL TERMINATION 的字符串。成功的作业通常还会将日志文件复制到 $CASEROOT/logs 目录。

当任务失败时，首先检查这些事项：

模型是否超时？
是否达到磁盘配额限制？
机器故障了吗？
文件系统是否已满？

如果发生了上述任何情况，请采取适当的纠正措施（见下文建议），并重新提交作业。

如果无法确定上述任何一项导致了案例失败，可以查看以下几个地方以获取错误信息。

检查运行目录中的组件日志文件（$RUNDIR）。此目录在 env_run.xml 文件中设置。每个组件都会写入自己的日志文件，并且应该以这种格式存在每个组件的日志文件：cpl.log.yymmdd-hhmmss。检查每个日志文件中的错误信息，尤其是在文件末尾附近。
检查 $CASEROOT 中是否存在标准输出和/或标准错误文件。标准输出/错误文件通常捕获大量额外的模型输出，并且在作业终止时也经常包含大量系统输出。有时有用的错误信息可能位于大型标准输出/错误文件底部的上方。从底部开始回溯以寻找错误信息。
检查运行目录中的核心文件，并使用适当的工具进行查看。
检查作业发送的任何自动电子邮件，了解作业失败的原因。一些站点的批处理调度器会发送这些邮件。
检查归档目录： $DOUT_S_ROOT/$ CASE。如果案例失败，日志文件或数据可能仍然已被归档。

常见错误

一个常见错误是作业超时，这通常会产生很少的错误信息。检查 cpl.log 文件中的每日模型时间戳以及运行目录中文件的时间戳，以推断运行的开始和结束时间。如果模型运行正常，但达到了 wallclock 时间限制，可以缩短运行时间或增加 wallclock 设置。

如果模型挂起然后超时，这通常表明存在 MPI 或文件系统问题，或者可能是模型问题。如果你怀疑是间歇性的系统问题，尝试重新提交作业。同时向本地站点顾问发送帮助请求，提供系统问题的反馈并寻求帮助。

另一个可能导致超时的错误是节点速度慢或间歇性速度慢。 cpl.log 文件通常输出每个模型模拟日所用的时间。要查看这些数据，可以像这里所示那样在 cpl.log 文件中用 grep 搜索字符串 tStamp：


$ grep tStamp cpl.log.* | more

输出看起来像这样：


tStamp_write: model date = 10120 0 wall clock = 2009-09-28 09:10:46 avg dt = 58.58 dt = 58.18
tStamp_write: model date = 10121 0 wall clock = 2009-09-28 09:12:32 avg dt = 60.10 dt = 105.90

查看每个模型日每行末尾的运行时间。 “avg dt =” 是模拟一个模型日的平均时间， “dt = “ 是模拟最新模型日所需的时间。

模型日期以 YYYYMMDD 格式打印，wallclock 是本地日期和时间。在示例中，10120 是 0001 年 1 月 20 日，模型那天运行了 58 秒。第二天，1 月 21 日，运行了 105.90 秒。

典型月中模型日的模拟时间差异很大，这表明存在系统问题。然而，模型成本随时间变化。例如，在每个模拟月的最后一天，模型通常会写入 netcdf 文件，这可能是一项显著的间歇性成本。此外，某些模型配置在月中读取数据或在一天以上的时间步长上间歇性地运行物理过程。在这些情况下，可以预期存在一些变化。如果问题是系统性能变化，时间变化通常非常混乱且不可预测。

有时当作业超时或磁盘空间溢出时，重启文件会变得混乱。除了 CAM 和 CLM 历史文件外，所有重启文件的大小都是一致的。

将重启文件与先前重启文件的大小进行比较。如果不匹配，请删除它们并将先前重启文件移入位置，然后重新提交作业。参见重启运行。

在 HPC 系统上节点失败或访问大文件系统挂起的情况并不少见。在提交错误报告之前，请确保案例在相同位置上始终如一地失败。

重新运行以获取更多调试信息

你可以通过以下几种方式修改你的案例以获取更多有助于调试的信息：

增加运行时 xml 变量 INFO_DBUG 的值：./xmlchange INFO_DBUG=2。这会在 cpl.log 文件中添加更多信息，如果你无法确定哪个组件中止了运行，或者无法找到不良耦合场的来源，这些信息会很有用。（这不需要重新构建。）
尝试使用构建时 xml 变量 DEBUG 设置为 TRUE 来重新构建和重新运行：./xmlchange DEBUG=TRUE。
- 这会添加各种运行时检查，以捕获诸如数组索引越界、除以 0 以及其他浮点异常等条件（具体检查的条件取决于在 caseroot 目录下的 cmake_macros 子目录中定义的宏中设置的标志）。
- 最好的方法通常是创建一个新案例，并在运行 ./xmlchange DEBUG=TRUE 之前运行 ./case.build。然而，如果你难以重新创建你的案例，那么你可以从现有案例中运行该 xmlchange 命令；然后你必须运行 ./case.build --clean-all，在重新运行 ./case.build 之前。
- 请注意，在此模式下模型运行速度会显著变慢，因此如果模型在产生错误之前需要运行很长时间，这可能并不可行。（有时在非调试模式下运行模型直到错误发生前不久，让它生成重启文件，然后在调试模式下重新启动，这样效果会很好。）另外请注意，答案会略有变化，因此如果错误是由罕见条件引起的，那么在此模式下可能不会出现。