- mpiwg-large-counts - mailman3.cels.anl.gov

Re: [Mpiwg-large-counts] Explicit F08 bindings for MPI_Op_create and MPI_Register_datarep
by Bangalore, Purushotham 06 Aug '20

06 Aug '20

Yes, we need to add text in Section 2.6.2, as Hubert also noted. Thanks, Puri ________________________________ From: Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> Sent: Thursday, August 6, 2020 8:53 AM To: MPI BigCount Working Group <mpiwg-large-counts(a)lists.mpi-forum.org> Cc: MPI Fortran WG <mpiwg-fortran(a)lists.mpi-forum.org>; Bangalore, Purushotham <puri(a)uab.edu> Subject: Re: [Mpiwg-large-counts] Explicit F08 bindings for MPI_Op_create and MPI_Register_datarep Doesn't seem like there's a better way to do it (i.e., other than adding a suffix to differentiate the two functions). It would probably be a good idea to have additional text about these two F08 procedures, because it affects both users and implementors. On Aug 5, 2020, at 9:55 AM, Bangalore, Purushotham via mpiwg-large-counts <mpiwg-large-counts(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: Dear Members of Fortran WG: Hubert pointed out that we have to provide MPI_Op_create_l and MPI_Register_datarep_l functions in the F08 bindings since generic function overload is not possible for these two functions (the only difference in the two versions of these functions is the argument of type procedure and these two procedure arguments are not distinguishable, more details from Hubert at: https://github.com/mpi-forum/mpi-issues/issues/137#issuecomment-648725841) The question for the Fortran WG is: Is there a better solution than adding the _l functions for these two cases? If not, are you all OK with making an exception for these two cases and adding _l functions? Thanks, Puri _______________________________________________ mpiwg-large-counts mailing list mpiwg-large-counts(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-large-counts -- Jeff Squyres jsquyres(a)cisco.com<mailto:[email protected]>

1 0

Re: [Mpiwg-large-counts] Explicit F08 bindings for MPI_Op_create and MPI_Register_datarep
by Jeff Squyres (jsquyres) 06 Aug '20

06 Aug '20

Doesn't seem like there's a better way to do it (i.e., other than adding a suffix to differentiate the two functions). It would probably be a good idea to have additional text about these two F08 procedures, because it affects both users and implementors. On Aug 5, 2020, at 9:55 AM, Bangalore, Purushotham via mpiwg-large-counts <mpiwg-large-counts(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: Dear Members of Fortran WG: Hubert pointed out that we have to provide MPI_Op_create_l and MPI_Register_datarep_l functions in the F08 bindings since generic function overload is not possible for these two functions (the only difference in the two versions of these functions is the argument of type procedure and these two procedure arguments are not distinguishable, more details from Hubert at: https://github.com/mpi-forum/mpi-issues/issues/137#issuecomment-648725841) The question for the Fortran WG is: Is there a better solution than adding the _l functions for these two cases? If not, are you all OK with making an exception for these two cases and adding _l functions? Thanks, Puri _______________________________________________ mpiwg-large-counts mailing list mpiwg-large-counts(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-large-counts -- Jeff Squyres jsquyres(a)cisco.com<mailto:[email protected]>

1 0

Fwd: Explicit F08 bindings for MPI_Op_create and MPI_Register_datarep
by Rolf Rabenseifner 05 Aug '20

05 Aug '20

Puri asked me to forward this to the Fortran WG: _____________ Dear Members of Fortran WG: Hubert pointed out that we have to provide MPI_Op_create_l and MPI_Register_datarep_l functions in the F08 bindings since generic function overload is not possible for these two functions (the only difference in the two versions of these functions is the argument of type procedure and these two procedure arguments are not distinguishable, more details from Hubert at: https://github.com/mpi-forum/mpi-issues/issues/137#issuecomment-648725841) The question for the Fortran WG is: Is there a better solution than adding the _l functions for these two cases? If not, are you all OK with making an exception for these two cases and adding _l functions? Thanks, Puri ----- Forwarded Message ----- From: "Purushotham V. Bangalore" <puri(a)uab.edu> To: "Rolf Rabenseifner" <rolf.rabenseifner(a)hlrs.de> Sent: Wednesday, August 5, 2020 5:07:33 PM Subject: Fw: Explicit F08 bindings for MPI_Op_create and MPI_Register_datarep Hi Rolf, I sent this message earlier, however it looks like it got rejected. I have subscribed for the Fortran WG mailing list, so not sure what happened. In any case, could you please forward this to the Fortran WG mailing list. Thanks, Puri ________________________________ From: Bangalore, Purushotham Sent: Wednesday, August 5, 2020 8:55 AM To: mpiwg-fortran(a)lists.mpi-forum.org <mpiwg-fortran(a)lists.mpi-forum.org> Cc: mpiwg-large-counts(a)lists.mpi-forum.org <mpiwg-large-counts(a)lists.mpi-forum.org> Subject: Explicit F08 bindings for MPI_Op_create and MPI_Register_datarep Dear Members of Fortran WG: Hubert pointed out that we have to provide MPI_Op_create_l and MPI_Register_datarep_l functions in the F08 bindings since generic function overload is not possible for these two functions (the only difference in the two versions of these functions is the argument of type procedure and these two procedure arguments are not distinguishable, more details from Hubert at: https://github.com/mpi-forum/mpi-issues/issues/137#issuecomment-648725841) The question for the Fortran WG is: Is there a better solution than adding the _l functions for these two cases? If not, are you all OK with making an exception for these two cases and adding _l functions? Thanks, Puri -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de . 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 . Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) .

1 0

Re: [Mpiwg-large-counts] Explicit F08 bindings for MPI_Op_create and MPI_Register_datarep
by Jeff Hammond 05 Aug '20

05 Aug '20

I defer to Hubert but everything I've read from the experts suggests that we need to add the _c functions. Given the usage frequency of user-defined reductions, this is a minor inconvenience. Jeff On Wed, Aug 5, 2020 at 7:05 AM Bangalore, Purushotham via mpiwg-large-counts <mpiwg-large-counts(a)lists.mpi-forum.org> wrote: > Dear Members of Fortran WG: > > Hubert pointed out that we have to provide MPI_Op_create_l and > MPI_Register_datarep_l functions in the F08 bindings since generic function > overload is not possible for these two functions (the only difference in > the two versions of these functions is the argument of type procedure and > these two procedure arguments are not distinguishable, more details from > Hubert at: > https://github.com/mpi-forum/mpi-issues/issues/137#issuecomment-648725841) > > > The question for the Fortran WG is: Is there a better solution than adding > the _l functions for these two cases? If not, are you all OK with making an > exception for these two cases and adding _l functions? > > Thanks, > Puri > _______________________________________________ > mpiwg-large-counts mailing list > mpiwg-large-counts(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-large-counts > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Explicit F08 bindings for MPI_Op_create and MPI_Register_datarep
by Bangalore, Purushotham 05 Aug '20

05 Aug '20

Dear Members of Fortran WG: Hubert pointed out that we have to provide MPI_Op_create_l and MPI_Register_datarep_l functions in the F08 bindings since generic function overload is not possible for these two functions (the only difference in the two versions of these functions is the argument of type procedure and these two procedure arguments are not distinguishable, more details from Hubert at: https://github.com/mpi-forum/mpi-issues/issues/137#issuecomment-648725841) The question for the Fortran WG is: Is there a better solution than adding the _l functions for these two cases? If not, are you all OK with making an exception for these two cases and adding _l functions? Thanks, Puri

1 0

Re: [Mpiwg-large-counts] [Mpi-forum] Announcing/Reconfirming 2nd Vote on Ticket #137 - Enbiggenment (Large Counts)
by Rolf Rabenseifner 04 Aug '20

04 Aug '20

Dear all, I have trhee concerns and hopefully resolvable through an errata before second vote. All my references to https://github.com/mpi-forum/mpi-issues/files/5022345/mpi40-report-ticket13… 1. Concern: Sect. 18.2 page 779, lines 32-35 tell: The "_l" suffixed MPI procedure has MPI_Count for all count parameters, MPI_Aint for all parameters that represent byte displacement in memory, and MPI_Count for all parameters that represent byte displacement in files. MPI_File_seek with MPI_SEEK_CUR moves the file pointer by an offset in bytes in the default fileview is used. It is also in the _l version defined as MPI_Offset. In MPI_File_set_view, the "MPI_Offset disp" explicitely defines an "displacement" (Sect. 13.3 page 596 line 25). I expect that this is decided (and in my opinion a good decision), but the text in 18.2 should be corrected, for example with an additional sentence like In MPI_File_... procedures, arguments of type MPI_Offset are not changed to MPI_Count although they may contain byte displacements in files. 2. Concern: It is not described in the 18.2, that "byte displacements in files" is related to all MPI_File_... and derived datatype procedures. 3. Concern: I mentioned very early, that the displacement in the derived data type procedures may be used - for relative displacements used for memeory and files, but never in combination with MPI_BOTTOM, or - for absolute displacements in memory in combination with MPI_BOTTOM. int MPI_Type_create_hindexed(int count, const int array_of_blocklengths[], const MPI_Aint array_of_displacements[], MPI_Datatype oldtype, MPI_Datatype *newtype) can be used for relative and absolute displacements, but only with blocklength in int. (A) int MPI_Type_create_hindexed_l(MPI_Count count, const MPI_Count array_of_blocklengths[], const MPI_Count array_of_displacements[], MPI_Datatype oldtype, MPI_Datatype *newtype) can only be used for relative displacements in memory and files, but not for absolute displ in memory with MPI_BOTTOM. This means absolute displacements (i.e. with MPI_Aint) together with MPI_Count blocklength (B) is missing. For a few routines a second interface (B) would have been needed. In my opinion, it is okay to provide A and not B, but this should be clearly documented in 18.2. A simple reason is, that nearly all, what one could do with MPI_BOTTOM, one can also do with normal buffers, and there, A works. And A works also for files, but B not. Summarizing, I expect that the APIs are okay, but 18.2 is missing some short explanations of exceptions and decisions. Best regards Rolf ----- Original Message ----- > From: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > Cc: "Anthony Skjellum" <skjellum(a)gmail.com> > Sent: Tuesday, August 4, 2020 3:33:53 PM > Subject: [Mpi-forum] Announcing/Reconfirming 2nd Vote on Ticket #137 - Enbiggenment (Large Counts) > Hi, this is the two-week vote announcement for Ticket #137, which is already on > the agenda. > > Issue: [ https://github.com/mpi-forum/mpi-issues/issues/137 | > https://github.com/mpi-forum/mpi-issues/issues/137 ] > > > Pull request: [ https://github.com/mpi-forum/mpi-standard/pull/132 | > https://github.com/mpi-forum/mpi-standard/pull/132 ] > > PDF: [ > https://github.com/mpi-forum/mpi-issues/files/5022345/mpi40-report-ticket13… > | > https://github.com/mpi-forum/mpi-issues/files/5022345/mpi40-report-ticket13… > ] > One outstanding issue is being discussed, and there may be no-no vote proposed > also, tbd. > > Thanks, > Tony and Puri on behalf of the Large Counts WG. > > > -- > Anthony Skjellum, PhD > [ mailto:[email protected] | skjellum(a)gmail.com ] > Cell: +1-205-807-4968 > > > > > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de . 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 . Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) .

1 0

Re: [Mpiwg-large-counts] Regular meeting tomorrow?
by Jeff Squyres (jsquyres) 18 Dec '19

18 Dec '19

I’ll be there. Sent from my phone. No type good. On Dec 17, 2019, at 7:34 PM, Martin Ruefenacht <m.a.ruefenacht(a)gmail.com> wrote: I am available. AndI think it would be useful before releasing to the Forum. Martin On Tue, 17 Dec 2019 at 21:51, Jeff Squyres (jsquyres) via mpiwg-large-counts <mpiwg-large-counts(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: Are we having our regular Pythonization/Embiggening WG Zoom tomorrow morning (Wed, Dec 18, 9am US Eastern)? I ask because I know Dan is out for the rest of the year on vacation. -- Jeff Squyres jsquyres(a)cisco.com<mailto:[email protected]> _______________________________________________ mpiwg-large-counts mailing list mpiwg-large-counts(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-large-counts -- Martin

1 0

Re: [Mpiwg-large-counts] Regular meeting tomorrow?
by Martin Ruefenacht 17 Dec '19

17 Dec '19

I am available. AndI think it would be useful before releasing to the Forum. Martin On Tue, 17 Dec 2019 at 21:51, Jeff Squyres (jsquyres) via mpiwg-large-counts <mpiwg-large-counts(a)lists.mpi-forum.org> wrote: > Are we having our regular Pythonization/Embiggening WG Zoom tomorrow > morning (Wed, Dec 18, 9am US Eastern)? > > I ask because I know Dan is out for the rest of the year on vacation. > > -- > Jeff Squyres > jsquyres(a)cisco.com > > _______________________________________________ > mpiwg-large-counts mailing list > mpiwg-large-counts(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-large-counts > -- Martin

1 0

Re: [Mpiwg-large-counts] DRAFT: Chapter Committees ACTION NEEDED
by Jeff Squyres (jsquyres) 17 Dec '19

17 Dec '19

Dan -- Good points; many thanks. On Dec 17, 2019, at 1:31 PM, HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]>> wrote: Hi Jeff, The (potential) new “Partitioned Communication” chapter should be included in the Google spreadsheet, without a chapter number, between chapters 7 and 8 (its most likely insertion position). FYI - Ryan is Chair of that (speculative) Chapter Committee. First set wording - fine. Second set wording - there are two purposes for this part of the review 1) does compiling the non-Embiggened(tm) version of the Pythonised source render the document sufficiently similarly to the document rendered by compiling the pre-Embiggening(tm) version of the pure-Latex source? 2) does compiling the post-Embiggening(tm) version of the Pythonised source render the document in a manner consistent with the application of the rules/expectations, i.e. in accordance with the text changes read (rejected via no-no-vote veto) at the ABQ meeting? Both of the purposes motivating the review of the second set are important and should be completed before the T-2 deadline for the next face-to-face meeting (at the latest). This permits a full reading of all components for The Embiggening(tm), including all the new bindings, to happen at the Portland meeting with the blessing (hopefully) of all of the chapter committees (except George's, I guess). This resets the MPI voting procedure clock, but it can happen concurrently with bringing forward additional no-no votes (one for the text changes, another for the bindings) and a 1st vote for the hopefully-amended-by-no-no-votes BigCount ticket. When one or both of the no-no votes fail(s), we can pull the 1st vote and rely on the reading instead. The Jun meeting will see either a 2nd vote (unlikely) or a 1st vote (more likely). The Jun meeting is also the point at which MartinS announces a release candidate that targets MPI-4.0 at SC20 (or doesn’t delaying it, e.g. until ISC21). Style - sufficiently lurid, except I suggest that the red deadline text should be embiggened. 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 17 Dec 2019, at 15:08, Jeff Squyres (jsquyres) via mpiwg-large-counts <mpiwg-large-counts(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: This is a DRAFT of what I'd like to send to the Forum to get all Chapter Committees to review the document-wide stuff that we need reviewed. Please send comments / suggestions to me. Thanks! (Last week, I accidentally sent this to the wrong WG -- I am [finally] re-sending it to the large count WG for proofing before I sent this out to the entire Forum mailing list / chapter chairs) ----------------------------------------- We need Chapter Committees to review their chapters in 2 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…>. 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/145 1b. "Uniform style for Fortran code" https://github.com/mpi-forum/mpi-standard/pull/151 Deadline: Jan 7, 2020 (Yes, that's an early deadline, but we need time to merge this 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 (at least) the MPI-3.1 document -- or, better yet, to the head of the mpi-4.x branch. See this wiki page for instructions: https://github.com/mpiwg-large-count/large-count-issues/wiki/pythonizing-in… Also please see the Pythonization slides presented at the Forum last week<https://docs.google.com/presentation/d/1QZyh6TbjDMu7mEcNqBFfe9fFOltaCtxgZ2Z…>. 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. -- Jeff Squyres jsquyres(a)cisco.com<mailto:[email protected]> _______________________________________________ mpiwg-large-counts mailing list mpiwg-large-counts(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-large-counts -- Jeff Squyres jsquyres(a)cisco.com<mailto:[email protected]>

1 0

Regular meeting tomorrow?
by Jeff Squyres (jsquyres) 17 Dec '19

17 Dec '19

Are we having our regular Pythonization/Embiggening WG Zoom tomorrow morning (Wed, Dec 18, 9am US Eastern)? I ask because I know Dan is out for the rest of the year on vacation. -- Jeff Squyres jsquyres(a)cisco.com

1 0