`orog_gsl`

Note

The uwtools drivers are idempotent, meaning that actions they successfully complete during one invocation are not repeated in subsequent invocations. For example, an asset like a configuration file will not be recreated when the driver is run again, even if its UW YAML configuration changes. To force recreation, remove the asset(s) in question – up to and including the entire provisioned run directory – then re-run the driver, which will recreate any missing assets based on the current configuration.

The uw mode for configuring and running the UFS Utils preprocessing component orog_gsl. Documentation for this UFS Utils component is here.

uw orog_gsl --help

usage: uw orog_gsl [-h] [--version] [--show-schema] TASK ...

Execute orog_gsl tasks

Optional arguments:
  -h, --help
      Show help and exit
  --version
      Show version info and exit
  --show-schema
      Show driver schema and exit

Positional arguments:
  TASK
    input_config_file
      The input config file
    input_grid_file
      The input grid file
    provisioned_rundir
      Run directory provisioned with all required content
    run
      A run
    runscript
      The runscript
    show_output
      Show the output to be created by this component
    topo_data_2p5m
      Global topographic data on 2.5-minute lat-lon grid
    topo_data_30s
      Global topographic data on 30-second lat-lon grid
    validate
      Validate the UW driver config

All tasks take the same arguments. For example:

uw orog_gsl run --help

usage: uw orog_gsl run [-h] [--version] [--config-file PATH] [--batch]
                       [--dry-run] [--graph-file PATH]
                       [--key-path KEY[.KEY...]] [--schema-file PATH]
                       [--quiet] [--verbose]

A run

Optional arguments:
  -h, --help
      Show help and exit
  --version
      Show version info and exit
  --config-file PATH, -c PATH
      Path to UW YAML config file (default: read from stdin)
  --batch
      Submit run to batch scheduler
  --dry-run
      Only log info, making no changes
  --graph-file PATH
      Path to Graphviz DOT output [experimental]
  --key-path KEY[.KEY...]
      Dot-separated path of keys leading through the config to the driver's
      configuration block
  --schema-file PATH
      Path to schema file to use for validation
  --quiet, -q
      Print no logging messages
  --verbose, -v
      Print all logging messages

Examples

The examples use a configuration file named config.yaml with contents similar to:

orog_gsl:
  config:
    halo: 4
    input_grid_file: /path/to/C{{ orog_gsl.config.resolution }}_grid.tile{{ orog_gsl.config.tile }}.halo{{ orog_gsl.config.halo }}.nc
    resolution: 403
    tile: 7
    topo_data_2p5m: /path/to/geo_em.d01.lat-lon.2.5m.HGT_M.nc
    topo_data_30s: /path/to/HGT.Beljaars_filtered.lat-lon.30s_res.nc
  execution:
    batchargs:
      cores: 1
      walltime: "00:01:00"
    envcmds:
      - module use /path/to/modules
      - module load module_name
    executable: /path/to/orog_gsl
  rundir: /path/to/run/dir
platform:
  account: me
  scheduler: slurm

Its contents are described in section orog_gsl.

Run orog_gsl on an interactive node
```
$ uw orog_gsl run --config-file config.yaml
```
The driver creates a runscript.orog_gsl file in the directory specified by rundir: in the config and runs it, executing orog_gsl.
Run orog_gsl via a batch job
```
$ uw orog_gsl run --config-file config.yaml --batch
```
The driver creates a runscript.orog_gsl file in the directory specified by rundir: in the config and submits it to the batch system. Running with --batch requires a correctly configured platform: block in config.yaml, as well as appropriate settings in the execution: block under orog_gsl:.
Specifying the --dry-run flag results in the driver logging messages about actions it would have taken, without actually taking any.
```
$ uw orog_gsl run --config-file config.yaml --batch --dry-run
```

The --key-path option can be used to navigate from the top of the config to the driver’s configuration block. For example, specifying --key-path foo.bar with config
```
foo:
  bar:
    driver:
      # driver config block
```
is equivalent to using config
```
driver:
  # driver config block
```
without specifying --key-path.

Specifying the --show-schema flag, with no other options, prints the driver’s schema:

uw orog_gsl --show-schema >schema
head -n20 schema

{
  "properties": {
    "orog_gsl": {
      "additionalProperties": false,
      "properties": {
        "config": {
          "additionalProperties": false,
          "properties": {
            "halo": {
              "type": "integer"
            },
            "input_grid_file": {
              "type": "string"
            },
            "resolution": {
              "type": "integer"
            },
            "tile": {
              "maximum": 7,
              "minimum": 1,

Use the --schema-file option to specify a custom JSON Schema file with which to validate the driver config. A custom schema could range in complexity from the simplest, most permissive schema, {}, to one based on the internal schema shown by --show-schema.

orog_gsl

Examples

`orog_gsl`