Notes from parallel BMI meeting III

[mdpiper]

On 2024 Feb 29, we held a third meeting (over Zoom) to discuss how BMI could work in a parallel environment. In attendance were @hrajagers, @scrasmussen, @mcflugen, @rcabell, @PhilMiller, @jdhughes-usgs, @mjr-deltares, @gregtucker, @hellkite500, and @mdpiper. (These are Mark's clumsy notes.)

Soren on his work with Ryan on WRF-Hydro:

• Serial coupling between WRF-Hydro and MODFLOW is working.
• Not parallel yet.
• Is there a need for a parallel_finalize function?
  Phil: Don't call MPI_Finalize in a component. Call it in driver code instead. Next version of MPI (4.0) will have a better way of handling this, so every component will be able to call its own initializer and finalizer. Procedure that fits with MPI 3: Call MPI_Init in driver. Initialize components, passing communicator, Finalize components. Call MPI_Finalize in driver.

Martijn on MODFLOW 6:

• Parallel BMI version working, though not quite user-friendly yet.

Phil on his work on the NextGen framework:

• How to identify a model as serial or parallel BMI? If the framework is just handed a model... This can take the form of a rough engineering workaround.
• Call collectively or independently? This is a priority.
  Bert: This touches on the general issue of extensions.
  Eric: We've thought about this a bit, and have made examples in Python and Fortran.
  Phil: It looks like we're on a good path with extensions.
• Block partitioning shouldn't be assumed.
  Bert: Was following ESMF and OASIS. But this can be changed.

Bert generalizes the discussion to extensions:

• (I lost the thread a bit here.)
  Nels: That gets really complicated then to define what is “BMI Compliant” if an extension is required, the core BMI is no longer the “contract”
  Phil:
  Nels: So the extensions are essentially implemented alongside the BMI core implementation, just namespace separated via what is bound to a BMI struct and what is bound to either free function extensions or an extension struct bound to the core BMI structure
  Phil: Leans toward OO instead of free functions

Things we need to work on: Instantiation, collective/independent calls, extension design.

Meet again in a few weeks.

[PhilMiller]

Nels and I discussed the calling being independent vs collective, and concluded that for a baseline "MPI parallel BMI" extension, collective would be fine for NWM NextGen. If we get to the point where we have components that would benefit from more asynchronous execution, and a need to enable it for application demands, then we can define a follow-on "asynchronous MPI parallel BMI" extension that specifies this differently.

[PhilMiller]

I opened a stand-alone discussion on instantiation in #142, since that really should get some sort of resolution independent of any parallel extension.