fv3
Structured YAML to run FV3 is validated by JSON Schema and requires the fv3: block, described below. If FV3 is to be run via a batch system, the platform: block, described here, is also required. The configuration files required by the UFS Weather Model are documented here.
This driver receives a
cycleargument, which it makes available as a Pythondatetimeobject to Jinja2 when realizing its input config. This supports specification of cycle-specific values. For example, the key-value pairgfs.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 fv3: block, explained in detail below:
fv3:
diag_table:
template_file: /path/to/diag_table_to_use
domain: regional
execution:
batchargs:
walltime: "00:10:00"
executable: ufs_model
mpiargs:
- "--export=NONE"
mpicmd: srun
threads: 1
field_table:
base_file: /path/to/field_table_to_use
files_to_copy:
INPUT/gfs_ctrl.nc: /path/to/gfs_ctrl.nc
INPUT/gfs_data.nc: /path/to/gfs_data.nc
INPUT/sfc_data.nc: /path/to/sfc_data.nc
files_to_link:
co2historicaldata_2010.txt: src/uwtools/drivers/global_co2historicaldata_2010.txt
co2historicaldata_2011.txt: src/uwtools/drivers/global_co2historicaldata_2011.txt
lateral_boundary_conditions:
interval_hours: 3
offset: 0
path: gfs_bndy.tile{tile}.f{forecast_hour}.nc
length: 12
model_configure:
base_file: /path/to/model_configure_to_use
update_values:
write_dopost: .false.
namelist:
base_file: /path/to/base/input.nml
update_values:
fv_core_nml:
k_split: 2
n_split: 6
validate: true
rundir: /path/to/runs/{{ cycle.strftime('%Y%m%d%H') }}
platform:
account: me
scheduler: slurm
UW YAML for the fv3: Block
diag_table:
template_file:
The path to a Jinja2 template file to be rendered, using the values from the
template_values:block for thediag_tablefile. See FV3diag_tabledocumentation here.template_values:
The key/value pairs that are required by the
template_file.
domain:
Accepted values are global and regional.
execution:
See this page for details.
field_table:
The path to a valid field-table file to be copied into the run directory.
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.
lateral_boundary_conditions:
Describes how the lateral boundary conditions have been prepared for a limited-area configuration of the FV3 forecast. Required when domain is regional.
interval_hours:
How frequently the lateral boundary conditions will be used in the FV3 forecast, in integer hours.
offset:
How many hours earlier the external model used for boundary conditions started compared to the desired forecast cycle, in integer hours.
path:
An absolute-path template to the lateral boundary condition files prepared for the forecast. The Python
intvariableforecast_hourwill be interpolated into, e.g.,/path/to/srw.t00z.gfs_bndy.tile7.f{forecast_hour:03d}.nc. Note that this is a Python string template rather than a Jinja2 template.
length:
The length of the forecast in integer hours.
model_configure:
Supports base_file: and update_values: blocks (see Updating Values for details). See FV3 model_configure documentation here.
namelist:
Supports base_file: and update_values: blocks (see Updating Values for details). See FV3 model_configure documentation here.
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.