

A Variable stores bulk data.Īn Attribute stores smaller quantities of metadata, and canīe attached to either a Group or a Variable. It is a logicalĬollection of Variables and Attributes that describes some As IODA development proceeds, we expect the diversity of supported backend engines to continue to grow.ĭata in IODA are stored in a structure Groups, Variables, andĪttributes. The same frontend API can thus access data through a variety of file formats and other data channels, implemented as backend engines.

In the code component we call ioda-engines, we separate out how the data are stored (the backend engine) from how an end user can access it (the frontend engine). That is not to say that IODA relies on HDF5 or NetCDF4 for its input. HDF5 also forms the basis of the popular NetCDF (version 4) file format that is widely used in the weather forecasting community. HDF5 (Hierarchical Data Format, version 5) is a well-established standard in the high-performance computing (HPC) community for for efficient processing and storage of large data volumes. The IODA data model is based on the HDF5 Data Model both in its high-level design and its low-level implementation. This separation of concerns is achieved through an abstract data model that is implemented through a generic set of interfaces what programmers call an API (Application Programming Interface). Conversely, scientists and developers who are integrating new observational instruments into JEDI need not concern themselves with the details of how these observational data will be used. In short, developers who are implementing new DA algorithms or interfacing new models into JEDI should not need to worry about the details of how observational data is organized in files.
IODA COPYRIGHT SOFTWARE
The principle software design objective that guides IODA development is what is known in the software engineering world as the separation of concerns.

The Interface for Observational Data Assimilation (IODA) is the component of JEDI that handles observational data.
