ABOUT UFS SOFTWARE INFRASTRUCTURE

The Unified Forecast System (UFS) applications share a set of scientific components (e.g. an atmospheric model, a land model), and a set of software infrastructure packages (e.g. model coupling software, a common physics framework). They also share a system architecture, which describes how the scientific components and software infrastructure elements are combined and specialized, end-to-end, to generate forecast guidance and to support research. This page outlines which software infrastructures are used in UFS, and where you may encounter them.

The explanations below assume that you have a basic understanding of UFS applications and components.

In order to change the configuration or code of the UFS, it may be necessary to understand one or more of the community software infrastructure packages that the UFS leverages. Each of these community packages is designed to support interoperability of components and to facilitate experimentation. For several of these packages, there is a wrapper or “cap” layer of software that acts as a component adapter, translating user-written scientific code into standard data structures and metadata that the infrastructure package can understand. Other components of the system use the standard “cap” to interact with the component. Figure 1 is a simplified schematic of two components (say, atmosphere and land) interacting through a software infrastructure package.

A schematic of two components interacting through a software infrastructure package.
Figure 1. A schematic of two components interacting through a software infrastructure package. Each component has a “cap” that calls into scientific code. The caps translate that scientific code to data structures and metadata that are understandable by the infrastructure package that connects them.

If you are working deep within scientific code, you may not need to understand much of the infrastructure software used in UFS at all. But if you are changing input or output arguments to a component, or are concerned with how your scientific code is interacting with other components of the UFS, you may need to learn about one or more software infrastructure packages.

The rest of this page provides a description of the major community software infrastructure packages that UFS leverages, where you may run into them, and how to find out more about them. Table 1 summarizes where the various infrastructures are used. Unless otherwise indicated, all of these infrastructure packages are publicly available.

Table 1. Software infrastructures used within UFS.
Software Infrastructure Who can expect to encounter this software
Common Community Physics Package-framework (CCPP-framework) Anyone modifying or introducing new atmospheric physics parameterizations.
Earth System Modeling Framework (ESMF) and National Unified Operational Prediction Capability (NUOPC) Layer Anyone who is interested in modifying the coupling between UFS model components, introducing new coupled components, or reconfiguring I/O in the atmospheric component.
NOAA Environmental Modeling System (NEMS) Anyone who is interested in managing the execution of UFS models; for example, those setting up or modifying ensembles that will run as single executables, and those integrating the JEDI software into UFS applications. Anyone running regression tests across UFS applications.
Common Infrastructure for Modeling Earth (CIME) Anyone trying to configure or port a UFS application that runs within a CIME workflow.
Model Evaluation Tools plus (METplus) Anyone who wishes to verify real-data forecasts against observations to determine forecast accuracy, to diagnose systematic model errors, or to compare proposed model improvements with previous versions.
Unified Post Processor (UPP) Anyone running an application with an atmospheric component will run UPP as part of their workflow. Anyone interested in modifying the model diagnostics will also encounter UPP.

Common Community Physics Package-framework (CCPP-framework)

The Common Community Physics Package-framework (CCPP-framework) is software infrastructure that is used to support interoperable atmospheric physics parameterizations. It has two parts: a CCPP-framework, which is the driver that invokes and sequences the physics parameterizations, and the CCPP itself, a set of physics parameterizations that comply with the CCPP-framework. The CCPP-framework is part of the atmospheric component of the UFS, the FV3-based Global Forecast System. CCPP uses the “cap” approach shown in Figure 1.

Used in the following UFS applications:
Medium-Range Weather, Short-Range Weather, and Subseasonal-to-Seasonal applications (development versions).

Who can expect to encounter the CCPP-framework:
Anyone modifying atmospheric physics parameterizations or introducing new atmospheric parameterizations will likely need to understand how to use the CCPP-framework.

More information:
https://dtcenter.org/community-code/common-community-physics-package-ccpp

Earth System Modeling Framework (ESMF) and National Unified Operational Prediction Capability (NUOPC) Layer

The Earth System Modeling Framework (ESMF) is a community software package for building and coupling component models. Key functions include parallel grid remapping and support for sequential or concurrent component operation. Sequential operation means that different components, such as atmosphere and ocean models, operate using the same computer resources and one model runs after the other; concurrent operation means that multiple components can operate simultaneously on different computer resources.

The National Unified Operational Prediction Capability (NUOPC) Layer is a set of generic component templates that simplify the implementation of ESMF.

ESMF and the NUOPC Layer are used in a number of ways in UFS:

  • There is a single NUOPC Layer driver for all UFS applications that is a key part of what makes UFS “unified.”
  • ESMF and the NUOPC Layer are used to couple the atmosphere, ocean, ice, wave, chemistry, and other component models in UFS. This is done with simple data transfers between some components, such as atmosphere and wave, or by using a flux coupler that performs more complex operations. The Community Mediator for Earth Prediction Systems (CMEPS) is a flux coupler based on ESMF and the NUOPC Layer. It couples the UFS atmosphere, ocean, and ice models. There is also a space weather mediator based on ESMF and the NUOPC Layer that performs specialized 3D coupling between an atmosphere model and an ionosphere-plasmasphere model.
  • ESMF and the NUOPC Layer are also used to implement I/O (Input/Output) in the UFS atmosphere model, and ESMF is used in various places, such as pre-processing, as a grid remapping utility.

ESMF and the NUOPC layer follow the “cap” approach shown in Figure 1.

Used in the following UFS applications:
All UFS applications (development versions) and previous operational versions of the Global Forecast System and Global Ensemble Forecast System

Who can expect to encounter ESMF and the NUOPC Layer:
Anyone who is interested in modifying the coupling between UFS model components, new coupled components, or reconfiguring I/O in the atmospheric component will likely need to work with ESMF interfaces.

More information:

NOAA Environmental Modeling System (NEMS)

The NOAA Environmental Modeling System (NEMS) is the term used to describe software infrastructure that has been built or customized for use in UFS. This focus on UFS distinguishes it from the other more general software infrastructure package described in these pages. Most community-developed software infrastructure packages used in UFS, such as ESMF, the CCPP-framework, and METplus, are forecast-system-agnostic. They are used in other modeling and forecast systems besides UFS.

NEMS includes:

  • A NEMS model driver that invokes all of the UFS applications, and the “main” program for all of these applications. The NEMS driver supports ensemble configurations set up as a single executable – meaning that every ensemble member is compiled into the same executable.
  • Extensions for a “Unified Driver,” where the NEMS model driver is modified to allow UFS modeling applications to be driven by the Joint Effort for Data assimilation Integration (JEDI) software infrastructure.
  • Regression testing software that spans UFS applications.
  • The mediators or flux couplers included in UFS, such as the Community Mediator for Earth Prediction Systems (CMEPS) and a space weather mediator, may be considered sub-modules of NEMS, although CMEPS is used on other modeling systems besides UFS.

Used in the following UFS applications:
All UFS applications (operational GFS and all development versions) and previous operational versions of the Global Forecast System and Global Ensemble Forecast System

Who can expect to encounter NEMS:
Anyone who is interested in managing the execution of UFS models; for example those setting up or modifying ensembles that will run as single executables, and those integrating the JEDI software into UFS applications. Anyone running regression tests across UFS applications.

More information:
https://www.emc.ncep.noaa.gov/emc/pages/infrastructure/nems.php

Common Infrastructure for Modeling Earth (CIME)

The Common Infrastructure for Modeling Earth (CIME) contains a set of community-based infrastructure utilities including a Case Control System (CCS) along with other software tools. The CIME CCS provides a user-friendly, reproducible workflow for configuring, compiling and executing Earth system models. It consists of an extensible set of object-oriented python scripts and is well documented. The CIME CCS also provides a user-friendly porting capability for CCS-compliant modeling systems, and it is accompanied by comprehensive system and unit testing functionality.

CIME includes “data” components that, when invoked, send physically realistic input data to model components. These data components can be used to replace prognostic components for testing, spin-up, and model parameterization development. CIME also includes “dead” components that generate data that is scientifically invalid but useful for testing. These generic components enable CIME itself to be ported and tested standalone, without needing to bring in any user-written model components. Once these data and test component options are integrated into UFS, which has not happened yet, they will support hierarchical model development by allowing the user to easily control model feedbacks.

Used in the following UFS applications:
Medium-Range Weather and Subseasonal-to-Seasonal applications (development versions) and Hurricane application (in progress)

Who can expect to encounter CIME:
Anyone trying to configure or port a UFS application that runs within a CIME workflow. For example, CIME is used to build and execute the Medium-Range Weather application, including generating a default namelist for the model, and providing a way to update that namelist.

More information:
https://esmci.github.io/cime/

METplus

METplus is a suite of Python wrappers and ancillary scripts that enhance the user’s ability to quickly set-up and run the Model Evaluation Tools (MET). MET is designed to be a highly-configurable, state-of-the-art suite of verification tools for numerical environmental prediction systems. MET provides a variety of verification techniques, including:

  • Standard verification scores comparing gridded model data to point-based observations
  • Standard verification scores comparing gridded model data to gridded observations
  • Spatial verification methods comparing gridded model data to gridded observations using neighborhood, object-based, and intensity-scale decomposition approaches
  • Ensemble and probabilistic verification methods comparing gridded model data to point-based or gridded observations
  • Aggregating the output of these verification methods through time and space

Used in the following UFS applications:
Medium-Range Weather, Subseasonal to Seasonal, Short-Range Weather/Convection Allowing (eventually all applications)

Who can expect to encounter METplus:
Anyone who wishes to verify real-data forecasts against observations to determine forecast accuracy, to diagnose systematic model errors, or to compare proposed model improvements with previous versions.

More information:
https://dtcenter.org/community-code/model-evaluation-tools-met
https://github.com/NCAR/METplus

Unified Post Processor (UPP)

The Unified Post Processor (UPP) is a software package designed to take raw model output and turn it into convenient and useful products. The UPP provides the capability to compute a variety of diagnostic fields and interpolate to pressure levels or other vertical coordinates. Examples of products include:

  • T, Z, humidity, wind, cloud water, cloud ice, rain, and snow on pressure levels
  • SLP, shelter level T, humidity, and wind fields
  • Precipitation-related fields
  • PBL-related fields
  • Severe weather products (e.g. CAPE, Vorticity, Wind shear)
  • Radiative/Surface fluxes
  • Cloud related fields
  • Aviation products
  • Radar reflectivity products
  • Satellite look-alike products

The output from the UPP can then be used directly by visualization, plotting, or verification packages, or for further downstream post-processing, e.g. statistical post-processing techniques.

Used in the following UFS applications:
Medium-Range Weather, Short-Range Weather/Convection Allowing, Hurricane, and eventually all applications

Who can expect to encounter UPP:
Anyone running an application with an atmospheric component will run UPP as part of their workflow. Anyone interested in modifying the model diagnostics will also encounter UPP.

More information:
https://dtcenter.org/community-code/unified-post-processor-upp
https://github.com/NOAA-EMC/EMC_post