Notes from parallel BMI planning meeting I

[mdpiper]

On 2023 Oct 17, we held a meeting (over Zoom) to discuss how BMI could work in a parallel code. In attendance were @hrajagers, @jdhughes-usgs, @rcabell, @scrasmussen, and @mdpiper. (These are Mark's sketchy notes.)

Bert presented slides to the group with the thoughts he's put into parallel BMI design.

Bert: It's best to have one interface. Not BMI for single and ESMF or Oasis for parallel. This is a solvable problem. The challenge is in data transfer and regridding. Move these to a third party library. Need to define what the BMI functions should be.

Bert showed his ideas for new functions, or changes to existing functions, that parallel BMI would need.

Ryan and Soren need a parallel BMI implementation soon for their work in coupling WRF-Hydro with MODFLOW 6.

Soren says just a rough draft of the required BMI functions would be enough for him to start working. It doesn't have to be perfect right now.

Bert will write up his recommendations and send them out in about two weeks.

We should meet again in about a month to discuss.

[RolfHut]

I seem to have dropped out of the planning for this at some point, but would like to be roped back in. This is also highly relevant for a post-doc on data assimilation (with eWaterCycle) that starts with us shortly. Can you make sure I'm on the list for that next meeting?

[mdpiper]

Yes, absolutely!

[hrajagers]

I’ve uploaded a draft for the BMI parallel API to the CSDMS repository.
Branch https://github.com/csdms/bmi/tree/hrajagers/parallel-bmi

You can review the changes as a file diff:
develop...hrajagers/parallel-bmi

or rendered nicely by selecting one-by-one the various bmi.*.rst files
https://github.com/csdms/bmi/tree/hrajagers/parallel-bmi/docs/source

Summary of changes:

• I’ve added a main parallel comment above Table 3 in bmi.spec.rst: all functions should be called on all threads, return arguments MUST be the same unless specified otherwise. Failure conditions SHOULD be the same.
• I’ve defined parallel_initialize to pass the communicator to the model, see bmi.control_funcs.rst.
• I’ve added a series of partitioning routines to bmi.grid_funcs.rst.
• I’ve added an implementation note with flag Parallel to define the meaning of the routine arguments in a parallel context if it differs from the default meaning.

It’s currently left as a TODO how to determine whether a component does have parallel support.

[mdpiper]

The "nr" in a few of the grid functions--e.g., get_grid_global_node_nr--is a little cryptic. Would you consider using "number", "index", or "id" instead?

For example, this would change get_grid_global_node_nr to get_grid_global_node_number.