thank you. Anthony Skjellum, PhD Professor of Computer Science and Chair of Excellence Director, SimCenter University of Tennessee at Chattanooga (UTC) [email protected] [or [email protected]] cell: 205-807-4968 ________________________________ From: mpiwg-persistence <[email protected]> on behalf of Bangalore, Purushotham via mpiwg-persistence <[email protected]> Sent: Wednesday, July 15, 2020 3:37 PM To: [email protected] <[email protected]>; [email protected] <[email protected]> Subject: [EXT]: [mpiwg-persistence] Partitioned communication - Accelerator support External Email I am starting a new thread with the appropriate subject header to separate out the discussion on this topic. I have also cc'ed the collective communications group and removed the semantic terms group for this discussion. Thanks, Puri ________________________________ From: Skjellum, Anthony <[email protected]> Sent: Wednesday, July 15, 2020 12:53 PM To: Bangalore, Purushotham <[email protected]>; HOLMES Daniel <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: [mpiwg-persistence] Summary of Semantics for Partitioned Communication Operations We had a short meeting with Ryan and students---he advocates for a blocking PSYNC on both sides now... after start... before kernel launch on send side... Anthony Skjellum, PhD Professor of Computer Science and Chair of Excellence Director, SimCenter University of Tennessee at Chattanooga (UTC) [email protected] [or [email protected]] cell: 205-807-4968 ________________________________ From: mpiwg-persistence <[email protected]> on behalf of HOLMES Daniel via mpiwg-persistence <[email protected]> Sent: Wednesday, July 15, 2020 1:42 PM To: Purushotham Bangalore <[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) [email protected]<mailto:[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 <[email protected]<mailto:[email protected]>> wrote: <MPI-semantics-appendix.xlsx> This message is not from a UTC.EDU address. Caution should be used in clicking links and downloading attachments from unknown senders or unexpected email.