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:

1. Inherit from mist::api - minor code change in Geometry/State/Increment; equivalent to current
2. Inherit from mist::api + call into utils - granular offload of implementation work to utils
3. 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