Lead by Francois H.
Overall: model interfaces and how it will evolve in JEDI
Presentation link: here
Looking at the software architecture for how to build and maintain the code into JEDI.
- Simplifying JEDI interfaces
- New library to support model-interfaces
- Example of model-interfaces
Simplicity:
- Simple way to build a small interface for file based DA experiments
- 1) Interfaces to models
- 2) Simplified interfaces to shared components
- Factor similar algorithm to reduce model-specific code; currently there are several partial implementations to this
- Goal is the simplify data ownership and interfaces without extreme duplication of data, duplication of coupling interfaces, and growing inconsistency in interface used within OOPs algorithms
- New approach:
- Shared layer within model-interface implementation
- Formalize API for use by shared components
- Synergy: if shared layer stores model data in Atlas structures, the API for shared components is easily implemented.
New library (mist):
- New library “mist” to support JEDI model interfaces, 3 components:
- An API formalizing the shared components interfaces
- Utilities for simplifying a model interface implementation
- Base classes
- oops/3247 - note, might get added to a new repo or kept in oops
- mist::api - lightweight but will be required to use shared components, equivalent to the current API but formalizing will enable future cleaning. This will be required to continue using shared components
- mist::utils - functions to set up “standard” grids from Atlas, class to represent model data, class to wrap VADAR var changes; This is a helpful building block for an Atlas-based model interface implementation
- mist::base - implements parts of OOPS model interface; inherits from mist api; intentionally does not implement I/O; This is a useful start point for new model interfaces
Should I use the mist library in my model interface?
- Opt-out: accept loss of shared components
- Opt-in: Maintain use of shared components; Possible to opt-in with minimal code change, but enables simpler interfaces by offloading implementation work
How do I use the mist library in my model interface?
Options:
- Inherit from mist::api - minor code change in Geometry/State/Increment; equivalent to current
- Inherit from mist::api + call into utils - granular offload of implementation work to utils
- Inherit from mist base classes - inherits from and implements mist::api; majority of implementation work offloaded to base classes
Examples:
NetCDF pseudo-model using mist utilities
- In this approach, implement required OOPS interface classes; Most class methods are greatly simplified by utility calls
- File-based DA experiments in O(900) lines of code
- See https://github.com/JCSDA-internal/oops/pull/3248
NetCDF pseudo-model using mist base classes
- In this approach, implement State read/write; File-based DA experiments in O(200) lines of code
- See https://github.com/JCSDA-internal/oops/pull/3249
MPAS using base classes
- A streamlined interface that calls Fortran for Geometry, I/O, Model; Requires porting some VarChanges to VADER; Structurally much simpler vs mpas-jedi
- ~4200 lines of code (vs mpas-jedi ~17000)
- Runs MPAS in-core
- Supports 3dvar with radiances and BUMP covariance
- (Still being tested, not yet ready for sharing broadly)
Discussion:
- Improved performance is still being tested (on MPAS experimental interface); should see memory reduction and saw this in SOCA
- Explicitly: Do we have to use this? Entirely optional to do so; Will be required (mist::api and base class) if using saber
- Hoping to be released in a few weeks from now (4/5)
- Will the toy models be transferred over? Most won’t be able to conform
Take a look at the available PRs and we can set up another meeting to come back together, review, and answer any questions