-
Notifications
You must be signed in to change notification settings - Fork 4
Summary of JEDI Components
A link to the online JEDI documentation for each component will be provided in each section along with a very brief summary.
OOPS - Object Oriented Prediction System
It is the top level of JEDI that orchestrates the configuration and execution of applications. This is where most DA applications are implemented. OOPS also includes the Lorenz 95 and Quasi-geostrophic toy models that can be used to run many of the DA applications. OOPS is where one would make modifications to source code that affect all modeling frameworks, such as something like the LETKF solver, or the PCG minimizer code. This is also where you would go to see what is happening at the highest level for things like the unit tests or applications. For example, a print statement added to oops/src/test/interface/ObsOperator.h would add a print statement to every time the observation operator is called, regardless of which executable is called, model is used, or which nonlinear operator is chosen.
UFO - Unified Forward Operator
UFO provides the different forward operators needed to compute the simulated observation from the model’s forecast. This is then used to compute the innovation between the modeled and observed value, key to the data assimilation process. The UFO also features other observational related transformations and functionality, including quality control (QC) filters and bias correction algorithms. UFO’s observation operators are designed to be generic, rather than specifically tailored to one observation type/platform. In the GSI, for example, things are often repeated in several different observation source code files, but UFO hopes to instead have more flexible code that can have options selected by YAML input files. The best example is for QC, all the source code in UFO for QC is very generic. The user must configure it by YAML to actually filter out what is needed for each observation type. UFO is where source code changes would need to be made if one of the existing operators or QC filters either needs modification to support an additional feature, or if a completely new operator/filter needs to be developed. UFO asks for GeoVaLs, the model state fields interpolated in x and y to the observation location as a vertical profile, for all requested fields needed to compute the simulated observation.
IODA - Interface for Observational Data Access
IODA is the part of JEDI that reads in and processes observations for use with other JEDI components. It is unlikely that the average user would need to modify much in IODA, but it is a pivotal part of JEDI nonetheless. It puts the data in data assimilation! IODA handles both the ingestion of observations, but also the writing out of diagnostics such as O-F and H(x). In IODA, observations are generally one-dimensional (nlocs) and have a corresponding latitude, longitude, height/pressure, time (or other locational metadata) associated with each location value. There are different backends for IODA, including in-memory, netCDF/HDF5, and ODB. The file format that is used to store the data is secondary to the structure and naming conventions of how the data is stored. Currently, a suite of software (IODA-converters) is used to convert observations from various formats to IODA-compatible netCDF files. Eventually, the hope is that IODA can, through an intermediate library, read and translate BUFR, non-IODA netCDF, or other file formats directly.
FV3-JEDI is the interface between the generic components of JEDI (UFO, IODA, OOPS, etc.) and all models that are based on the FV3 dynamical core (GEOS, GFS, FV3-LAM, etc.). The source code for the model grid definition (geometry), how to read and write the model restart files, how to transform model state variables to GeoVaLs, how to advance the forecast model, and other FV3 model specific code is in this repository. FV3-JEDI also creates the majority of the executables (together with OOPS) used to compute an analysis, such as the variational solver application, the H(x) calculation, or interpolation executables.
SABER - System Agnostic Background Error Representation
SABER provides generic software utilities for computing and working with the background error covariance matrix (B matrix). Currently, it features BUMP, the Background error on an Unstructured Mesh Package, which computes B from an ensemble of forecasts. The GSI recursive filter has also been implemented here for a Gaussian grid.
While not part of the FV3-Bundle, IODA-Converters, available at https://github.com/JCSDA-internal/ioda-converters, is a repository that holds all of the scripts and utilities to convert observations from various sources and input formats to IODA-readable files. Most of these converters are written in Python3. One notable exception is the BUFR ingester that takes an input YAML file filled with BUFR mnemonics, reads the BUFR file, and stores the observation data in an IODA ObsSpace object, which can then either be saved to a file, or kept in memory.
-
Atlas- an ECMWF library for model grid structures. -
eckitandfckit- ECMWF toolkit libraries with all kinds of handy functions that are used throughout JEDI. The eckit library is written in C++ and fckit is a Fortran wrapper to eckit so that the tools can be called from Fortran code. Some example functionality include grabbing configuration parameters from YAML files, exception handling, MPI wrappers, or how to compute a great circle difference. There are hundreds of different tools. This is similar to “NCEPLIBS”. -
ecbuild- wrapper for cmake that is used to build JEDI components. -
CRTM- The Community Radiative Transfer Model -
EWOK- Experiments and Workflows Orchestration Kit. Scripts for JEDI workflows; similar to “global-workflow”; still under early development/testing.