UFS Weather Model Configuration File Types

The files described here are present in the version of the ufs-weather-model as of Aug 14, 2022 under the tests/parm directory.

AQM Resource File

The NOAA Air Quality Model is a subcomponent of UFS and requires the AQM Resource File, aqm.rc .

• This file can currently be parsed with pyyaml
• There are sections of the file that use a double colon (::) syntax to start a section that contains CSV data. These sections all seem to contain the same data type/structure.
• The double colon sections will require special handling to parse.
• Truthy values are pyyaml compliant, but may need to be converted back to lowercase strings when writing to file (need to check fortran code). Recommendation for unified management: Use YAML as a dictable and let a tool do the formatting. Use "base" from RT suite.

diag_table

The diag_table is described here. It uses the FMS-managed format, which is most like CSV. It's purpose is to control the output written by the diag_manager tool. Here are the described requirements (source) of the format:

• The diag_table is a plain text file that lists files and fields, and the frequency of output
• The diag_table contains the "base date" used by the model
• None of the lines in the diag_table can span multiple lines The files contain a 2-line header:
• Line 1: An arbitrary string that describes the experiment. It cannot contain spaces.
• Line 2: The base date of the experiment
  • Must the same or earlier than the model start time
  • 6 integers separated by spaces Examples of existing management:
• SRW maintains one file for each CCPP suite and fills in the header at run time using Jinja2 templates
• global_workflow maintains several use-case-specific diag_tables, then uses the cat utility in bash to add the header at run time.
• HAFS has two templates specific to their use cases (global nest or regional), and uses atparse to template the date and the output interval.
• weather-model RT maintains several files for the specific tests in the suite. Recommendation for unified management: Jinja2 Templates housed in RT, filled by same tool in Apps.

field_table

The field_table file is described here. It manages the advected tracers and their associated options. The file is most like CSV, but specifically formatted by item and row of entry, making it possible to configure it with YAML-like files and develop a formatter for writing the files. The format from the link above:

The first line of an entry should consist of three quoted strings:The first quoted string will tell the field manager what type of field it is. The string “TRACER” is used to declare a field entry.The second quoted string will tell the field manager which model the field is being applied to. The supported type at present is “atmos_mod” for the atmosphere model.The third quoted string should be a unique tracer name that the model will recognize.

The second and following lines are called methods. These lines can consist of two or three quoted strings. The first string will be an identifier that the querying module will ask for. The second string will be a name that the querying module can use to set up values for the module. The third string, if present, can supply parameters to the calling module that can be parsed and used to further modify values.

An entry is ended with a forward slash (/) as the final character in a row. Comments can be inserted in the field table by having a hash symbol (#) as the first character in the line.

For example, an entry in a field_table looks like:

"TRACER", "atmos_mod", "sphum" "longname", "specific humidity" "units", "kg/kg" "profile_type", "fixed", "surface_value=3.e-6" /