December 2019 - mpi-forum - mailman3.cels.anl.gov

Re: [Mpi-forum] Chapter Committees ACTION NEEDED
by Guillaume Mercier 25 Dec '19

25 Dec '19

Hello Santa, On 12/25/19 3:40 PM, Jeff Squyres (jsquyres) wrote: > On Dec 24, 2019, at 9:08 PM, Guillaume Mercier via mpi-forum <mpi-forum(a)lists.mpi-forum.org> wrote: >> >> I did just that: >> make PYTHON=/usr/bin/python3.8 cleandoc >> >> But the result is the same: > > Yes, that does not work right now -- we'd have to add that. I was asking if that would be useful to you. I guess the answer is yes. ;-) > > Soooo... I guess you've been a good (enough) boy this year. Git pull, and now you have that functionality. > > Merry Christmas! > > - Santa Claus Everything is A-OK! Thank you, Santa! Guillaume

1 0

Re: [Mpi-forum] Chapter Committees ACTION NEEDED
by Jeff Squyres (jsquyres) 25 Dec '19

25 Dec '19

On Dec 24, 2019, at 9:08 PM, Guillaume Mercier via mpi-forum <mpi-forum(a)lists.mpi-forum.org> wrote: > > I did just that: > make PYTHON=/usr/bin/python3.8 cleandoc > > But the result is the same: Yes, that does not work right now -- we'd have to add that. I was asking if that would be useful to you. I guess the answer is yes. ;-) Soooo... I guess you've been a good (enough) boy this year. Git pull, and now you have that functionality. Merry Christmas! - Santa Claus

1 0

Re: [Mpi-forum] Chapter Committees ACTION NEEDED
by Guillaume Mercier 24 Dec '19

24 Dec '19

Hello Jeff, I did just that: make PYTHON=/usr/bin/python3.8 cleandoc But the result is the same: Traceback (most recent call last): File "binding-tool/binding_prepass.py", line 109, in <module> main() File "binding-tool/binding_prepass.py", line 96, in main common.check_for_sufficient_version() File "/home/mercierg/Developpement/Git/A_RELIRE/mpi-pythonization/binding-tool/common.py", line 38, in check_for_sufficient_version raise RuntimeError('This python installation is too old! ' RuntimeError: This python installation is too old! Use Python 3.7 or later Makefile:396: recipe for target 'binding-prepass' failed make[1]: *** [binding-prepass] Error 1 make[1]: Leaving directory '/home/mercierg/Developpement/Git/A_RELIRE/mpi-pythonization' Makefile:412: recipe for target 'rendered-31' failed make: *** [rendered-31] Error 2 I'm pretty sure that it's possible to force your system to check against a version that is not the system version. I just need to know how to do this. And by the way, Merry Christmas ! Guillaume On 12/24/19 11:21 PM, Jeff Squyres (jsquyres) via mpi-forum wrote: > Shame on me for not reading your entire mail before replying. > > You could set your PATH before invoking `make`...? > > We could probably also do something like `make > PYTHON=/path/to/your/python3 cleandoc`, if that would be helpful. ï¿½Let > me know. > > >> On Dec 24, 2019, at 5:20 PM, Jeff Squyres <jsquyres(a)cisco.com >> <mailto:[email protected]>> wrote: >> >> The key is in the output: >> >> raise RuntimeError('This python installation is too old! ' >> RuntimeError: This python installation is too old! Use Python 3.7 or later >> >> You need at least Python 3.7. >> >> >>> On Dec 22, 2019, at 4:11 PM, Guillaume Mercier via mpi-forum >>> <mpi-forum(a)lists.mpi-forum.org >>> <mailto:[email protected]>> wrote: >>> >>> >>> Hello Jeff, >>> >>> I followed your instructions, but I'm stuck with the make cleandoc >>> command in your Git repo: >>> >>> >>> make rendered-backend BINDING_RENDER_VERSION=3.1 >>> make[1]: Entering directory >>> '/home/mercierg/Developpement/Git/A_RELIRE/mpi-pythonization' >>> Traceback (most recent call last): >>> ï¿½File "binding-tool/binding_prepass.py", line 109, in <module> >>> ï¿½ï¿½ï¿½main() >>> ï¿½File "binding-tool/binding_prepass.py", line 96, in main >>> ï¿½ï¿½ï¿½common.check_for_sufficient_version() >>> ï¿½File >>> "/home/mercierg/Developpement/Git/A_RELIRE/mpi-pythonization/binding-tool/common.py", >>> line 38, in check_for_sufficient_version >>> ï¿½ï¿½ï¿½raise RuntimeError('This python installation is too old! ' >>> RuntimeError: This python installation is too old! Use Python 3.7 or >>> later >>> Makefile:396: recipe for target 'binding-prepass' failed >>> make[1]: *** [binding-prepass] Error 1 >>> make[1]: Leaving directory >>> '/home/mercierg/Developpement/Git/A_RELIRE/mpi-pythonization' >>> Makefile:412: recipe for target 'rendered-31' failed >>> make: *** [rendered-31] Error 2 >>> >>> I have python 3.7 and 3.8 installed but the default version is >>> 2.7.15+ and I don't want to change that. >>> >>> Is there a way to modify your scripts/makefiles so that I can force >>> it to consider python 3.8 instead (and not change my system)? >>> >>> Thanks. >>> Guillaume >>> >>> >>> >>> >>> On 12/18/19 8:47 PM, Jeff Squyres (jsquyres) via mpi-forum wrote: >>>> Chapter Committees / Chairs -- >>>> We need Chapter Committees to review their chapters in three sets of >>>> upcoming document-wideï¿½changes that are slated to be merged "soon". >>>> After you complete a review, please put an "X" in the corresponding >>>> row/column for yourï¿½chapter and the specified PR in this Google >>>> spreadsheet >>>> <https://docs.google.com/spreadsheets/d/1qPAREYgeuSCMtU-EQniDilrHIYb8W0-f6Qz…>ï¿½(including >>>> an un-numbered chapter for partitioned communication). ï¿½This will >>>> let us track what has beenï¿½done / what still needs to be done. >>>> *_FIRST SET >>>> _* >>>> Bill Gropp (the MPI Standard document Editor) has two PRs with >>>> "ticket 0" changes. ï¿½However,ï¿½the changes are pervasive and touch a >>>> LOT of the document. ï¿½We therefore need Chapterï¿½Committees to review >>>> their chapters in the following two PRs: >>>> 1a. "Ticket 0 changes for MPI-4.x" >>>> https://github.com/mpi-forum/mpi-standard/pull/151 >>>> 1b. "Uniform style for Fortran code" >>>> https://github.com/mpi-forum/mpi-standard/pull/145 >>>> Deadline: Jan 7, 2020 >>>> ï¿½ ï¿½ (Yes, that's an early deadline, but we need time to merge these >>>> PRs and fix conflicts with the second set) >>>> *_SECOND SET >>>> _* >>>> The Pythonization group has Pythonized the bindings in the entire >>>> document. ï¿½We've completed aï¿½first correctness pass over the work, >>>> but we need more eyes to compare the end result of ourï¿½work to the >>>> (non-Pythonized) head of the mpi-4.x branch. >>>> To be clear: this review does not include Embiggening. ï¿½It is >>>> more-or-less the "MPI-3.1" style of function bindings. >>>> See this wiki page for instructions >>>> <https://github.com/mpiwg-large-count/large-count-issues/wiki/pythonizing-in…>. >>>> For additional information, also see the Pythonization slides >>>> presented at the Forum last week >>>> <https://docs.google.com/presentation/d/1QZyh6TbjDMu7mEcNqBFfe9fFOltaCtxgZ2Z…>. >>>> ï¿½ï¿½If you have any questions or problems, let us know in the >>>> Embiggening WG. >>>> If you just want to compare the rendered PDF: >>>> ï¿½* Here's a PDF from the head of the mpi-4.x branch >>>> ï¿½ï¿½ï¿½<https://aws.open-mpi.org/~jsquyres/forum-unofficial/mpi-report-mpi4xhead-d8…>ï¿½(i.e., >>>> ï¿½ï¿½ï¿½old/original LaTeX) >>>> ï¿½* Here's a PDF from the head of the Pythonization branch >>>> ï¿½ï¿½ï¿½<https://aws.open-mpi.org/~jsquyres/forum-unofficial/mpi-report-d8ad059-pyth…> >>>> ï¿½ï¿½ï¿½/_with no Embiggening_/ (i.e,. new/Python-rendered LaTeX) >>>> Deadline: 21 Jan, 2020 >>>> ï¿½ ï¿½ Thisï¿½gives us time to finalizeï¿½everything before the T-2 week >>>> deadline for the Portland Forum meeting. >>>> *_NOTE:_* At the ABQ Forum meeting, I asked you to commit/PR your >>>> approvals.json file thatï¿½resulted from running the tool. ï¿½This is no >>>> longer necessary -- please just mark the googleï¿½spreadsheet as >>>> described above. >>>> *_THIRD SET_* >>>> After Pythonization comes Embiggening. ï¿½We need Chapter Committees >>>> to review their chapters to ensure that API parameters were >>>> embiggened properly. >>>> You can do this by finding all "POLY" kinds in the Pythonized LaTeX >>>> bindings, and you can see 2xC bindings and 2xF08 bindings in the >>>> rendered PDF in your chapter. If you have any questions or problems, >>>> let us know in the Embiggening WG. >>>> Also check that the existing MPI-3.1 "_x" functions -- and their >>>> corresponding non-"_x" versions -- are all rendered correctly. >>>> If you just want to compare the rendered PDF: >>>> ï¿½* Here's a PDF from the head of the mpi-4.x branch >>>> ï¿½ï¿½ï¿½<https://aws.open-mpi.org/~jsquyres/forum-unofficial/mpi-report-mpi4xhead-d8…>ï¿½(i.e., >>>> ï¿½ï¿½ï¿½old/original LaTeX) >>>> ï¿½* Here's a PDF from the head of the Pythonization branch >>>> ï¿½ï¿½ï¿½<https://aws.open-mpi.org/~jsquyres/forum-unofficial/mpi-report-d8ad059-pyth…> >>>> ï¿½ï¿½ï¿½/_with Embiggening enabled_/ (i.e,. new/Python-rendered LaTeX) >>>> Deadline: 21 Jan, 2020 >>>> ï¿½ ï¿½ You can probably review the second and third sets in a single >>>> pass through the text. >>>> -- >>>> Jeff Squyres >>>> jsquyres(a)cisco.com <mailto:[email protected]> >>>> _______________________________________________ >>>> mpi-forum mailing list >>>> mpi-forum(a)lists.mpi-forum.org >>>> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum(a)lists.mpi-forum.org <mailto:[email protected]> >>> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum >> >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com <mailto:[email protected]> >> > > > -- > Jeff Squyres > jsquyres(a)cisco.com <mailto:[email protected]> > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum >

1 0

Re: [Mpi-forum] Chapter Committees ACTION NEEDED
by Jeff Squyres (jsquyres) 24 Dec '19

24 Dec '19

Shame on me for not reading your entire mail before replying. You could set your PATH before invoking `make`...? We could probably also do something like `make PYTHON=/path/to/your/python3 cleandoc`, if that would be helpful. Let me know. On Dec 24, 2019, at 5:20 PM, Jeff Squyres <jsquyres(a)cisco.com<mailto:[email protected]>> wrote: The key is in the output: raise RuntimeError('This python installation is too old! ' RuntimeError: This python installation is too old! Use Python 3.7 or later You need at least Python 3.7. On Dec 22, 2019, at 4:11 PM, Guillaume Mercier via mpi-forum <mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: Hello Jeff, I followed your instructions, but I'm stuck with the make cleandoc command in your Git repo: make rendered-backend BINDING_RENDER_VERSION=3.1 make[1]: Entering directory '/home/mercierg/Developpement/Git/A_RELIRE/mpi-pythonization' Traceback (most recent call last): File "binding-tool/binding_prepass.py", line 109, in <module> main() File "binding-tool/binding_prepass.py", line 96, in main common.check_for_sufficient_version() File "/home/mercierg/Developpement/Git/A_RELIRE/mpi-pythonization/binding-tool/common.py", line 38, in check_for_sufficient_version raise RuntimeError('This python installation is too old! ' RuntimeError: This python installation is too old! Use Python 3.7 or later Makefile:396: recipe for target 'binding-prepass' failed make[1]: *** [binding-prepass] Error 1 make[1]: Leaving directory '/home/mercierg/Developpement/Git/A_RELIRE/mpi-pythonization' Makefile:412: recipe for target 'rendered-31' failed make: *** [rendered-31] Error 2 I have python 3.7 and 3.8 installed but the default version is 2.7.15+ and I don't want to change that. Is there a way to modify your scripts/makefiles so that I can force it to consider python 3.8 instead (and not change my system)? Thanks. Guillaume On 12/18/19 8:47 PM, Jeff Squyres (jsquyres) via mpi-forum wrote: Chapter Committees / Chairs -- We need Chapter Committees to review their chapters in three sets of upcoming document-wide changes that are slated to be merged "soon". After you complete a review, please put an "X" in the corresponding row/column for your chapter and the specified PR in this Google spreadsheet <https://docs.google.com/spreadsheets/d/1qPAREYgeuSCMtU-EQniDilrHIYb8W0-f6Qz…> (including an un-numbered chapter for partitioned communication). This will let us track what has been done / what still needs to be done. *_FIRST SET _* Bill Gropp (the MPI Standard document Editor) has two PRs with "ticket 0" changes. However, the changes are pervasive and touch a LOT of the document. We therefore need Chapter Committees to review their chapters in the following two PRs: 1a. "Ticket 0 changes for MPI-4.x" https://github.com/mpi-forum/mpi-standard/pull/151 1b. "Uniform style for Fortran code" https://github.com/mpi-forum/mpi-standard/pull/145 Deadline: Jan 7, 2020 (Yes, that's an early deadline, but we need time to merge these PRs and fix conflicts with the second set) *_SECOND SET _* The Pythonization group has Pythonized the bindings in the entire document. We've completed a first correctness pass over the work, but we need more eyes to compare the end result of our work to the (non-Pythonized) head of the mpi-4.x branch. To be clear: this review does not include Embiggening. It is more-or-less the "MPI-3.1" style of function bindings. See this wiki page for instructions <https://github.com/mpiwg-large-count/large-count-issues/wiki/pythonizing-in…>. For additional information, also see the Pythonization slides presented at the Forum last week <https://docs.google.com/presentation/d/1QZyh6TbjDMu7mEcNqBFfe9fFOltaCtxgZ2Z…>. If you have any questions or problems, let us know in the Embiggening WG. If you just want to compare the rendered PDF: * Here's a PDF from the head of the mpi-4.x branch <https://aws.open-mpi.org/~jsquyres/forum-unofficial/mpi-report-mpi4xhead-d8…> (i.e., old/original LaTeX) * Here's a PDF from the head of the Pythonization branch <https://aws.open-mpi.org/~jsquyres/forum-unofficial/mpi-report-d8ad059-pyth…> /_with no Embiggening_/ (i.e,. new/Python-rendered LaTeX) Deadline: 21 Jan, 2020 This gives us time to finalize everything before the T-2 week deadline for the Portland Forum meeting. *_NOTE:_* At the ABQ Forum meeting, I asked you to commit/PR your approvals.json file that resulted from running the tool. This is no longer necessary -- please just mark the google spreadsheet as described above. *_THIRD SET_* After Pythonization comes Embiggening. We need Chapter Committees to review their chapters to ensure that API parameters were embiggened properly. You can do this by finding all "POLY" kinds in the Pythonized LaTeX bindings, and you can see 2xC bindings and 2xF08 bindings in the rendered PDF in your chapter. If you have any questions or problems, let us know in the Embiggening WG. Also check that the existing MPI-3.1 "_x" functions -- and their corresponding non-"_x" versions -- are all rendered correctly. If you just want to compare the rendered PDF: * Here's a PDF from the head of the mpi-4.x branch <https://aws.open-mpi.org/~jsquyres/forum-unofficial/mpi-report-mpi4xhead-d8…> (i.e., old/original LaTeX) * Here's a PDF from the head of the Pythonization branch <https://aws.open-mpi.org/~jsquyres/forum-unofficial/mpi-report-d8ad059-pyth…> /_with Embiggening enabled_/ (i.e,. new/Python-rendered LaTeX) Deadline: 21 Jan, 2020 You can probably review the second and third sets in a single pass through the text. -- Jeff Squyres jsquyres(a)cisco.com <mailto:[email protected]> _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org https://lists.mpi-forum.org/mailman/listinfo/mpi-forum _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum -- Jeff Squyres jsquyres(a)cisco.com<mailto:[email protected]> -- Jeff Squyres jsquyres(a)cisco.com<mailto:[email protected]>

1 0

Re: [Mpi-forum] Chapter Committees ACTION NEEDED
by Jeff Squyres (jsquyres) 24 Dec '19

24 Dec '19

The key is in the output: raise RuntimeError('This python installation is too old! ' RuntimeError: This python installation is too old! Use Python 3.7 or later You need at least Python 3.7. On Dec 22, 2019, at 4:11 PM, Guillaume Mercier via mpi-forum <mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: Hello Jeff, I followed your instructions, but I'm stuck with the make cleandoc command in your Git repo: make rendered-backend BINDING_RENDER_VERSION=3.1 make[1]: Entering directory '/home/mercierg/Developpement/Git/A_RELIRE/mpi-pythonization' Traceback (most recent call last): File "binding-tool/binding_prepass.py", line 109, in <module> main() File "binding-tool/binding_prepass.py", line 96, in main common.check_for_sufficient_version() File "/home/mercierg/Developpement/Git/A_RELIRE/mpi-pythonization/binding-tool/common.py", line 38, in check_for_sufficient_version raise RuntimeError('This python installation is too old! ' RuntimeError: This python installation is too old! Use Python 3.7 or later Makefile:396: recipe for target 'binding-prepass' failed make[1]: *** [binding-prepass] Error 1 make[1]: Leaving directory '/home/mercierg/Developpement/Git/A_RELIRE/mpi-pythonization' Makefile:412: recipe for target 'rendered-31' failed make: *** [rendered-31] Error 2 I have python 3.7 and 3.8 installed but the default version is 2.7.15+ and I don't want to change that. Is there a way to modify your scripts/makefiles so that I can force it to consider python 3.8 instead (and not change my system)? Thanks. Guillaume On 12/18/19 8:47 PM, Jeff Squyres (jsquyres) via mpi-forum wrote: Chapter Committees / Chairs -- We need Chapter Committees to review their chapters in three sets of upcoming document-wide changes that are slated to be merged "soon". After you complete a review, please put an "X" in the corresponding row/column for your chapter and the specified PR in this Google spreadsheet <https://docs.google.com/spreadsheets/d/1qPAREYgeuSCMtU-EQniDilrHIYb8W0-f6Qz…> (including an un-numbered chapter for partitioned communication). This will let us track what has been done / what still needs to be done. *_FIRST SET _* Bill Gropp (the MPI Standard document Editor) has two PRs with "ticket 0" changes. However, the changes are pervasive and touch a LOT of the document. We therefore need Chapter Committees to review their chapters in the following two PRs: 1a. "Ticket 0 changes for MPI-4.x" https://github.com/mpi-forum/mpi-standard/pull/151 1b. "Uniform style for Fortran code" https://github.com/mpi-forum/mpi-standard/pull/145 Deadline: Jan 7, 2020 (Yes, that's an early deadline, but we need time to merge these PRs and fix conflicts with the second set) *_SECOND SET _* The Pythonization group has Pythonized the bindings in the entire document. We've completed a first correctness pass over the work, but we need more eyes to compare the end result of our work to the (non-Pythonized) head of the mpi-4.x branch. To be clear: this review does not include Embiggening. It is more-or-less the "MPI-3.1" style of function bindings. See this wiki page for instructions <https://github.com/mpiwg-large-count/large-count-issues/wiki/pythonizing-in…>. For additional information, also see the Pythonization slides presented at the Forum last week <https://docs.google.com/presentation/d/1QZyh6TbjDMu7mEcNqBFfe9fFOltaCtxgZ2Z…>. If you have any questions or problems, let us know in the Embiggening WG. If you just want to compare the rendered PDF: * Here's a PDF from the head of the mpi-4.x branch <https://aws.open-mpi.org/~jsquyres/forum-unofficial/mpi-report-mpi4xhead-d8…> (i.e., old/original LaTeX) * Here's a PDF from the head of the Pythonization branch <https://aws.open-mpi.org/~jsquyres/forum-unofficial/mpi-report-d8ad059-pyth…> /_with no Embiggening_/ (i.e,. new/Python-rendered LaTeX) Deadline: 21 Jan, 2020 This gives us time to finalize everything before the T-2 week deadline for the Portland Forum meeting. *_NOTE:_* At the ABQ Forum meeting, I asked you to commit/PR your approvals.json file that resulted from running the tool. This is no longer necessary -- please just mark the google spreadsheet as described above. *_THIRD SET_* After Pythonization comes Embiggening. We need Chapter Committees to review their chapters to ensure that API parameters were embiggened properly. You can do this by finding all "POLY" kinds in the Pythonized LaTeX bindings, and you can see 2xC bindings and 2xF08 bindings in the rendered PDF in your chapter. If you have any questions or problems, let us know in the Embiggening WG. Also check that the existing MPI-3.1 "_x" functions -- and their corresponding non-"_x" versions -- are all rendered correctly. If you just want to compare the rendered PDF: * Here's a PDF from the head of the mpi-4.x branch <https://aws.open-mpi.org/~jsquyres/forum-unofficial/mpi-report-mpi4xhead-d8…> (i.e., old/original LaTeX) * Here's a PDF from the head of the Pythonization branch <https://aws.open-mpi.org/~jsquyres/forum-unofficial/mpi-report-d8ad059-pyth…> /_with Embiggening enabled_/ (i.e,. new/Python-rendered LaTeX) Deadline: 21 Jan, 2020 You can probably review the second and third sets in a single pass through the text. -- Jeff Squyres jsquyres(a)cisco.com <mailto:[email protected]> _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org https://lists.mpi-forum.org/mailman/listinfo/mpi-forum _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum -- Jeff Squyres jsquyres(a)cisco.com<mailto:[email protected]>

1 0

Re: [Mpi-forum] Chapter Committees ACTION NEEDED
by Guillaume Mercier 22 Dec '19

22 Dec '19

Hello Jeff, I followed your instructions, but I'm stuck with the make cleandoc command in your Git repo: make rendered-backend BINDING_RENDER_VERSION=3.1 make[1]: Entering directory '/home/mercierg/Developpement/Git/A_RELIRE/mpi-pythonization' Traceback (most recent call last): File "binding-tool/binding_prepass.py", line 109, in <module> main() File "binding-tool/binding_prepass.py", line 96, in main common.check_for_sufficient_version() File "/home/mercierg/Developpement/Git/A_RELIRE/mpi-pythonization/binding-tool/common.py", line 38, in check_for_sufficient_version raise RuntimeError('This python installation is too old! ' RuntimeError: This python installation is too old! Use Python 3.7 or later Makefile:396: recipe for target 'binding-prepass' failed make[1]: *** [binding-prepass] Error 1 make[1]: Leaving directory '/home/mercierg/Developpement/Git/A_RELIRE/mpi-pythonization' Makefile:412: recipe for target 'rendered-31' failed make: *** [rendered-31] Error 2 I have python 3.7 and 3.8 installed but the default version is 2.7.15+ and I don't want to change that. Is there a way to modify your scripts/makefiles so that I can force it to consider python 3.8 instead (and not change my system)? Thanks. Guillaume On 12/18/19 8:47 PM, Jeff Squyres (jsquyres) via mpi-forum wrote: > Chapter Committees / Chairs -- > > We need Chapter Committees to review their chapters in three sets of > upcoming document-wideï¿½changes that are slated to be merged "soon". > > After you complete a review, please put an "X" in the corresponding > row/column for yourï¿½chapter and the specified PR in this Google > spreadsheet > <https://docs.google.com/spreadsheets/d/1qPAREYgeuSCMtU-EQniDilrHIYb8W0-f6Qz…>ï¿½(including > an un-numbered chapter for partitioned communication). ï¿½This will let us > track what has beenï¿½done / what still needs to be done. > > *_FIRST SET > _* > Bill Gropp (the MPI Standard document Editor) has two PRs with "ticket > 0" changes. ï¿½However,ï¿½the changes are pervasive and touch a LOT of the > document. ï¿½We therefore need Chapterï¿½Committees to review their chapters > in the following two PRs: > > 1a. "Ticket 0 changes for MPI-4.x" > https://github.com/mpi-forum/mpi-standard/pull/151 > 1b. "Uniform style for Fortran code" > https://github.com/mpi-forum/mpi-standard/pull/145 > > Deadline: Jan 7, 2020 > ï¿½ ï¿½ (Yes, that's an early deadline, but we need time to merge these PRs > and fix conflicts with the second set) > > *_SECOND SET > _* > The Pythonization group has Pythonized the bindings in the entire > document. ï¿½We've completed aï¿½first correctness pass over the work, but > we need more eyes to compare the end result of ourï¿½work to the > (non-Pythonized) head of the mpi-4.x branch. > > To be clear: this review does not include Embiggening. ï¿½It is > more-or-less the "MPI-3.1" style of function bindings. > > See this wiki page for instructions > <https://github.com/mpiwg-large-count/large-count-issues/wiki/pythonizing-in…>. > > For additional information, also see the Pythonization slides presented > at the Forum last week > <https://docs.google.com/presentation/d/1QZyh6TbjDMu7mEcNqBFfe9fFOltaCtxgZ2Z…>. > ï¿½If you have any questions or problems, let us know in the Embiggening WG. > > If you just want to compare the rendered PDF: > > * Here's a PDF from the head of the mpi-4.x branch > <https://aws.open-mpi.org/~jsquyres/forum-unofficial/mpi-report-mpi4xhead-d8…>ï¿½(i.e., > old/original LaTeX) > * Here's a PDF from the head of the Pythonization branch > <https://aws.open-mpi.org/~jsquyres/forum-unofficial/mpi-report-d8ad059-pyth…> > /_with no Embiggening_/ (i.e,. new/Python-rendered LaTeX) > > > Deadline: 21 Jan, 2020 > ï¿½ ï¿½ Thisï¿½gives us time to finalizeï¿½everything before the T-2 week > deadline for the Portland Forum meeting. > > *_NOTE:_* At the ABQ Forum meeting, I asked you to commit/PR your > approvals.json file thatï¿½resulted from running the tool. ï¿½This is no > longer necessary -- please just mark the googleï¿½spreadsheet as described > above. > > *_THIRD SET_* > > After Pythonization comes Embiggening. ï¿½We need Chapter Committees to > review their chapters to ensure that API parameters were embiggened > properly. > > You can do this by finding all "POLY" kinds in the Pythonized LaTeX > bindings, and you can see 2xC bindings and 2xF08 bindings in the > rendered PDF in your chapter. If you have any questions or problems, let > us know in the Embiggening WG. > > Also check that the existing MPI-3.1 "_x" functions -- and their > corresponding non-"_x" versions -- are all rendered correctly. > > If you just want to compare the rendered PDF: > > * Here's a PDF from the head of the mpi-4.x branch > <https://aws.open-mpi.org/~jsquyres/forum-unofficial/mpi-report-mpi4xhead-d8…>ï¿½(i.e., > old/original LaTeX) > * Here's a PDF from the head of the Pythonization branch > <https://aws.open-mpi.org/~jsquyres/forum-unofficial/mpi-report-d8ad059-pyth…> > /_with Embiggening enabled_/ (i.e,. new/Python-rendered LaTeX) > > > Deadline: 21 Jan, 2020 > ï¿½ ï¿½ You can probably review the second and third sets in a single pass > through the text. > > -- > Jeff Squyres > jsquyres(a)cisco.com <mailto:[email protected]> > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum >

1 0

Chapter Committees ACTION NEEDED
by Jeff Squyres (jsquyres) 18 Dec '19

18 Dec '19

Chapter Committees / Chairs -- We need Chapter Committees to review their chapters in three sets of upcoming document-wide changes that are slated to be merged "soon". After you complete a review, please put an "X" in the corresponding row/column for your chapter and the specified PR in this Google spreadsheet<https://docs.google.com/spreadsheets/d/1qPAREYgeuSCMtU-EQniDilrHIYb8W0-f6Qz…> (including an un-numbered chapter for partitioned communication). This will let us track what has been done / what still needs to be done. FIRST SET Bill Gropp (the MPI Standard document Editor) has two PRs with "ticket 0" changes. However, the changes are pervasive and touch a LOT of the document. We therefore need Chapter Committees to review their chapters in the following two PRs: 1a. "Ticket 0 changes for MPI-4.x" https://github.com/mpi-forum/mpi-standard/pull/151 1b. "Uniform style for Fortran code" https://github.com/mpi-forum/mpi-standard/pull/145 Deadline: Jan 7, 2020 (Yes, that's an early deadline, but we need time to merge these PRs and fix conflicts with the second set) SECOND SET The Pythonization group has Pythonized the bindings in the entire document. We've completed a first correctness pass over the work, but we need more eyes to compare the end result of our work to the (non-Pythonized) head of the mpi-4.x branch. To be clear: this review does not include Embiggening. It is more-or-less the "MPI-3.1" style of function bindings. See this wiki page for instructions<https://github.com/mpiwg-large-count/large-count-issues/wiki/pythonizing-in…>. For additional information, also see the Pythonization slides presented at the Forum last week<https://docs.google.com/presentation/d/1QZyh6TbjDMu7mEcNqBFfe9fFOltaCtxgZ2Z…>. If you have any questions or problems, let us know in the Embiggening WG. If you just want to compare the rendered PDF: * Here's a PDF from the head of the mpi-4.x branch<https://aws.open-mpi.org/~jsquyres/forum-unofficial/mpi-report-mpi4xhead-d8…> (i.e., old/original LaTeX) * Here's a PDF from the head of the Pythonization branch<https://aws.open-mpi.org/~jsquyres/forum-unofficial/mpi-report-d8ad059-pyth…> with no Embiggening (i.e,. new/Python-rendered LaTeX) Deadline: 21 Jan, 2020 This gives us time to finalize everything before the T-2 week deadline for the Portland Forum meeting. NOTE: At the ABQ Forum meeting, I asked you to commit/PR your approvals.json file that resulted from running the tool. This is no longer necessary -- please just mark the google spreadsheet as described above. THIRD SET After Pythonization comes Embiggening. We need Chapter Committees to review their chapters to ensure that API parameters were embiggened properly. You can do this by finding all "POLY" kinds in the Pythonized LaTeX bindings, and you can see 2xC bindings and 2xF08 bindings in the rendered PDF in your chapter. If you have any questions or problems, let us know in the Embiggening WG. Also check that the existing MPI-3.1 "_x" functions -- and their corresponding non-"_x" versions -- are all rendered correctly. If you just want to compare the rendered PDF: * Here's a PDF from the head of the mpi-4.x branch<https://aws.open-mpi.org/~jsquyres/forum-unofficial/mpi-report-mpi4xhead-d8…> (i.e., old/original LaTeX) * Here's a PDF from the head of the Pythonization branch<https://aws.open-mpi.org/~jsquyres/forum-unofficial/mpi-report-d8ad059-pyth…> with Embiggening enabled (i.e,. new/Python-rendered LaTeX) Deadline: 21 Jan, 2020 You can probably review the second and third sets in a single pass through the text. -- Jeff Squyres jsquyres(a)cisco.com<mailto:[email protected]>

1 0

Call for short talks at the Q1 2020 PMIx Standard Quarterly Administrative Steering Committee (ASC) Meeting
by Mohror, Kathryn 17 Dec '19

17 Dec '19

Hi all, The PMIx Administrative Steering Committee (ASC) is soliciting short talks from researchers and practitioners whose work is related to the PMIx standard interface for inclusion in the first-quarter PMIx ASC meeting (meeting information below). We encourage presentations demonstrating novel application or optimization of the PMIx interface, as well as presentations that introduce new use cases or other issues for broad discussion. Selected speakers will share their work and ideas with the PMIx community which could result in shaping the future direction of the PMIx standard or related efforts. The objective of the PMIx standard is to provide an implementation-independent specification to facilitate interaction between applications, tools, and middleware and system runtime environments. The interface focuses on supporting application launch and wire-up; supporting tools that wish to inspect, steer, and/or debug parallel applications; providing interfaces to manage dynamic workload applications, to support fault tolerance and cross-library coordination; and facilitate communication across container boundaries. We encourage anyone interested in sharing ideas or research related to these topics at our upcoming meeting to email Josh Hursey (jhursey(a)us.ibm.com) and Kathryn Mohror (kathryn(a)llnl.gov<mailto:[email protected]>). Include a title, presenter information, and a short abstract in your email. Meeting information: * Date: January 23, 2020 * Time: 11 am - 5 pm US Central Time * Location: Virtual (online) Meeting (see agenda link for details) * Meeting Link: <https://github.com/pmix/pmix-standard/wiki/ASC-Q4-2019-Meeting> https://github.com/pmix/pmix-standard/wiki/ASC-Q1-2020-Meeting For more information about the PMIx standardization body and its activities please join the mailing list [1], check out the activity on the GitHub repository [2], and/or review the website [3]. [1] PMIx Forum Mailing list: https://groups.google.com/forum/#!forum/pmix-forum [2] PMIx Standard GitHub: https://github.com/pmix/pmix-standard [3] PMIx website: https://pmix.org Kathryn Mohror and Josh Hursey PMIx ASC Co-Chairs _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov<mailto:[email protected]>, https://people.llnl.gov/kathryn Data Analysis Group<https://computation.llnl.gov/casc/data-analysis-group> @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

Call for Participation: Q1 2020 PMIx Standard Quarterly Administrative Steering Committee (ASC) Meeting
by Mohror, Kathryn 17 Dec '19

17 Dec '19

Hello everyone, The PMIx community is pleased to announce the first-quarter meeting of the Administrative Steering Committee (ASC) of the PMIx standardization body for 2020. The objective of the PMIx standard is to provide an implementation-independent specification to facilitate interaction between applications, tools, and middleware and system runtime environments. The interface focuses on supporting application launch and wire-up; supporting tools that wish to inspect, steer, and/or debug parallel applications; providing interfaces to manage dynamic workload applications, to support fault tolerance and cross-library coordination; and facilitate communication across container boundaries. The PMIx standard is governed by the ASC comprised of representatives from a wide range of research, academic, and industrial organizations. The ASC plays a critical role in shaping the evolution of this critical system interface. In 2019, the PMIx standardization body adopted new governance rules to facilitate broader participation, and balance active innovation with interface stability. This quarterly meeting will be the second formal meeting of the ASC under these new governance rules. The goal of this meeting is to read, discuss, and vote on modifications to the PMIx standard, discuss potential modifications or new ideas for the standard, welcome formal participation in the governance body from new, interested groups, and learn of community progress with respect to PMIx. As such we are calling for broad participation from the parallel and distributed computing community to participate in this meeting. Meeting information: * Date: January 23, 2020 * Time: 11 am - 5 pm US Central Time * Location: Virtual (online) Meeting (see agenda link for details) * Meeting Link: <https://github.com/pmix/pmix-standard/wiki/ASC-Q4-2019-Meeting> https://github.com/pmix/pmix-standard/wiki/ASC-Q1-2020-Meeting For more information about the PMIx standardization body and its activities please join the mailing list [1], check out the activity on the GitHub repository [2], and/or review the website [3]. [1] PMIx Forum Mailing list: https://groups.google.com/forum/#!forum/pmix-forum [2] PMIx Standard GitHub: https://github.com/pmix/pmix-standard [3] PMIx website: https://pmix.org Kathryn Mohror and Josh Hursey PMIx ASC Co-Chairs _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov<mailto:[email protected]>, https://people.llnl.gov/kathryn Data Analysis Group<https://computation.llnl.gov/casc/data-analysis-group> @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

Results from the Albuquerque MPI Forum (INCLUDES ACTION ITEM)
by schulzm＠in.tum.de 14 Dec '19

14 Dec '19

Hi all, (Warning: long email with action items at the end) We had a (at least in my eyes) very successful meeting last week - thank you to all who were active in the many discussions and/or helped with preparations. In the following a quick summary: Several tickets passed the reading stage, including MPI Sessions, Partitioned Communication, and additions for hardware topologies. Those will come up for 1st votes next time in Portland, matching our timeline that we had set for MPI 4.0. Additional votes and NoNo updates for tickets are listed on the voting page for the meeting. https://www.mpi-forum.org/meetings/2019/12/votes <https://www.mpi-forum.org/meetings/2019/12/votes> We also had discussions on changes on how the bindings in the document are built (aka. Pythonization) and on many smallish clean-up changes that Bill accumulated. Both will require review by the chapter committees and we have discussed a process for this review - Jeff will send around explicit instructions for chapter committees this week - please take a close look and try to stick with the deadlines in that email - we need to get this done in time for the Portland meeting (to be precise 4 weeks BEFORE the Portland meeting). To ensure that we have active committees as well as chairs who are familiar with the process as discussed, we shuffled the chapter committees around - please take a look at this on the MPI 4 page - if you would like volunteer for an additional chapter or if you feel your name shouldn’t be there, please contact the chapter committee chair (with Wesley and myself on cc). Overall, we decided to stick with our timeline (of course, pending review in Portland), as follows: Feb 2020: Final 1st Votes June 2020: Final 2nd Votes Sep 2020: Ratification Meeting Nov 2020 (special meeting at SC): Final ratification This timeline, however, leaves two issues out, which weren’t quite ready in Albuquerque: - BigCount - we have more or less reached consensus on the text changes, but the new bindings are missing - Terms and Semantics - long discussions and still many changes pending With the above timeline and the changes compared to the last officially announced versions likely not passing a NoNo vote, these two issues would not make MPI 4.0. As some members felt that those two items need to go out quickly as well, but overarching opinion was that we made a firm commitment to the community for an MPI 4.0 at SC2020, we discussed two alternatives: A) Immediately follow up with a clean-up 4.1 version with final 1st votes in September and final 2nd votes in November, so that we can have a draft 4.1 along the new MPI 4.0 with BigCount and clean-ed up terminology (plus several clean-up tickets stemming from Bill’s full document review) as well as possible some restructuring, but no new functionality beyond BigCount. B) Add another meeting in the April and/or August timeframe to buy us one more meeting for discussions. ACTION ITEM BELOW: If there are any strong opinions one way or the other, please let me know (I would suggest to send this directly to me and not over the whole list to give everyone equal chance to speak up and I will collect all input). Also, as both tickets are controversial, I would like to encourage all active members of the forum to a) actively participate in the discussion so we can have productive discussions at the meetings and b) have internal discussions in the respective organizations to form an opinion on where they stand on the two tickets (both in general and how critical they are to the MPI 4/4.1 timeline) - also here, please feedback to me and I will collect. We will also have several virtual meetings on these topics (as well as the cleanup pass mentioned above) in the usual slot starting in the new year (we are skipping this week and - obviously - during the holidays). Please stay tuned for details and make every attempt to attend. It will be important to have good representation! I am sure we will find a good solution to these issue and overall I think we are on track to a significant and strong update to MPI in 4.0 (and possibly 4.1). Thanks to everyone for their hard work on this! 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

1 0