I have created a presentation here<https://docs.google.com/presentation/d/1CdPbSL_hKtHc5y-LN-IJ-IbG6fPlnWIhDaJPnvPKvrg/edit?usp=sharing> based on today's WG meeting, please feel free to update this. See you all tomorrow. Thanks, Puri ________________________________ From: mpiwg-persistence <[email protected]> on behalf of Bangalore, Purushotham via mpiwg-persistence <[email protected]> Sent: Friday, July 24, 2020 11:10 AM To: [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: [mpiwg-persistence] [mpiwg-semantic-terms] Summary of Semantics for Partitioned Communication Operations Hi All, Here is the updated spreadsheet <https://drive.google.com/file/d/1VkkqAd56lgxEt3JEt-zmGR0aC1VvLTDh/view?usp=sharing> for the appendix and the updated text<https://docs.google.com/document/d/12M6glWfNDt3WpLsf8FNug2ma0cRG2QZ_mNKnvUl19Ws/edit?usp=sharing> for the semantic terms section based on the discussion with Ryan related to partitioned communication functions this week. Please review. The basic idea is to introduce a new operation type called partitioned operation. This would require the introduction of a new stage called ready stage after the starting stage. Ryan has updated the text for the ready stage and we have added a new state transition diagram for the partitioned operations. Thanks, Puri ________________________________ From: mpiwg-semantic-terms <[email protected]> on behalf of Bangalore, Purushotham via mpiwg-semantic-terms <[email protected]> Sent: Tuesday, July 21, 2020 4:01 PM To: Rolf Rabenseifner <[email protected]> Cc: mpiwg-semantic-terms <[email protected]>; [email protected] <[email protected]> Subject: Re: [mpiwg-semantic-terms] [mpiwg-persistence] Summary of Semantics for Partitioned Communication Operations Hi Rolf, I used the text as a placeholder. This text currently appears as an advice to implementors in the partitioned communication chapter. I will let the partitioned communication WG decide the appropriate text for the footnote 🙂 Thanks, Puri ________________________________ From: Rolf Rabenseifner <[email protected]> Sent: Tuesday, July 21, 2020 3:43 PM To: Bangalore, Purushotham <[email protected]> Cc: [email protected] <[email protected]>; mpiwg-semantic-terms <[email protected]> Subject: Re: [mpiwg-semantic-terms] [mpiwg-persistence] Summary of Semantics for Partitioned Communication Operations Dear puri and all, I expect that the proposed footnote "20) Unlike MPI_SEND_INIT and MPI_RECV_INIT, MPI_PSEND_INIT and MPI_PRECV_INIT may communicate." is incorrect. MPI_SEND_INIT and MPI_RECV_INIT, MPI_PSEND_INIT and MPI_PRECV_INIT are all local procedures and we know, that local is weak local and no line in the MPI Standard can prohibit that a (weak) local is performing some "internal" communication for optimization. As long as the user's (= application programmer's) viewpoint can see only a local routine, and the freeing is also a local routine, even in the case that there was never an MPI_START, then all is fine. Maybe you meant: 20) Although these are local routines, an MPI implementation may internally already start some communication of metadata, but must guarantee that the INIT and the MPI_REQUEST_FREE are both local procedures. But such a comment should be an advice to implementors in the definition of the MPI_P..._INIT routines, and not as a footnote here. My comment is completely independent of what is written in the MPI Standard elsewhere. MPI-3.1 p 73 line 41 on persistent pt-to-pt init: "These calls involve no communication." In principle, this sentence should be substituted by "These procedures are local and do not send or receive any buffer content." But this may be a cleanup for MPI 4.1 ;-) Such a sentence should be part of the new partitioned comm. chapter! Best regards Rolf ----- Original Message -----

From: "mpiwg-semantic-terms" <[email protected]> To: [email protected] Cc: "mpiwg-semantic-terms" <[email protected]> Sent: Tuesday, July 21, 2020 8:34:09 PM Subject: Re: [mpiwg-semantic-terms] [mpiwg-persistence] Summary of Semantics for Partitioned Communication Operations

Here is the updated spreadsheet based on Dan's suggestions. I would really like the persistence WG to finalize this ASAP.

I know Ryan would like to review the changes to the chapter before it is merged during tomorrow's meeting. If there is time left after that, I would like to discuss this.

Thanks, Puri

From: mpiwg-persistence <[email protected]> on behalf of Bangalore, Purushotham via mpiwg-persistence <[email protected]> Sent: Wednesday, July 15, 2020 12:54 PM To: HOLMES Daniel <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: [mpiwg-persistence] Summary of Semantics for Partitioned Communication Operations Here are the other footnotes (I should have pasted them near footnote 20):

7) Addresses are cached on the request handle.

9) One shall not free or deallocate the bu er before the operation is freed, that is MPI_REQUEST_FREE returned.

14) Nonblocking procedure without an I pre fix.

===== I will move PREADY,...,PARRIVED after START... good suggestion.

I also agree with "ic" for the PREADY, PARRIVED procedures.

From: HOLMES Daniel <[email protected]> Sent: Wednesday, July 15, 2020 12:42 PM To: Bangalore, Purushotham <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: [mpiwg-persistence] Summary of Semantics for Partitioned Communication Operations Hi Puri,

Thanks for this - a great way to provoke some progress (no pun intended).

I would suggest: move the rows dealing with MPI_PREADY and MPI_PARRIVED between MPI_START and MPI_WAIT, i.e. in the approximate calling order.

Also, I would add “ic” for the new MPI_PREADY, MPI_PARRIVED, etc procedures - because the operation is definitely incomplete at the point in time they are called, during the time interval of their entire execution, and at the point in time they return - there is no possibility they could be completing or freeing procedures.

What are the other footnotes: 7, 9, and 14? (I could look them up but I’d have to choose the same draft version as you because the numbering changed recently.)

Cheers, Dan. — Dr Daniel Holmes PhD Architect (HPC Research) [ mailto:[email protected] | [email protected] ] Phone: +44 (0) 131 651 3465 Mobile: +44 (0) 7940 524 088 Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh, EH8 9BT — The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. —

On 15 Jul 2020, at 18:24, Bangalore, Purushotham via mpiwg-persistence < [ mailto:[email protected] | [email protected] ] > wrote:

<MPI-semantics-appendix.xlsx>

-- mpiwg-semantic-terms mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-semantic-terms

-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] . High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 . University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 . Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner<http://www.hlrs.de/people/rabenseifner> . Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) .