Jim, and others, I would like to discuss these topics (frozen proposals from MPI-4 and 4. 1) at the next meeting on June 12: Pbuf_prepare, Parrived_any I would like to see if we can get agreement on these and push into MPI-4. 2 or the next increment
Jim, and others, I would like to discuss these topics (frozen proposals from MPI-4 and 4.1) at the next meeting on June 12:
Pbuf_prepare, Parrived_any
I would like to see if we can get agreement on these and push into MPI-4.2 or the next increment after that, rather than MPI-5.
I am sure this will take more than one discussion, since we didn't get these through before.
Note: They are both marked for MPI-5 currently, presumably because we don't have a broad opening for MPI-4.2, and we haven't agreed on an MPI-4.3.
Here are the tickets/issues:
|
|
Problem The ability to take the next available partition is not supported in the current MPI-4.0 API. Proposal The API: MPI_Parrived_any(MPI_Request prequest, int *partition, int *flag); /* C inter...
|
My apologies for long delays in follow up. We really need to resolve these issues as they impact both point-to-point partitioned and potential collective partitioned comms.
I would encourage additional commentary on the issues; Patrick has made new, relevant observations about the dual roles of Pbuf_prepare recently on ticket#302, for example.
Thank you all,
Tony
PS After that, I really do intend to hold a collective WG meeting to discuss partitioned collective ops 🙂 on June 19, or July 3 or 10, depending
what works in tandem with the Hybrid calendar.
Anthony Skjellum, PhD
Professor of Computer Science
Tennessee Technological University
cell: +1-205-807-4968