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.
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?
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).
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?