Skip to Content
教程列表Cime运行 Case

5.1. 调用 **case.submit

脚本 case.submit  将将你的运行任务提交到你的机器上的批处理队列系统。如果你没有批处理队列系统，case.submit  将以交互方式启动任务，前提是你已经定义了适当的 MPI 环境。运行 case.submit  是你应该启动任务的唯一方法。

要查看 case.submit  的选项，请执行命令

$ ./case.submit --help

要了解 case.submit  会做什么，一个好的方法是在首先调用 preview_run 

$ ./preview_run

这将输出您的运行环境，以及批量提交和 mpirun 命令。例如，在 NCAR 机器 Cheyenne 上，对于 f19_g17_rx1 分辨率的 A compset，preview_run  的输出如下：

CASE INFO:
   nodes: 1
   total tasks: 36
   tasks per node: 36
   thread count: 1
 
BATCH INFO:
   FOR JOB: case.run
ENV:
   module command is /glade/u/apps/ch/opt/lmod/7.5.3/lmod/lmod/libexec/lmod python purge
   module command is /glade/u/apps/ch/opt/lmod/7.5.3/lmod/lmod/libexec/lmod python load ncarenv/1.2 intel/17.0.1 esmf_libs mkl esmf-7.0.0-defio-mpi-O mpt/2.16 netcdf-mpi/4.5.0 pnetcdf/1.9.0 ncarcompilers/0.4.1
   Setting Environment OMP_STACKSIZE=256M
   Setting Environment TMPDIR=/glade/scratch/mvertens
   Setting Environment MPI_TYPE_DEPTH=16
SUBMIT CMD:
   qsub    -q regular -l walltime=12:00:00 -A P93300606 .case.run
 
FOR JOB: case.st_archive
   ENV:
      module command is /glade/u/apps/ch/opt/lmod/7.5.3/lmod/lmod/libexec/lmod python purge
      module command is /glade/u/apps/ch/opt/lmod/7.5.3/lmod/lmod/libexec/lmod python load ncarenv/1.2 intel/17.0.1 esmf_libs mkl esmf-7.0.0-defio-mpi-O mpt/2.16 netcdf-mpi/4.5.0 pnetcdf/1.9.0 ncarcompilers/0.4.1
      Setting Environment OMP_STACKSIZE=256M
      Setting Environment TMPDIR=/glade/scratch/mvertens
      Setting Environment MPI_TYPE_DEPTH=16
      Setting Environment TMPDIR=/glade/scratch/mvertens
      Setting Environment MPI_USE_ARRAY=false
SUBMIT CMD:
   qsub    -q share -l walltime=0:20:00 -A P93300606  -W depend=afterok:0 case.st_archive
 
MPIRUN:
   mpiexec_mpt  -np 36 -p "%g:"  omplace -tm open64  /glade/scratch/mvertens/jim/bld/cesm.exe  $$ cesm.log.$LID 2$&1

上述每个部分都在不同的 $CASEROOT xml 文件中定义，相关的变量可以使用 xmlchange  命令进行修改（对于任务和线程，也可以使用 pelayout  命令进行修改）。

  • PE 布局由 xml 变量 NTASKS、NTHRDS 和 ROOTPE 设置。要查看每个组件的确切设置，执行以下命令

    ./xmlquery NTASKS,NTHRDS,ROOTPE

    要将所有 NTASKS 设置更改为 30，并将所有 NTHRDS 设置为 4，您可以执行

    ./xmlchange NTASKS=30,NTHRDS=4

    要仅将 ATM NTASKS 改为 8，可以执行

    ./xmlchange NTASKS_ATM=8

  • 提交参数由文件 env_batch.xml 中的 xml 变量设置。这个文件在某些情况下，xml 变量可以出现在多个组中。注意：组是可提交的工作列表。通常，最小的组集是 case.run 和 case.st_archive。我们将演示如何使用 xml 变量 JOB_WALLCLOCK_TIME 更改 env_batch.xml 中的 xml 变量。

    • 要将 cheyenne 的所有组的 JOB_WALLCLOCK_TIME 改为 2 小时，使用

      ./xmlchange JOB_WALLCLOCK_TIME=02:00:00

    • 要仅将 cheyenne 的 case.run 组的 JOB_WALLCLOCK_TIME 改为 20 分钟，使用

      ./xmlchange JOB_WALLCLOCK_TIME=00:20:00 --subgroup case.run

在使用 case.submit  提交案例前，请确保为您的运行正确设置了批量队列变量。特别是，请确保您有适当的账户(PROJECT)、时间限制(JOB_WALLCLOCK_TIME)和队列(JOB_QUEUE)。

同时，使用 xmlchange 修改您的案例的 $CASEROOT/env_run.xml。

在执行完 case.setup  和 case.build  后，调用 case.submit  将运行提交到您机器的批量队列系统。

$ cd $CASEROOT
$ ./case.submit

5.1.1. 运行 case.submit 的结果

当被调用时，case.submit  脚本将：

  • 加载必要的环境。

  • 确认锁定文件与当前 xml 文件一致。

  • 运行 preview_namelist ，它将依次运行每个组件的 cime_config/buildnml 脚本。

  • 运行 check_input_data  来验证所需数据是否存在。

  • 将任务提交到批处理队列。该队列将运行 case.run  脚本。

运行成功完成后，case.run  将：

  • 将时间信息写入 $CASEROOT/timing。详情请参阅 model timing data 。

  • 如果 $DOUT_S 为 TRUE，请将短期归档脚本 case.st_archive  提交到批量队列。短期归档将复制并移动组件历史记录、日志、诊断和重启文件从 $RUNDIR 到短期归档目录 $DOUT_S_ROOT。

  • 重新提交 case.run  如果 $RESUBMIT 大于 0。

5.1.2. 监控案例作业状态

$CASEROOT/CaseStatus 文件按时间顺序记录了所有作业状态和 xmlchange  命令的日志。以下是状态消息的示例：

2017-02-14 15:29:50: case.setup starting
---------------------------------------------------
2017-02-14 15:29:54: case.setup success
---------------------------------------------------
2017-02-14 15:30:58: xmlchange success <command$ ./xmlchange STOP_N=2,STOP_OPTION=nmonths  </command$
---------------------------------------------------
2017-02-14 15:31:26: xmlchange success <command$ ./xmlchange STOP_N=1  </command$
---------------------------------------------------
2017-02-14 15:33:51: case.build starting
---------------------------------------------------
2017-02-14 15:53:34: case.build success
---------------------------------------------------
2017-02-14 16:02:35: case.run starting
---------------------------------------------------
2017-02-14 16:20:31: case.run success
---------------------------------------------------
2017-02-14 16:20:45: st_archive starting
---------------------------------------------------
2017-02-14 16:20:58: st_archive success
---------------------------------------------------

注意

成功运行一次后，在重新提交之前，请将 env_run.xml 变量 $CONTINUE_RUN 设置为 TRUE，否则作业将不会继续进行。

您可能还需要修改 env_run.xml 变量 $STOP_OPTION、$STOP_N 和/或 $STOP_DATE，以及 $REST_OPTION、$REST_N 和/或 $REST_DATE，和 $RESUBMIT，在重新提交之前。

请参阅[基本示例](7. Customizing your input variables — CIME master documentation )，了解如何运行案例的完整示例。

5.1.3. 故障排除失败的作业

如果作业失败，有多个地方可以查找信息。首先查看 $CASEROOT 中的 STDOUT和 STDERR 文件。如果在其中没有找到明显的错误消息，$RUNDIR/$model.log.$datestamp 文件可能会给你一些提示。

首先，检查 cpl.log.$datestamp，这通常会告诉你模型是何时失败的。然后检查其余的组件日志文件。有关更多信息，请参阅 troubleshooting run-time problems 。

5.2. 输入数据

check_input_data 脚本用于确定你的案例所需的数据文件是否存在于 $DIN_LOC_ROOT 的适当子目录中的本地磁盘上。它会自动下载模拟所需缺失的数据。

注意

建议在同一系统上的用户共享一个共同的 $DIN_LOC_ROOT 目录，以避免磁盘上大量输入数据的重复。您可能需要与系统管理员沟通来设置此配置。

每个组件所需的输入数据集位于 $CASEROOT/Buildconf 目录中。这些文件由对 preview_namlists 的调用生成，而每个组件的 buildnml 脚本会创建这些文件。例如，对于仅包含数据模型（即 A 组件集）的 compsets，会创建以下文件：

cpl.input_data_list
datm.input_data_list
dice.input_data_list
docn.input_data_list
drof.input_data_list

您可以通过以下命令独立验证所需数据的存在：

$ cd $CASEROOT
$ ./check_input_data --help
$ ./check_input_data

如果数据集缺失，可通过以下命令从输入数据服务器(s)获取：

$ cd $CASEROOT
$ ./check_input_data --download

check_input_data 由案例控制系统在案例构建并提交时自动调用。因此，手动使用此脚本不是必需的。

5.2.1. 分布式输入数据仓库

CIME 能够利用多个输入数据仓库，这些仓库可能使用不同的协议。仓库定义在文件 $CIMEROOT/config/$ model/config_inputdata.xml 中。当前支持的服务器协议有：gridftp、subversion、ftp 和 wget。这些协议是否可用取决于您的软件配置。

注意

现在您能够创建自己的输入数据仓库并将其添加到 config_inputdata.xml 中。这将使您能够通过与他人共享所需的输入数据来轻松协作。

5.3. 启动、停止和重新启动运行

文件 env_run.xml 包含在初始化或模型运行过程中可以修改的变量。除了其他功能外，这些变量包括模型停止时间、重启频率、耦合器历史频率的耦合器配置文件设置，以及一个标志来确定是否应将运行标记为继续运行。

至少，您需要设置变量 $STOP_OPTION 和 $STOP_N。其他驱动配置文件设置将具有一致且合理的默认值。默认设置保证在模型运行结束时生成重启文件。

默认情况下，停止时间设置是：

STOP_OPTION = ndays
STOP_N = 5
STOP_DATE = -999

默认设置仅适用于初始测试。在开始长时间运行之前，应根据案例吞吐量和批处理队列限制更新停止时间。例如，如果模型每天运行5个模型年，设置 RESUBMIT=30, STOP_OPTION= nyears, and STOP_N= 5 。然后模型将以五年为增量运行，并在提交30次后停止。

5.3.1. 运行类型初始化  

案例初始化类型使用 env_run.xml 中的 $RUN_TYPE 变量设置。CIME 运行可以通过三种方式之一进行初始化：

startup

在启动运行（默认设置）中，所有组件都使用基线状态进行初始化。这些状态由每个组件独立设置，可以包括使用重启文件、初始文件、外部观测数据文件或内部初始化（即“冷启动”）。在启动运行中，耦合器在初始化时将起始日期发送给组件。此外，耦合器不需要输入数据文件。在启动初始化中，海洋模型直到第二次海洋耦合步骤才开始运行。

branch

在一个分支运行中，所有组件都使用一组一致的重新启动文件进行初始化，这些文件来自之前的运行（由 env_run.xml 中的 $RUN_REFCASE 和 $RUN_REFDATE 变量确定）。案例名称通常在分支运行中会更改，但并非必须。在分支运行中，$RUN_STARTDATE 设置会被忽略，因为模型组件从它们的重新启动数据集中获取起始日期。因此，分支运行的起始日期不能更改。这是执行重新启动运行所使用的相同机制（在 env_run.xml 文件中将 $CONTINUE_RUN 设置为 TRUE）。分支运行通常用于需要敏感性或参数研究，或者需要修改历史文件输出流设置时，同时仍保持逐位可重现性。在这种情况下，如果未修改源代码或组件 namelist 输入，新案例能够像继续运行一样产生逐位精确的重新启动。所有模型都使用重新启动文件来执行这种类型的运行。 $RUN_REFCASE 和 $RUN_REFDATE 是分支运行所必需的。要设置分支运行，请从之前的运行中找到 $RUN_REFCASE 和 $RUN_REFDATE 的重新启动 tar 文件或重新启动目录，然后将这些文件放置在 $RUNDIR 目录中。参见从参考案例开始  。

hybrid

混合运行像启动一样初始化，但它使用先前案例的初始化数据集。它类似于具有宽松重启约束的分支运行。混合运行允许用户在给定的模型输出日期（由 $RUN_REFCASE 指定）将先前案例（由 $RUN_REFDATE 指定）的初始/重启文件组合起来。与分支运行不同，混合运行的起始日期（由 $RUN_STARTDATE 指定）可以相对于参考案例进行修改。在混合运行中，模型不会以逐位的方式继续相对于参考案例。然而，只要混合运行中没有更改模型源代码或命名列表，结果气候应该是连续的。在混合初始化中，海洋模型直到第二个海洋耦合步骤才开始，耦合器在没有重启文件的情况下进行“冷启动”。

变量 $RUN_TYPE 决定了初始化类型。此设置仅在 $CONTINUE_RUN 变量设置为 FALSE 时，对初始生产运行重要。初始运行后，$CONTINUE_RUN 变量设置为 TRUE，模型将精确地使用输入文件，以案例、日期和逐位连续的方式重新启动。

变量 $RUN_STARTDATE 是启动运行或混合运行的开始日期（格式为 yyyy-mm-dd）。如果运行目标是混合运行或分支运行，你必须指定 $RUN_REFCASE 和 $RUN_REFDATE 的值。

5.3.2. 从参考案例（REFCASE）开始

有几个 xml 变量控制分支案例或混合案例如何从另一个案例启动。从另一个案例启动运行所需的初始/重启文件必须位于 $RUNDIR。xml 变量 $GET_REFCASE 是一个标志，如果设置，将自动预置参考案例重启数据。

  • 如果 $GET_REFCASE 是 TRUE，则使用 $RUN_REFDIR、$RUN_REFCASE、$RUN_REFDATE 和 $RUN_TOD 设置的值通过符号链接将数据预置到适当路径。

    从另一个案例启动所需的资料位置由 xml 变量 $RUN_REFDIR 控制。

    • 如果 $RUN_REFDIR 是绝对路径名，则预期启动模型运行所需的初始/重启文件位于 $RUN_REFDIR。

    • 如果 $RUN_REFDIR 是相对路径名，则预期启动模型运行所需的初始/重启文件位于相对于 $DIN_LOC_ROOT 的路径，绝对路径名为 $DIN_LOC_ROOT/$RUN_REFDIR/$RUN_REFCASE/$RUN_REFDATE 。

    • 如果 $RUN_REFDIR 是一个相对路径名，并且不在 $DIN_LOC_ROOT 中可用，那么 CIME 将尝试从输入数据仓库下载数据。

  • 如果 $GET_REFCASE 是 FALSE，则假定数据已经存在于 $RUNDIR 中。

5.4. 控制输出数据

在模型运行期间，每个模型组件在 $RUNDIR 中生成自己的输出数据集，包括历史数据、初始数据、重启数据、诊断数据、输出日志和 rpointer 文件。组件历史文件和重启文件采用 netCDF 格式。重启文件用于重新启动相同的模型，或作为其他模型案例的初始条件。rpointer 文件是 ASCII 文本文件，列出了重启所需的组件历史文件和重启文件。

归档（此处指短期归档）是模型运行的一个阶段，当输出数据从 $RUNDIR 移动到本地磁盘区域（短期归档）。它对生产运行没有影响，除了清理 $RUNDIR 中的磁盘空间，这有助于管理用户磁盘配额。

env_run.xml 中的几个变量控制短期归档的行为。以下是如何通过两个变量设置来控制数据输出流的示例：

DOUT_S = TRUE
DOUT_S_ROOT = /$SCRATCH/$user/$CASE/archive

上述第一个设置是默认设置，因此短期归档是启用的。第二个设置指定在成功运行结束时将文件移动到哪里。

此外：

  • 所有输出数据最初写入到 $RUNDIR。

  • 除非您明确关闭短期归档，否则在模型运行成功结束后，文件会被移动到 $DOUT_S_ROOT。

  • 用户在开发新代码时，通常应该关闭短期归档。

每个组件生成的标准输出会保存在 $RUNDIR 中的日志文件 。每次运行模型时，都会在输出日志文件的文件名中加入一个协调的日期戳。运行脚本以 YYMMDD-hhmmss 的格式生成日期戳，表示运行开始时的年、月、日、小时、分钟和秒（例如 ocn.log.040526-082714）。

默认情况下，每个组件还会定期写入历史文件（通常为每月），并在 $RUNDIR 目录中写入 netCDF 或二进制重启文件。历史文件和日志文件由每个组件独立控制。历史输出控制（例如输出字段和频率）在每个组件的 namelist 中设置。

原始历史数据并不易于进行简单的时间序列分析。例如，CAM 在每个请求的输出周期会写入一个或多个大的 netCDF 历史文件。虽然这种行为对于模型运行是最佳的，但它使得在不访问整个数据量的情况下分析单个变量的时间序列变得困难。因此，主要模型集成的原始数据通常会被后处理成更用户友好的配置，例如包含每个输出字段长时间序列的单个文件，并提供给社区。

关于 CESM，请参考 CESM2 Output Filename Conventions  了解输出数据文件名的说明。

5.5. 重新启动运行

活动组件（以及一些数据组件）根据驱动程序通过在 env_run.xml 中设置 $REST_OPTION 和 $REST_N 变量来决定重启文件的写入间隔。重启文件允许模型停止后又能以逐位精确的能力重新启动；模型输出与模型未停止时的输出完全相同。驱动程序负责协调重启文件的写入以及模型的运行时间演变。

初始化为分支或混合运行的运行需要从先前的模型运行中获取重启/初始文件（由变量 $RUN_REFCASE 和 $RUN_REFDATE 指定）。在模型运行开始前，将这些文件预置到案例 $RUNDIR（通常为 $EXEROOT/../run）。通常这是通过复制相关 $RUN_REFCASE/rest/$RUN_REFDATE.00000 目录的内容来完成的。

每当一个组件写入重启文件时，它还会以 rpointer.$component 格式写入一个重启指针文件。在重启时，每个组件会读取指针文件，以确定要读取哪个文件才能继续运行。以下是使用完整主动模型组件为组件集创建的指针文件示例。

- rpointer.atm
- rpointer.drv
- rpointer.ice
- rpointer.lnd
- rpointer.rof
- rpointer.cism
- rpointer.ocn.ovf
- rpointer.ocn.restart

如果启用了短期归档，模型会将组件重启数据集和指针文件归档到 $DOUT_S_ROOT/rest/yyyy-mm-dd-sssss，其中 yyyy-mm-dd-sssss 是重启时的模型日期。（详情见下文。）

5.5.1. 撤回到上一个重启

如果一个运行遇到问题并崩溃，通常需要撤回到上一个重启。如果启用了短期归档，请找到最新的 $DOUT_S_ROOT/rest/yyyy-mm-dd-sssss 目录，并将其内容复制到你的运行目录（ $RUNDIR ）。

确保新的重启指针文件覆盖 $RUNDIR 中的旧文件，否则作业可能无法在正确的位置重启。然后您可以使用新的重启继续运行。

偶尔，当运行在重启时出现问题，那是因为指针文件和重启文件不同步。指针文件是文本文件，可以编辑以匹配重启和历史文件的正确日期。所有重启文件都应有相同的日期。

5.6. 归档模型输出数据

成功运行产生的输出数据流取决于是否启用了短期归档，默认情况下是启用的。

5.6.1. 无归档

如果未执行短期归档，模型输出数据将保留在由 $RUNDIR 指定的运行目录中。

5.6.2. 短期归档

如果启用了短期归档，组件输出文件将被移动到本地磁盘上由 $DOUT_S_ROOT 指定的短期归档区域。该目录通常是 $EXEROOT/../../archive/$CASE，并具有以下目录结构：

rest/yyyy-mm-dd-sssss/
logs/
atm/hist/
cpl/hist
glc/hist
ice/hist
lnd/hist
ocn/hist
rof/hist
wav/hist
....

logs/ 子目录包含运行期间创建的组件日志文件。日志文件也会被复制到短期归档目录，因此可供长期归档使用。

rest/ 子目录包含一组子目录，每个子目录包含一组一致的重新启动文件、初始文件和 rpointer 文件。每个子目录都有一个唯一名称，对应于文件创建时的模型年份、月份、日期和当天秒数。任何重新启动目录的内容都可以用来创建分支运行或混合运行，或备份到之前的重新启动日期。

5.6.3. 长期归档

用户可以选择遵循其机构偏好的模型输出长期归档方法。CESM 的先前版本提供了一个外部长期归档工具，支持大容量磁带存储和 HPSS 系统。然而，随着行业从磁带归档迁移，CIME 不再能够支持所有可能的归档方案。

5.7. 数据同化和其他外部处理

CIME 提供了在计算节点上运行任务的能力，该任务可以在模型运行之前或之后执行。CIME 还提供了数据同化功能，该功能会循环模型，然后执行用户定义的任务，循环次数由用户确定。

5.7.1. 运行前和运行后脚本

变量 PRERUN_SCRIPT 和 POSTRUN_SCRIPT 可分别用于命名一个脚本，该脚本应在批处理环境中立即在 CESM 可执行文件开始运行之前或完成运行之后执行。该脚本预期位于案例目录中，并将接收一个参数，即该目录的完整路径。如果该脚本是用 Python 编写的，并且包含一个与脚本名称相同的子程序，它将作为子程序调用，而不是作为外部 Shell 脚本调用。

5.7.2. 数据同化脚本

变量 DATA_ASSIMILATION、DATA_ASSIMILATION_SCRIPT 和 DATA_ASSIMILATION_CYCLES 也可以用于外部控制模型演化。如果 DATA_ASSIMILATION 在模型完成 DATA_ASSIMILATION_SCRIPT 后为真，则会运行该脚本，然后模型将重新启动 DATA_ASSIMILATION_CYCLES 次。脚本预期存在于案例目录中，并将接收两个参数：该目录的完整路径和周期编号。如果脚本是用 Python 编写的，并且包含一个与脚本同名的子程序，它将作为子程序调用，而不是作为外部 Shell 脚本调用。

下面是一个简单的预运行脚本示例。

#!/usr/bin/env python3
import sys
from CIME.case import Case
 
def myprerun(caseroot):
    with Case(caseroot) as case:
         print ("rundir is ",case.get_value("RUNDIR"))
 
 if __name__ == "__main__":
   caseroot = sys.argv[1]
   myprerun(caseroot)
Last updated on
构建 Case克隆 Case