- mpiwg-persistence - mailman3.cels.anl.gov

Re: [mpiwg-persistence] [mpiwg-persistence/mpi-standard] WIP - Do Not Merge: Persistent partcomm 2019 (#2)
by Tony Skjellum 02 Oct '19

02 Oct '19

Ryan, I am not able to join either ... I am not sure we should proceed today. Tony Anthony Skjellum, PhD 205-807-4968 > On Oct 2, 2019, at 6:41 AM, HOLMES Daniel via mpiwg-persistence <mpiwg-persistence(a)lists.mpi-forum.org> wrote: > > Hi all, > > I am off work sick today. I will not be joining the call later. > > Cheers, > Dan. > — > Dr Daniel Holmes PhD > Architect (HPC Research) > d.holmes(a)epcc.ed.ac.uk > 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 1 Oct 2019, at 22:15, Ryan Grant <notifications(a)github.com> wrote: >> >> @regrant pushed 1 commit. >> >> 89eeb85 cleaning up language before wg meeting >> — >> You are receiving this because you are subscribed to this thread. >> View it on GitHub or mute the thread. >> > > _______________________________________________ > mpiwg-persistence mailing list > mpiwg-persistence(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-persistence

1 0

Re: [mpiwg-persistence] [mpiwg-persistence/mpi-standard] WIP - Do Not Merge: Persistent partcomm 2019 (#2)
by HOLMES Daniel 02 Oct '19

02 Oct '19

Hi all, I am off work sick today. I will not be joining the call later. Cheers, Dan. — Dr Daniel Holmes PhD Architect (HPC Research) d.holmes(a)epcc.ed.ac.uk<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 1 Oct 2019, at 22:15, Ryan Grant <notifications(a)github.com<mailto:[email protected]>> wrote: @regrant<https://github.com/regrant> pushed 1 commit. * 89eeb85<https://github.com/mpiwg-persistence/mpi-standard/commit/89eeb85e817967aaf2…> cleaning up language before wg meeting — You are receiving this because you are subscribed to this thread. View it on GitHub<https://github.com/mpiwg-persistence/mpi-standard/pull/2/files/0a56dff335bc…> or mute the thread<https://github.com/notifications/unsubscribe-auth/ADD7YSREOWWXKNV3LBF3WHTQM…>.

1 0

Re: [mpiwg-persistence] FYI 10am Eastern meeting today--Topic: Partitioned Comms---
by Skjellum, Anthony 25 Sep '19

25 Sep '19

The meeting of persistence WG on partitioned comms is confirmed for 10am Eastern today via zoom: https://tennessee.zoom.us/j/9916910516 Also sent Forum wide, as requested. Thanks, Tony [https://d24cgw3uvb9a9h.cloudfront.net/static/93679/image/thumb.png]<https://tennessee.zoom.us/j/9916910516> Join our Cloud HD Video Meeting now<https://tennessee.zoom.us/j/9916910516> Zoom is the leader in modern enterprise video communications, with an easy, reliable cloud platform for video and audio conferencing, chat, and webinars across mobile, desktop, and room systems. Zoom Rooms is the original software-based conference room solution used around the world in board, conference, huddle, and training rooms, as well as executive offices and classrooms. Founded in 2011, Zoom helps businesses and organizations bring their teams together in a frictionless environment to get more done. Zoom is a publicly traded company headquartered in San Jose, CA. tennessee.zoom.us Here is the full invite: Hi there, Anthony Skjellum is inviting you to a scheduled Zoom meeting. Topic: Anthony Skjellum's Personal Meeting Room Join from PC, Mac, Linux, iOS or Android: https://tennessee.zoom.us/j/9916910516 Or iPhone one-tap (US Toll): +16468769923,9916910516# or +16699006833,9916910516# Or Telephone: Dial: +1 646 876 9923 (US Toll) +1 669 900 6833 (US Toll) Meeting ID: 991 691 0516 International numbers available: https://zoom.us/u/acVk33oBeV Or an H.323/SIP room system: H.323: 162.255.37.11 (US West) or 162.255.36.11 (US East) Meeting ID: 991 691 0516 SIP: 9916910516(a)zoomcrc.com Thanks, Tony Anthony Skjellum, PhD Professor of Computer Science and Chair of Excellence Director, SimCenter University of Tennessee at Chattanooga (UTC) tony-skjellum(a)utc.edu [or skjellum(a)gmail.com] cell: 205-807-4968 ________________________________ From: Skjellum, Anthony Sent: Wednesday, September 25, 2019 8:08 AM To: mpiwg-persistence(a)lists.mpi-forum.org <mpiwg-persistence(a)lists.mpi-forum.org> Cc: Martin Schulz <schulzm(a)in.tum.de> Subject: FYI 10am Eastern meeting today--Topic: Partitioned Comms--- Hi, I am presently verifying that Ryan Grant is available to continue our efforts to finalize the Partitioned Comms. chapter and ticket for the December meeting. Once verified, I will also alert the entire forum, as requested by Martin Schulz. Thanks, Tony Anthony Skjellum, PhD Professor of Computer Science and Chair of Excellence Director, SimCenter University of Tennessee at Chattanooga (UTC) tony-skjellum(a)utc.edu [or skjellum(a)gmail.com] cell: 205-807-4968

1 0

FYI 10am Eastern meeting today--Topic: Partitioned Comms---
by Skjellum, Anthony 25 Sep '19

25 Sep '19

Hi, I am presently verifying that Ryan Grant is available to continue our efforts to finalize the Partitioned Comms. chapter and ticket for the December meeting. Once verified, I will also alert the entire forum, as requested by Martin Schulz. Thanks, Tony Anthony Skjellum, PhD Professor of Computer Science and Chair of Excellence Director, SimCenter University of Tennessee at Chattanooga (UTC) tony-skjellum(a)utc.edu [or skjellum(a)gmail.com] cell: 205-807-4968

1 0

Wednesday 10am Eastern meeting--- AGENDA--Persistent/Collective WG
by Skjellum, Anthony 17 Sep '19

17 Sep '19

We will meet to discuss the refinement of the Partitioned communication proposal, as preliminary to re-reading in December. Usual zoom. Anthony Skjellum, PhD Professor of Computer Science and Chair of Excellence Director, SimCenter University of Tennessee at Chattanooga (UTC) tony-skjellum(a)utc.edu [or skjellum(a)gmail.com] cell: 205-807-4968

1 0

Re: [mpiwg-persistence] Unused persistent collectives info keys in Annex
by HOLMES Daniel 30 Aug '19

30 Aug '19

Hi Wesley, In which case, the new info key that we want in connection with persistent collectives (#83) is either an errata for an as-yet-unreleased version of the MPI Standard (except, perhaps, it could fix the SC18Draft version, which was kinda published) OR it has already missed the MPI-4.0 deadline. I would prefer that we follow the errata procedure (reading in Dec, only-vote in 2020Q1) and write the change-log for it as a tweak to the existing MPI-4.0 change-log entry for persistent collectives - as if the info key ticket had always been part of the main persistent collectives ticket. Note that removing the spurious info keys in the Annex could be a ticket-0/chapter committee tidy-up of the chapter, which can be done any time without formal approval by the Forum at large. Cheers, Dan. — Dr Daniel Holmes PhD Architect (HPC Research) d.holmes(a)epcc.ed.ac.uk<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 29 Aug 2019, at 21:10, Wesley Bland <work(a)wesbland.com<mailto:[email protected]>> wrote: According to our plan, this was the last meeting at which new proposals could be read in order to make that deadline. I’d be very hesitant to add yet another proposal type beyond our current three (normal, errata, no-no) in order to rush things in. On Aug 29, 2019, at 9:01 AM, HOLMES Daniel via mpiwg-persistence <mpiwg-persistence(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: Hi Martin, Procedurally, do we have enough time (that is, enough face-to-face meetings) to read a full proposal and get both the 1st vote and the 2nd vote done before the deadline imposed by our intention to release MPI-4.0 at SC20 which requires prior ratification of a release candidate? Note that #83 is not on the agenda for Zurich. The errata procedure only requires one formal vote, which shaves off one face-to-face meeting from the critical path (vs. the full proposal procedure) - although I agree it is a little unclear which version is being corrected. Using errata for new functionality suggests misuse of the “correct a small mistake” procedure as a “short-circuit for a small addition” procedure. OTOH, maybe we should innovate and approve such a “small addition” procedure? Maybe some changes need two formal votes but others only need one? Could we introduce a no-no-vote type of approval-by-acclamation at the end of the formal reading meeting to decide whether the proposal just read is “small” (needs one vote) or not (needs two votes)? Alternatively, perhaps the rules could permit 2nd votes at the start of the release candidate meeting, with the thing-to-be-gone-through-page-by-page being affected by the result(s) of that voting block with a short intermission while the document editor merges the successful pull requests (or a longer intermission if there are any merge conflicts that need fixing)? Cheers, Dan. — Dr Daniel Holmes PhD Architect (HPC Research) d.holmes(a)epcc.ed.ac.uk<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 29 Aug 2019, at 14:11, Martin Schulz via mpiwg-persistence <mpiwg-persistence(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: Hi Tony, all, I hope I fully followed this :) Doing an errata item seems a bit backwards to me, as we haven’t published the standard, yet. Also, removing it and then re-adding it with 83 seems odd. What about just removing the two keys that are not needed with 83 through the no/no process? Wouldn’t that be all that is needed? Martin — Prof. Dr. Martin Schulz, Chair of Computer Architecture and Parallel Systems Department of Informatics, TU-Munich, Boltzmannstraße 3, D-85748 Garching Member of the Board of Directors at the Leibniz Supercomputing Centre (LRZ) Email: schulzm(a)in.tum.de<mailto:[email protected]> On 29. Aug 2019, at 12:31, Skjellum, Anthony <Tony-Skjellum(a)utc.edu<mailto:[email protected]>> wrote: Hi, thank you... we will issue an appropriate change to remove these... they are not part of ticket #25 as approved...and so we must issue an erratum on ticket #25. They split off into ticket #83 in March, 2018. We itrerated multiple times on having or not having these info keys as part of ticket #25 and we must have missed removing completely. Such info keys are part of a second viable ticket we that we split out are still working on ... none belong in the standard yet. The first key value is part of ticket 83 as of now... which will get a no no plus vote in December (it had its reading priorly), introducing the first key... since acceptance is anticipated. Only examples for this ticket need to be fixed. Plus now evidently Annex 1.5 :-) too. The second and third key values are currently part of no proposed ticket. They are vestigial. So, our plan is to remove all mention of them with appropriate process and then watch for the passage of 83. :-) I will make sure that no no vote ticket for 83 also includes adding the first key to the Annex 1.5. I will ask Bill Gropp and Martin Schulz for advice on fixing this. They are cc’d. Tony Anthony Skjellum, PhD 205-807-4968 On Aug 29, 2019, at 5:12 AM, Joseph Schuchart <schuchart(a)hlrs.de<mailto:[email protected]>> wrote: Tony, I just rebased my MPI PR to the MPI 4.x branch. Looking at the info keys, I found that there are info keys in Annex A.1.5 that stem from the persistent collectives chapter but the text mentioning them was commented out there (git blame mentions you as the last author of that part). It seems that the info keys in the annex are a relic of this text. The keys in question are: mpi_assert_strict_start_ordering mpi_optimization_goal mpi_reuse_count Are you planning to revive these keys or should they be removed? Best regards, Joseph -- Dipl.-Inf. Joseph Schuchart High Performance Computing Center Stuttgart (HLRS) Nobelstr. 19 D-70569 Stuttgart Tel.: +49(0)711-68565890 Fax: +49(0)711-6856832 E-Mail: schuchart(a)hlrs.de<mailto:[email protected]> _______________________________________________ mpiwg-persistence mailing list mpiwg-persistence(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-persistence _______________________________________________ mpiwg-persistence mailing list mpiwg-persistence(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-persistence

1 0

Re: [mpiwg-persistence] Unused persistent collectives info keys in Annex
by Wesley Bland 29 Aug '19

29 Aug '19

According to our plan, this was the last meeting at which new proposals could be read in order to make that deadline. I’d be very hesitant to add yet another proposal type beyond our current three (normal, errata, no-no) in order to rush things in. > On Aug 29, 2019, at 9:01 AM, HOLMES Daniel via mpiwg-persistence <mpiwg-persistence(a)lists.mpi-forum.org> wrote: > > Hi Martin, > > Procedurally, do we have enough time (that is, enough face-to-face meetings) to read a full proposal and get both the 1st vote and the 2nd vote done before the deadline imposed by our intention to release MPI-4.0 at SC20 which requires prior ratification of a release candidate? Note that #83 is not on the agenda for Zurich. > > The errata procedure only requires one formal vote, which shaves off one face-to-face meeting from the critical path (vs. the full proposal procedure) - although I agree it is a little unclear which version is being corrected. Using errata for new functionality suggests misuse of the “correct a small mistake” procedure as a “short-circuit for a small addition” procedure. > > OTOH, maybe we should innovate and approve such a “small addition” procedure? Maybe some changes need two formal votes but others only need one? Could we introduce a no-no-vote type of approval-by-acclamation at the end of the formal reading meeting to decide whether the proposal just read is “small” (needs one vote) or not (needs two votes)? > > Alternatively, perhaps the rules could permit 2nd votes at the start of the release candidate meeting, with the thing-to-be-gone-through-page-by-page being affected by the result(s) of that voting block with a short intermission while the document editor merges the successful pull requests (or a longer intermission if there are any merge conflicts that need fixing)? > > Cheers, > Dan. > — > Dr Daniel Holmes PhD > Architect (HPC Research) > d.holmes(a)epcc.ed.ac.uk <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 29 Aug 2019, at 14:11, Martin Schulz via mpiwg-persistence <mpiwg-persistence(a)lists.mpi-forum.org <mailto:[email protected]>> wrote: >> >> Hi Tony, all, >> >> I hope I fully followed this :) >> >> Doing an errata item seems a bit backwards to me, as we haven’t published the standard, yet. Also, removing it and then re-adding it with 83 seems odd. What about just removing the two keys that are not needed with 83 through the no/no process? Wouldn’t that be all that is needed? >> >> Martin >> >> >> — >> Prof. Dr. Martin Schulz, Chair of Computer Architecture and Parallel Systems >> Department of Informatics, TU-Munich, Boltzmannstraße 3, D-85748 Garching >> Member of the Board of Directors at the Leibniz Supercomputing Centre (LRZ) >> Email: schulzm(a)in.tum.de <mailto:[email protected]> >> >> >> >> >> >> >> >> >>> On 29. Aug 2019, at 12:31, Skjellum, Anthony <Tony-Skjellum(a)utc.edu <mailto:[email protected]>> wrote: >>> >>> Hi, thank you... we will issue an appropriate change to remove these... they are not part of ticket #25 as approved...and so we must issue an erratum on ticket #25. They split off into ticket #83 in March, 2018. >>> >>> We itrerated multiple times on having or not having these info keys as part of ticket #25 and we must have missed removing completely. >>> >>> Such info keys are part of a second viable ticket we that we split out are still working on ... none belong in the standard yet. The first key value is part of ticket 83 as of now... >>> which will get a no no plus vote in December (it had its reading priorly), introducing the first key... since acceptance is anticipated. Only examples for this ticket need to be fixed. Plus now evidently Annex 1.5 :-) too. >>> >>> The second and third key values are currently part of no proposed ticket. >>> They are vestigial. >>> >>> So, our plan is to remove all mention of them with appropriate process and then watch for the passage of 83. :-) >>> >>> I will make sure that no no vote ticket for 83 also includes adding the first key to the Annex 1.5. >>> >>> I will ask Bill Gropp and Martin Schulz for advice on fixing this. They are cc’d. >>> >>> Tony >>> >>> Anthony Skjellum, PhD >>> 205-807-4968 >>> >>> >>>> On Aug 29, 2019, at 5:12 AM, Joseph Schuchart <schuchart(a)hlrs.de <mailto:[email protected]>> wrote: >>>> >>>> Tony, >>>> >>>> I just rebased my MPI PR to the MPI 4.x branch. Looking at the info keys, I found that there are info keys in Annex A.1.5 that stem from the persistent collectives chapter but the text mentioning them was commented out there (git blame mentions you as the last author of that part). It seems that the info keys in the annex are a relic of this text. The keys in question are: >>>> >>>> mpi_assert_strict_start_ordering >>>> mpi_optimization_goal >>>> mpi_reuse_count >>>> >>>> Are you planning to revive these keys or should they be removed? >>>> >>>> Best regards, >>>> Joseph >>>> -- >>>> Dipl.-Inf. Joseph Schuchart >>>> High Performance Computing Center Stuttgart (HLRS) >>>> Nobelstr. 19 >>>> D-70569 Stuttgart >>>> >>>> Tel.: +49(0)711-68565890 >>>> Fax: +49(0)711-6856832 >>>> E-Mail: schuchart(a)hlrs.de <mailto:[email protected]> >> >> _______________________________________________ >> mpiwg-persistence mailing list >> mpiwg-persistence(a)lists.mpi-forum.org <mailto:[email protected]> >> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-persistence > > _______________________________________________ > mpiwg-persistence mailing list > mpiwg-persistence(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-persistence

1 0

Re: [mpiwg-persistence] Unused persistent collectives info keys in Annex
by HOLMES Daniel 29 Aug '19

29 Aug '19

Hi Martin, Procedurally, do we have enough time (that is, enough face-to-face meetings) to read a full proposal and get both the 1st vote and the 2nd vote done before the deadline imposed by our intention to release MPI-4.0 at SC20 which requires prior ratification of a release candidate? Note that #83 is not on the agenda for Zurich. The errata procedure only requires one formal vote, which shaves off one face-to-face meeting from the critical path (vs. the full proposal procedure) - although I agree it is a little unclear which version is being corrected. Using errata for new functionality suggests misuse of the “correct a small mistake” procedure as a “short-circuit for a small addition” procedure. OTOH, maybe we should innovate and approve such a “small addition” procedure? Maybe some changes need two formal votes but others only need one? Could we introduce a no-no-vote type of approval-by-acclamation at the end of the formal reading meeting to decide whether the proposal just read is “small” (needs one vote) or not (needs two votes)? Alternatively, perhaps the rules could permit 2nd votes at the start of the release candidate meeting, with the thing-to-be-gone-through-page-by-page being affected by the result(s) of that voting block with a short intermission while the document editor merges the successful pull requests (or a longer intermission if there are any merge conflicts that need fixing)? Cheers, Dan. — Dr Daniel Holmes PhD Architect (HPC Research) d.holmes(a)epcc.ed.ac.uk<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 29 Aug 2019, at 14:11, Martin Schulz via mpiwg-persistence <mpiwg-persistence(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: Hi Tony, all, I hope I fully followed this :) Doing an errata item seems a bit backwards to me, as we haven’t published the standard, yet. Also, removing it and then re-adding it with 83 seems odd. What about just removing the two keys that are not needed with 83 through the no/no process? Wouldn’t that be all that is needed? Martin — Prof. Dr. Martin Schulz, Chair of Computer Architecture and Parallel Systems Department of Informatics, TU-Munich, Boltzmannstraße 3, D-85748 Garching Member of the Board of Directors at the Leibniz Supercomputing Centre (LRZ) Email: schulzm(a)in.tum.de<mailto:[email protected]> On 29. Aug 2019, at 12:31, Skjellum, Anthony <Tony-Skjellum(a)utc.edu<mailto:[email protected]>> wrote: Hi, thank you... we will issue an appropriate change to remove these... they are not part of ticket #25 as approved...and so we must issue an erratum on ticket #25. They split off into ticket #83 in March, 2018. We itrerated multiple times on having or not having these info keys as part of ticket #25 and we must have missed removing completely. Such info keys are part of a second viable ticket we that we split out are still working on ... none belong in the standard yet. The first key value is part of ticket 83 as of now... which will get a no no plus vote in December (it had its reading priorly), introducing the first key... since acceptance is anticipated. Only examples for this ticket need to be fixed. Plus now evidently Annex 1.5 :-) too. The second and third key values are currently part of no proposed ticket. They are vestigial. So, our plan is to remove all mention of them with appropriate process and then watch for the passage of 83. :-) I will make sure that no no vote ticket for 83 also includes adding the first key to the Annex 1.5. I will ask Bill Gropp and Martin Schulz for advice on fixing this. They are cc’d. Tony Anthony Skjellum, PhD 205-807-4968 On Aug 29, 2019, at 5:12 AM, Joseph Schuchart <schuchart(a)hlrs.de<mailto:[email protected]>> wrote: Tony, I just rebased my MPI PR to the MPI 4.x branch. Looking at the info keys, I found that there are info keys in Annex A.1.5 that stem from the persistent collectives chapter but the text mentioning them was commented out there (git blame mentions you as the last author of that part). It seems that the info keys in the annex are a relic of this text. The keys in question are: mpi_assert_strict_start_ordering mpi_optimization_goal mpi_reuse_count Are you planning to revive these keys or should they be removed? Best regards, Joseph -- Dipl.-Inf. Joseph Schuchart High Performance Computing Center Stuttgart (HLRS) Nobelstr. 19 D-70569 Stuttgart Tel.: +49(0)711-68565890 Fax: +49(0)711-6856832 E-Mail: schuchart(a)hlrs.de<mailto:[email protected]> _______________________________________________ mpiwg-persistence mailing list mpiwg-persistence(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-persistence

1 0

Re: [mpiwg-persistence] Unused persistent collectives info keys in Annex
by schulzm＠in.tum.de 29 Aug '19

29 Aug '19

Hi Tony, all, I hope I fully followed this :) Doing an errata item seems a bit backwards to me, as we haven’t published the standard, yet. Also, removing it and then re-adding it with 83 seems odd. What about just removing the two keys that are not needed with 83 through the no/no process? Wouldn’t that be all that is needed? Martin — Prof. Dr. Martin Schulz, Chair of Computer Architecture and Parallel Systems Department of Informatics, TU-Munich, Boltzmannstraße 3, D-85748 Garching Member of the Board of Directors at the Leibniz Supercomputing Centre (LRZ) Email: schulzm(a)in.tum.de > On 29. Aug 2019, at 12:31, Skjellum, Anthony <Tony-Skjellum(a)utc.edu> wrote: > > Hi, thank you... we will issue an appropriate change to remove these... they are not part of ticket #25 as approved...and so we must issue an erratum on ticket #25. They split off into ticket #83 in March, 2018. > > We itrerated multiple times on having or not having these info keys as part of ticket #25 and we must have missed removing completely. > > Such info keys are part of a second viable ticket we that we split out are still working on ... none belong in the standard yet. The first key value is part of ticket 83 as of now... > which will get a no no plus vote in December (it had its reading priorly), introducing the first key... since acceptance is anticipated. Only examples for this ticket need to be fixed. Plus now evidently Annex 1.5 :-) too. > > The second and third key values are currently part of no proposed ticket. > They are vestigial. > > So, our plan is to remove all mention of them with appropriate process and then watch for the passage of 83. :-) > > I will make sure that no no vote ticket for 83 also includes adding the first key to the Annex 1.5. > > I will ask Bill Gropp and Martin Schulz for advice on fixing this. They are cc’d. > > Tony > > Anthony Skjellum, PhD > 205-807-4968 > > >> On Aug 29, 2019, at 5:12 AM, Joseph Schuchart <schuchart(a)hlrs.de> wrote: >> >> Tony, >> >> I just rebased my MPI PR to the MPI 4.x branch. Looking at the info keys, I found that there are info keys in Annex A.1.5 that stem from the persistent collectives chapter but the text mentioning them was commented out there (git blame mentions you as the last author of that part). It seems that the info keys in the annex are a relic of this text. The keys in question are: >> >> mpi_assert_strict_start_ordering >> mpi_optimization_goal >> mpi_reuse_count >> >> Are you planning to revive these keys or should they be removed? >> >> Best regards, >> Joseph >> -- >> Dipl.-Inf. Joseph Schuchart >> High Performance Computing Center Stuttgart (HLRS) >> Nobelstr. 19 >> D-70569 Stuttgart >> >> Tel.: +49(0)711-68565890 >> Fax: +49(0)711-6856832 >> E-Mail: schuchart(a)hlrs.de

1 0

Re: [mpiwg-persistence] Unused persistent collectives info keys in Annex
by Skjellum, Anthony 29 Aug '19

29 Aug '19

Hi, thank you... we will issue an appropriate change to remove these... they are not part of ticket #25 as approved...and so we must issue an erratum on ticket #25. They split off into ticket #83 in March, 2018. We itrerated multiple times on having or not having these info keys as part of ticket #25 and we must have missed removing completely. Such info keys are part of a second viable ticket we that we split out are still working on ... none belong in the standard yet. The first key value is part of ticket 83 as of now... which will get a no no plus vote in December (it had its reading priorly), introducing the first key... since acceptance is anticipated. Only examples for this ticket need to be fixed. Plus now evidently Annex 1.5 :-) too. The second and third key values are currently part of no proposed ticket. They are vestigial. So, our plan is to remove all mention of them with appropriate process and then watch for the passage of 83. :-) I will make sure that no no vote ticket for 83 also includes adding the first key to the Annex 1.5. I will ask Bill Gropp and Martin Schulz for advice on fixing this. They are cc’d. Tony Anthony Skjellum, PhD 205-807-4968 > On Aug 29, 2019, at 5:12 AM, Joseph Schuchart <schuchart(a)hlrs.de> wrote: > > Tony, > > I just rebased my MPI PR to the MPI 4.x branch. Looking at the info keys, I found that there are info keys in Annex A.1.5 that stem from the persistent collectives chapter but the text mentioning them was commented out there (git blame mentions you as the last author of that part). It seems that the info keys in the annex are a relic of this text. The keys in question are: > > mpi_assert_strict_start_ordering > mpi_optimization_goal > mpi_reuse_count > > Are you planning to revive these keys or should they be removed? > > Best regards, > Joseph > -- > Dipl.-Inf. Joseph Schuchart > High Performance Computing Center Stuttgart (HLRS) > Nobelstr. 19 > D-70569 Stuttgart > > Tel.: +49(0)711-68565890 > Fax: +49(0)711-6856832 > E-Mail: schuchart(a)hlrs.de

1 0