BMI Version 3 Roadmap

General
1

Following the recent BMI Council meeting, I wanted to open the online discussion of plans for a BMI version 3.

The two big changes that the meeting attendees generally concluded were necessary were

  • Generalizing from the sets of ‘input’ and ‘output’ variables to variables that fill various roles
  • Supporting extensions in a way that supports an interoperable, open-ended ecosystem of BMI-supporting models and consumers

I’ll put some initial points about each of these in reply posts

1 Like
2

Roles of Exposed Variables

Besides input and output, participants identified several other meaningful roles of variables that BMI models may wish to expose:

  • model state (e.g. for serialization)
  • dimension parameters
  • calibration parameters
  • iterative solution input/output/control

Scott Peckham and Jessica Garrett did a more in-depth study on applications of this idea as part of their work on NOAA’s National Water Model.

3

Extensions

To support extensions, BMI models need at a minimum a way to expose the set of extensions that they implement, and to give consumers access to the functionality of each such extension

For inter-operability reasons, extensions can not be implemented as modifications of the base BMI object signature, which is necessarily static in C, C++, and Fortran.

4

They also did a prospective implementation demonstrating variable roles for one small-ish model

5

One question about variable roles that I think warrants discussion is the set structure they define. Are different roles disjoint, or can they overlap? Can the set of roles and/or their contents change during a run, or should they be fixed after initialization?

6

Two subjects of immediate interest for extensions, that the meeting attendees tentatively agreed could work in that form, were MPI parallelization and driving an iterative solution process that may couple models within a time step (as was done in XMI).

7

This sounds like a really useful update! My instinct is that it would be useful to have variables in different roles. For example, if you have a state variable (e.g. used for checkpointing), this could well be an output variable too, with the final value for the output variable being the value of the state variable after the final timestep.

On the second point about whether roles and their contents can change during runtime, I’m not sure! I can’t immediatedly think of a use case for this, but I’m sure there is one. I can imagine that bringing all sorts of complexity though.

As a side question, what is the best way of feeding in suggestions to the v3 roadmap? Via this thread?

8

For now, I think this thread, and eventually attending the next meeting. I think that’s being arranged for June.

1 Like