mpassit

Structured YAML to run MPASSIT is validated by JSON Schema and requires the mpassit: block, described below. If mpassit is to be run via a batch system, the platform: block, described here, is also required.

• This driver receives a cycle argument, which it makes available as a Python datetime object to Jinja2 when realizing its input config. This supports specification of cycle-specific values. For example, the key-value pair

  gfs.t{{ cycle.strftime('%H') }}z.atmanl.nc: /some/path/{{ cycle.strftime('%Y%m%d%H') }}/gfs.t{{ cycle.strftime('%H') }}z.atmanl.nc
  

  would be rendered as

  gfs.t18z.atmanl.nc: /some/path/2024021218/gfs.t18z.atmanl.nc
  

  for cycle 2024-02-12T18.

Here is a prototype UW YAML mpassit: block, explained in detail below:

mpassit:
  execution:
    batchargs:
      export: false
      nodes: 1
      stdout: /path/to/file
      walltime: 00:02:00
    envcmds:
    - module use /some/path/to/modules
    - module load some_module
    executable: /path/to/mpassit
    mpiargs:
    - --export=ALL
    - --ntasks $SLURM_CPUS_ON_NODE
    mpicmd: srun
  files_to_copy:
    x1.999.init.nc: /path/to/some.init.nc
    x1.999.graph.info.part.192: /path/to/x1.999.graph.info.part.192
  namelist:
    update_values:
      config:
        grid_file_input_grid: x1.999.init.nc
        hist_file_input_grid: /path/to/hist.nc
        diag_file_input_grid: /path/to/diag.nc
        block_decomp_file: x1.999.graph.info.part.192
        is_regional: true
        output_file: MPAS-A_out.{{ (cycle + leadtime).strftime('%Y-%m-%d_%H:%M:%S') }}.nc
        interp_diag: true
        interp_hist: true
        wrf_mod_vars: true
        esmf_log: false
        target_grid_type: lambert
        nx: 180
        ny: 106
        dx: 30000.0
        dy: 30000.0
        ref_lat: 38.5
        ref_lon: -97.5
        truelat1: 38.5
        truelat2: 38.5
        stand_lon: -97.5
    validate: true
  rundir: /path/to/run/dir
platform:
  account: me
  scheduler: slurm

UW YAML for the mpassit: Block

execution:

See this page for details.

files_to_copy:

See this page for details.

files_to_hardlink:

Identical to files_to_copy: except that hard links will be created in the run directory instead of copies, when possible. Otherwise a copy will be created.

files_to_link:

Identical to files_to_copy: except that symbolic links will be created in the run directory instead of copies.

To reduce duplication of information in these sections, it may be helpful to reference the config value that specifies the number of cores used to run the executable. For example, instead of:

mpassit:
  files_to_copy:
    x1.999.graph.info.part.192: /path/to/x1.999.graph.info.part.192

Jinja2 expressions can be used to reference the number of cores used for execution:

mpassit:
  files_to_copy:
    x1.999.graph.info.part.{{ mpassit.execution.batchargs.cores }}: /path/to/x1.999.graph.info.part.{{ mpassit.execution.batchargs.cores }}

namelist:

Supports base_file: and update_values: blocks (see Updating Values for details).

Before the namelist file is written, its proposed content will be validated against the appropriate schema. This can be suppressed by setting validate: false in the UW YAML configuration block for the namelist.

rundir:

The path to the run directory.