BMIv3: Defining sets of variables exported by a model

[PhilMiller]

This is a generalization of the 'input' and 'output' sets of export items defined in BMI v2. This will enable models to present a richer range of variables to frameworks that are calling and driving them.

Example uses:

• Parameters that can be varied for calibration
• Diagnostic data (e.g. estimates of change in conserved values, internal model state)
• Data to be captured for serialization

[PhilMiller]

I posed this question to Nels:

Should there be an API to get the set of set names that a model defines?

I'm leaning toward 'no', because

1. (introspection aside) callers should only really be asking for sets whose semantics they actually know, and
2. set names are potentially a place where models could maybe usefully/meaningfully define arbitrary sets by parsing the name requested, or an unbounded number of sets

Additionally, "what sets can I expect from a given model?" seems like a very natural thing to tie into "what extensions does the model support?", and a given set name might even have different semantics around its contents depending on which of multiple conflicting extensions promise its presence

[PhilMiller]

Initially asking for review from Scott and Nels for help in drafting this well, before really looking for feedback from the broader BMI council.

[PhilMiller]

Discussed this with Nels, and made some small revisions accordingly.

[PhilMiller]

@RolfHut Eric mentioned you may not have seen this suggestion at a previous meeting. It had pretty general support. It replaces input_vars = get_input_var_names with input_vars = get_varset_members("input"), so minimal impact on teachability/readability.