Agenda for 2022-10-27 BMI Council meeting

[mdpiper]

Here's the agenda for this Thursday's Council meeting:

• Extensions to core BMI
• New language bindings
• Add support for geospatial data #99: start RFC process

See you at 1 pm MT.

[mdpiper]

Meeting notes

Log of meeting discussion in the comments below. May be messy, but I'll come back and edit later.

[mdpiper]

We should make the Zoom link public & post it here. Meetings should be open to all in community.

[mdpiper]

Extensions to core BMI

Idealized use cases from @gregtucker:

1. BMI will grow. Add to BMI to support new functionality. Broad applicability. But loses "B" in Basic
2. B is Basic. Makes it easier for people to implement. Extensions for HPC, parallel.

[mdpiper]

@mdpiper We'll make an issue first with a plan. If people are happy with it, we can implement plan in a PR.

[mdpiper]

@peckhams We typically think of explicit time stepping. Any issues with implicit time step?

[mdpiper]

@hrajagers This should be OK, they've done this at Deltares.

[mdpiper]

@RolfHut Has a PR in with get_state and set_state functions. Should take care of implicit time step.

[mdpiper]

@peckhams Has also implemented get/set state in his NOAA work with Fred.

[mdpiper]

Language extensions

How can we handle new language specifications that we don't know well, like Julia and R?

[mdpiper]

@peckhams We should support as many languages as possible. More languages increase strength of BMI.

[mdpiper]

@gregtucker How should we present language specifications?

[mdpiper]

@rcabell: NetCDF supports only C, C++, Fortran. But many many unofficial implemetations. Present without support burden.

[mdpiper]

@hrajagers Before inviting new languages spec developers to Council, have a waiting period to get interoperability.

[mdpiper]

@RolfHut The Octave and R BMI specs were written on the fly, as needed for coupling, so they may need review.

[mdpiper]

Geospatial BMI support

Ask the Council for advice on #99. Should it go through RFC, or possibly be broken into smaller PRs?

[mdpiper]

@RolfHut Social models have no need for a grid, so it might be good to make grids an extension.

[mdpiper]

@peckhams We should be careful with the wording of how the get_grid_crs function works. It should return a standard representation of a CRS, not any string.

[rcabell]

Models on irregular meshes or polygon elements wouldn't work with this either, +1 for extension

[mdpiper]

@peckhams We should make sure the output of this function can effectively be used, e.g., for reprojection.

[mdpiper]

@mcflugen How do we word get_var_units? The wording for get_grid_crs could be approached in a similar manner.

[mdpiper]

Post-meeting actions

1. @mcflugen and @mdpiper will write up a plan for extensions and post as an issue. If the Council is happy with the plan, we'll implement it as a PR.
2. @mdpiper will break up Add support for geospatial data #99, making get_grid_crs an extension. (Depends on above)