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
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
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...
github.com
|
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
email: askjellum@tntech.edu
cell: +1-205-807-4968