jedi

Structured YAML to run JEDI is validated by JSON Schema and requires the jedi: block, described below. If jedi 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 jedi: block, explained in detail below:

jedi:
  configuration_file:
    base_file: path/to/config.yaml
    update_values:
      baz: qux
  execution:
    batchargs:
      nodes: 1
      stdout: path/to/runscript.out
      walltime: "08:00:00"
    envcmds:
      - module load some-module
      - module load jedi-module
    executable: /path/to/jedi
    mpiargs:
      - "--export=ALL"
      - "--ntasks $SLURM_CPUS_ON_NODE"
    mpicmd: srun
  files_to_copy:
    d/f2: /path/to/f2
    f1: /path/to/f1
  files_to_link:
    f3: /path/to/f3
    f4: d/f4
  rundir: /path/to/run/dir
platform:
  account: me
  scheduler: slurm

UW YAML for the jedi: Block

execution:

See this page for details.

configuration_file:

Supports base_file: and update_values: blocks (see Updating Values 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.

rundir:

The path to the run directory.