1 of 34

Future directions for JEDI model interfaces

Special Topic JEDI Weekly Meeting

Francois Hebert

Apr 2 2026

2 of 34

Simplifying JEDI interfaces
New library to support model-interfaces
Example model-interfaces

3 of 34

Define “shared components” as

JEDI-provided implementations of model-space DA components
shareable across spherical column-based model-interfaces
implemented on top of ECMWF’s Atlas library

e.g., SABER, VADER, hybrid-TLM, interpolations

(Just for this presentation)

4 of 34

Recurring requests for simplicity in different areas:

Interfaces to models

e.g., minimal interfaces for file-based DA experiments

Interfaces to shared components

e.g., passing model metadata to VADER

5 of 34

forecast model

model interface

OOPS

6 of 34

forecast model

model interface

OOPS

model specific code

but many similar algorithms across model interfaces

large API or “interaction surface”

7 of 34

shared interface

smaller API or “interaction surface”

forecast model

model interface

OOPS

less specific code

shared implementation of similar algorithms

8 of 34

shared interface

forecast model

model interface

OOPS

the “model interface”, from OOPS’s point of view

9 of 34

shared interface

forecast model

model interface

OOPS

the “model interface”, from developer point of view

10 of 34

Request: factor similar algorithms to reduce model-specific code.

recurring idea in the user community and core team
several partial implementations exist

11 of 34

Recurring requests for simplicity in different areas:

Interfaces to models

e.g., minimal interfaces for file-based DA experiments

Interfaces to shared components

e.g., passing model metadata to VADER

12 of 34

model interface

OOPS

owns data

transforms data

13 of 34

model interface

OOPS

shared components

transforms data

access to data?

owns data

14 of 34

model interface

OOPS

shared components

transforms data

atlas::FieldSet

owns copy of data

synchronizes data representations

transforms copy of data

owns data

15 of 34

model interface

OOPS

shared components

transforms data

atlas::FieldSet

owns copy of data

synchronizes data representations

owns data

transforms copy of data

16 of 34

Problematic software architecture

duplication of data

State<MODEL> and FieldSet

duplication and coupling of interfaces

Geometry<MODEL> vs GeometryData vs FunctionSpace
State<MODEL> vs FieldSet

growing inconsistency in interface use within OOPS algo’s

Request: simplify data ownership and interfaces

17 of 34

New approach, to simplify both aspects:

new shared layer within model-interface implementation

reduce model-specific code required
remain extensible for model-specific requirements

formalized API for use by shared components

enable components to act on model interface data directly
step towards removing data duplication in OOPS

Synergy: if shared layer stores model data in Atlas structures, the API for shared components is easily implemented.

18 of 34

shared interface

model interface

OOPS

shared components

owns data

the “model interface” from OOPS’s point of view

transforms on State, Increment data

formalized API for transforms on atlas::Fieldset data

19 of 34

Simplifying JEDI interfaces
New library to support model interfaces
Implementation examples (of model interfaces)

20 of 34

New library “mist” in support of JEDI model interfaces

An API formalizing the shared components interface
Utilities for simplifying a model interface implementation
Base classes (ditto)

See https://github.com/JCSDA-internal/oops/pull/3247

Mature enough to write code
Will probably stay in OOPS, but chance of new repo

21 of 34

In mist::api, the current API for Atlas structures is formalized

Virtual base classes encode API required by shared components,

FunctionSpace etc from Geometry
to/fromFieldSet from State/Increment

Equivalent to current API, but formalizing it enables future cleaning.

API will be required to continue using shared components

22 of 34

In mist::utils … utilities to simplify model-interface implementation

Of note,

functions to set up “standard” grids from Atlas
class to represent model data in atlas::Fields
class to wrap VADER variable changes

Helpful building-blocks for an Atlas-based model interface implementation.

23 of 34

In mist::base, a set of base classes implementing parts of the OOPS model interface

owns Atlas data wrapped in mist::utils::Fields
inherits from mist::api and implements the API methods
implements most of the OOPS model interface
intentionally does not implement I/O, Model…
extensible

Useful start point for new model interfaces: implement I/O to unlock pseudo-model DA.

24 of 34

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

25 of 34

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

26 of 34

Simplifying JEDI interfaces
New library to support model interfaces
Implementation examples (of model interfaces)

27 of 34

Example interface implementations

Minimal NetCDF pseudo-model

Using mist utilities only
Using mist base classes

MPAS, using base classes

28 of 34

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

29 of 34

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

30 of 34

MPAS using base classes

A streamlined interface

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)

31 of 34

New MPAS interface: 120km 3DVar increment from sondes + BUMP

32 of 34

Aside on surprise MPAS interface…

Today, JEDI model interfaces can essentially be generated on demand.

Not trying to undermine anyone here!

One human, one week, one agentic assistant (~$20)

Empowering or anxiety-inducing?

33 of 34

Examples show

Greatly simplified minimal entry point into JEDI
Same framework supports DA at scale with real models

Caveat

No LocalEnsembleDA (yet)

34 of 34

Introduced mist library to simplify JEDI interfaces

API provides a path to improve interfaces and data management in JEDI’s shared components

mist::api will become required for shared components

Utilities and base classes to simplify model interface implementations

But counting lines of code may not matter in the age of AI?
Simplified MPAS interface! TBD Will this go anywhere?

Please try it out!