April 2011 - mpi-forum - mailman3.cels.anl.gov

Re: [Mpi-forum] MPI attribute callback behavior
by Jeff Squyres 25 Apr '11

25 Apr '11

Here's a followup question: is it valid to call MPI_COMM_FREE on objects A or B when in a keyval copy callback with original object A and new object B? I can't decide whether the answer should be "yes" or "no"... On Apr 14, 2011, at 10:36 AM, Jeff Squyres wrote: > An issue recently came up within Open MPI as to what exactly you are allowed to do within an attribute callback (e.g., when a communicator is copied or deleted). > > From a standards point of view (i.e., regardless of implementation), here's a list that we came up with: > > 1. While in a keyval copy callback with original object A and new object B: > - Call MPI_Comm_get_attr on A: ok > - Call MPI_Comm_get_attr on B: erroneous > (B is still being created, and therefore the get is non-deterministic) > - Call MPI_Comm_set_attr on A: erroneous > (seems like a bad idea to modify what you're in the middle of copying) > - Call MPI_Comm_set_attr on B: erroneous (non-deterministive) if keyval exists on A, otherwise ok > - Call MPI_Comm_delete_attr on A: erroneous > (seems like a bad idea to modify what you're in the middle of copying) > - Call MPI_Comm_delete_attr on B: erroneous (non-deterministic) > (same as get_attr on B, above) > - Call MPI_Comm_create_keyval: ok > - Call MPI_Comm_free_keyval: ok > > 2. While in a keyval delete callback on object A: > - Call MPI_Comm_get_attr on A: erroneous > (A is being deleted; that attribute may have already been deleted) > - Call MPI_Comm_set_attr on A: erroneous > (why allow setting on an object that is being deleted?) > - Call MPI_Comm_delete_attr on A: erroneous > (it's going to be deleted anyway) > - Call MPI_Comm_create_keyval: ok > - Call MPI_Comm_delete_keyval: ok > > Does anyone disagree with this list? > > Should we put some kind of list like this in MPI-3? (I can work up a ticket if we think supporting text like this should be there) > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Ticket 265 - Re: Changelog question
by Rolf Rabenseifner 25 Apr '11

25 Apr '11

Jeff and Fab, I would say that the content is fine, but it would also be as same as good when you combine and shorten some entries, to reduce the total number to 2 entries, and I would add a simple sentence about compatibility in the last one: 2. Sections 2.5.8, 3.2.2, 3.3 on pages 16, 29, 31, Sections 4.1.5, 4.1.7, 4.1.8, 4.1.11, 5.9.2 on pages 97, 99, 101, 105, 172, Section 12.3 on page 412, and Appendix A.1.1 on page 545. New inquiry functions, MPI_TYPE_SIZE_X, MPI_TYPE_GET_EXTENT_X, MPI_TYPE_GET_TRUE_EXTENT_X, and MPI_GET_ELEMENTS_X, return their results as an MPI_Count value, which is a new type large enough to represent element counts in memory, file views, etc. A new function, MPI_STATUS_SET_ELEMENTS_X, modifies the opaque part of MPI_STATUS so that a call to MPI_GET_ELEMENTS_X returns the provided MPI_Count value. 3. Sections 3.2.5, 4.1.5, 4.1.11, 4.2 on pages 34, 97, 105, and 127. The functions MPI_GET_COUNT, MPI_TYPE_SIZE, MPI_GET_ELEMENTS, and MPI_PACK_SIZE are now defined to set the count, resp. size parameter to MPI_UNDEFINED when that parameter would overflows. In all other MPI-2.2 routines, the type and semantics of the count arguments are kept unchanged, i.e., int or INTEGER. ----- With this all locations are mentioned, all new functionality is mentioned, and that's what is needed for both users and implementors. Details can be taken from the cited sections. I'm sorry for the late answer - first I've overseen the mail (therefore I now added "Ticket 265" in the Subject) - and second, I'm still on Easter break. Best regards Rolf ----- Original Message ----- > From: "Jeff Squyres" <jsquyres(a)cisco.com> > To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > Sent: Friday, April 22, 2011 5:11:26 PM > Subject: Re: [Mpi-forum] Changelog question > Rolf -- How's this? (see attached; the rendered text didn't > copy-n-paste well into a plain-text email) > > I honestly don't have too much of an opinion here -- Fab and I put > together what we think Rolf wanted, but it *does* seem like a little > overkill. > > The only think I have a slight reservation about is that this sets a > high bar for all other MPI-3 proposals -- e.g., will the one-sided > chapter need to have changelog entries for every new function (because > they're interleaved; it's not like NBC or MPI_T that just added whole > new sections). > > Or should we have a single new changelog entry, perhaps with a table > or list of all the new functions? > > (I see that Rolf made 13 new changelog entries for the Fortran 08 > stuff -- > https://svn.mpi-forum.org/trac/mpi-forum-web/raw-attachment/ticket/229/mpi-…) > > > > > On Apr 21, 2011, at 7:15 AM, Rolf Rabenseifner wrote: > > > Yes, of course, but I thought that the MPI_Count > > ticket has only about 6 new routines, similar to the > > two entries 17 and 18 on MPI-2.2 pages 594 and 595 > > about the MPI_DIST_GRAPH_... routines. > > > > If a whole new main chapter is added, then > > typically only one ticket is added, > > without mentioning 20 routines. > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/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: Allmandring 30)

1 0

New MPI one-sided chapter available (reading next meeting)
by William Gropp 24 Apr '11

24 Apr '11

The RMA working group is pleased to announce the release of its draft for first reading. It may be found at https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/mpi3-rma-propo… (the same place as usual). Feedback from the Forum has been incorporated into this draft; it was much appreciated. The MPI RMA Working Group William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

Re: [Mpi-forum] Changelog question
by Jeff Squyres 22 Apr '11

22 Apr '11

Rolf -- How's this? (see attached; the rendered text didn't copy-n-paste well into a plain-text email) I honestly don't have too much of an opinion here -- Fab and I put together what we think Rolf wanted, but it *does* seem like a little overkill. The only think I have a slight reservation about is that this sets a high bar for all other MPI-3 proposals -- e.g., will the one-sided chapter need to have changelog entries for every new function (because they're interleaved; it's not like NBC or MPI_T that just added whole new sections). Or should we have a single new changelog entry, perhaps with a table or list of all the new functions? (I see that Rolf made 13 new changelog entries for the Fortran 08 stuff -- https://svn.mpi-forum.org/trac/mpi-forum-web/raw-attachment/ticket/229/mpi-…) On Apr 21, 2011, at 7:15 AM, Rolf Rabenseifner wrote: > Yes, of course, but I thought that the MPI_Count > ticket has only about 6 new routines, similar to the > two entries 17 and 18 on MPI-2.2 pages 594 and 595 > about the MPI_DIST_GRAPH_... routines. > > If a whole new main chapter is added, then > typically only one ticket is added, > without mentioning 20 routines. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

First reading Fortran-Tickets 229-252
by Rolf Rabenseifner 21 Apr '11

21 Apr '11

Here are the pdfs for the first reading of all Fortran tickets at May meeting in San Jose! Sorry, only the pdf is updated. The solutions in the tickets are still from March. The discussion in the tickets were input for rationales in the pdf. See attachments at https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/229 - mpi-report-F2008-2011-04-21-changeonlyplustickets.pdf (4.2 MB) Version for reading at MPI Forum meeting May 2011 - deleted text is removed - mpi-report-F2008-2011-04-21-changeonlyplustickets-majorpages.pdf (0.6 MB) - Version for reading at MPI Forum meeting May 2011 - deleted text is removed - major pages for printing - mpi-report-F2008-2011-04-21-reviewdoc.pdf (4.2 MB) - Version for reading at MPI Forum meeting May 2011 - all deleted text still visible I recommend to print the "majorpages" in colors. The other two are for acroread - browsing for "ticket2" Best regards Rolf -- 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: Allmandring 30)

1 0

Re: [Mpi-forum] Changelog question
by Rolf Rabenseifner 21 Apr '11

21 Apr '11

Yes, of course, but I thought that the MPI_Count ticket has only about 6 new routines, similar to the two entries 17 and 18 on MPI-2.2 pages 594 and 595 about the MPI_DIST_GRAPH_... routines. If a whole new main chapter is added, then typically only one ticket is added, without mentioning 20 routines. Rolf ----- Original Message ----- > From: "Bronis R. de Supinski" <bronis(a)llnl.gov> > To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > Sent: Thursday, April 21, 2011 11:59:54 AM > Subject: Re: [Mpi-forum] Changelog question > Rolf: > > Re: > > Normally, the routine names of the new routines should be mentioned. > > I do not agree that this rule is appropriate. If broad > concepts are added then you mention the concept, not every > routine that was added for it. As a primary example, if > we adopt the MPIT proposal then we only need to refer to > the concept. We do not need to list each routine of which > the new concept consists (it is obvious when one reviews > the new standard that any MPI_T_ routine was added). > > In this specific instance, Jeff's proposed text is certainly > specific enough. I agree with Jeff that we might want to be > less specific; we certainly do not need to add the name of > every new routine that accepts MPI_Count. > > Bronis > > > > They automatically go also into the Index. > > Taking the last position in the index, normally one can see > > with which MPI version, this routine was introduced, > > if it is newer than MPI-2.0. > > > > In your case, I would also say a word, > > - that several inquiry functions are modified to return > > MPI_UNDEFINED in the case of too large numbers > > (again the names should be fully listed), > > - and that other the existing routines are > > not modified as long they are internally able to handle > > large messages. > > > > Please have a look at the existing change-log items. > > > > Rolf > > > > ----- Original Message ----- > >> From: "Jeff Squyres" <jsquyres(a)cisco.com> > >> To: "MPI Forum list" > >> Sent: Wednesday, April 20, 2011 11:07:30 PM > >> Subject: [Mpi-forum] Changelog question > >> Rolf -- > >> > >> Per your comments, we made up a changelog entry for the MPI_Count > >> ticket. MPI_Count isn't *too* large, but it does touch a lot of > >> individual places. > >> > >> Here's how our changelog entry rendered in PDF; is this generally > >> what > >> you had in mind? > >> > >> ----- > >> Section 2.5.8 on page 16, Section 3.2.2 on page 29, Section 3.3 on > >> page 31, Section 4.1.5 on page 97, Section 4.1.7 on page 99, > >> Section > >> 4.1.8 on page 101, Section 4.1.11 on page 105, Section 5.9.2 on > >> page > >> 172, Section 12.3 on page 412, Section A.1.1 on page 545, > >> > >> Introduce MPI_Count, a type large enough to represent element > >> counts > >> in memory, file views, etc., and associated functions. > >> ----- > >> > >> Or should we be more brief and not list every individual > >> section/page > >> that we touched? I could see this getting problematic for some > >> other > >> tickets (e.g., Fortran). > >> > >> -- > >> Jeff Squyres > >> jsquyres(a)cisco.com > >> For corporate legal information go to: > >> http://www.cisco.com/web/about/doing_business/legal/cri/ > >> > >> > >> _______________________________________________ > >> mpi-forum mailing list > >> mpi-forum(a)lists.mpi-forum.org > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/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: Allmandring 30) > > _______________________________________________ > > mpi-forum mailing list > > mpi-forum(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/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: Allmandring 30)

1 0

Re: [Mpi-forum] Changelog question
by Bronis R. de Supinski 21 Apr '11

21 Apr '11

Rolf: Re: > Normally, the routine names of the new routines should be mentioned. I do not agree that this rule is appropriate. If broad concepts are added then you mention the concept, not every routine that was added for it. As a primary example, if we adopt the MPIT proposal then we only need to refer to the concept. We do not need to list each routine of which the new concept consists (it is obvious when one reviews the new standard that any MPI_T_ routine was added). In this specific instance, Jeff's proposed text is certainly specific enough. I agree with Jeff that we might want to be less specific; we certainly do not need to add the name of every new routine that accepts MPI_Count. Bronis > They automatically go also into the Index. > Taking the last position in the index, normally one can see > with which MPI version, this routine was introduced, > if it is newer than MPI-2.0. > > In your case, I would also say a word, > - that several inquiry functions are modified to return > MPI_UNDEFINED in the case of too large numbers > (again the names should be fully listed), > - and that other the existing routines are > not modified as long they are internally able to handle > large messages. > > Please have a look at the existing change-log items. > > Rolf > > ----- Original Message ----- >> From: "Jeff Squyres" <jsquyres(a)cisco.com> >> To: "MPI Forum list" >> Sent: Wednesday, April 20, 2011 11:07:30 PM >> Subject: [Mpi-forum] Changelog question >> Rolf -- >> >> Per your comments, we made up a changelog entry for the MPI_Count >> ticket. MPI_Count isn't *too* large, but it does touch a lot of >> individual places. >> >> Here's how our changelog entry rendered in PDF; is this generally what >> you had in mind? >> >> ----- >> Section 2.5.8 on page 16, Section 3.2.2 on page 29, Section 3.3 on >> page 31, Section 4.1.5 on page 97, Section 4.1.7 on page 99, Section >> 4.1.8 on page 101, Section 4.1.11 on page 105, Section 5.9.2 on page >> 172, Section 12.3 on page 412, Section A.1.1 on page 545, >> >> Introduce MPI_Count, a type large enough to represent element counts >> in memory, file views, etc., and associated functions. >> ----- >> >> Or should we be more brief and not list every individual section/page >> that we touched? I could see this getting problematic for some other >> tickets (e.g., Fortran). >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/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: Allmandring 30) > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >

1 0

Re: [Mpi-forum] Changelog question
by Rolf Rabenseifner 21 Apr '11

21 Apr '11

Normally, the routine names of the new routines should be mentioned. They automatically go also into the Index. Taking the last position in the index, normally one can see with which MPI version, this routine was introduced, if it is newer than MPI-2.0. In your case, I would also say a word, - that several inquiry functions are modified to return MPI_UNDEFINED in the case of too large numbers (again the names should be fully listed), - and that other the existing routines are not modified as long they are internally able to handle large messages. Please have a look at the existing change-log items. Rolf ----- Original Message ----- > From: "Jeff Squyres" <jsquyres(a)cisco.com> > To: "MPI Forum list" > Sent: Wednesday, April 20, 2011 11:07:30 PM > Subject: [Mpi-forum] Changelog question > Rolf -- > > Per your comments, we made up a changelog entry for the MPI_Count > ticket. MPI_Count isn't *too* large, but it does touch a lot of > individual places. > > Here's how our changelog entry rendered in PDF; is this generally what > you had in mind? > > ----- > Section 2.5.8 on page 16, Section 3.2.2 on page 29, Section 3.3 on > page 31, Section 4.1.5 on page 97, Section 4.1.7 on page 99, Section > 4.1.8 on page 101, Section 4.1.11 on page 105, Section 5.9.2 on page > 172, Section 12.3 on page 412, Section A.1.1 on page 545, > > Introduce MPI_Count, a type large enough to represent element counts > in memory, file views, etc., and associated functions. > ----- > > Or should we be more brief and not list every individual section/page > that we touched? I could see this getting problematic for some other > tickets (e.g., Fortran). > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/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: Allmandring 30)

1 0

Changelog question
by Jeff Squyres 20 Apr '11

20 Apr '11

Rolf -- Per your comments, we made up a changelog entry for the MPI_Count ticket. MPI_Count isn't *too* large, but it does touch a lot of individual places. Here's how our changelog entry rendered in PDF; is this generally what you had in mind? ----- Section 2.5.8 on page 16, Section 3.2.2 on page 29, Section 3.3 on page 31, Section 4.1.5 on page 97, Section 4.1.7 on page 99, Section 4.1.8 on page 101, Section 4.1.11 on page 105, Section 5.9.2 on page 172, Section 12.3 on page 412, Section A.1.1 on page 545, Introduce MPI_Count, a type large enough to represent element counts in memory, file views, etc., and associated functions. ----- Or should we be more brief and not list every individual section/page that we touched? I could see this getting problematic for some other tickets (e.g., Fortran). -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

May 9-11 MPI Forum registration
by RICHARD GRAHAM 20 Apr '11

20 Apr '11

The registration for the upcoming May MPI Forum meeting at Cisco in San Jose, CA. The link is at https://www.ornl.gov/ccsd_registrations/nccs_mpi_forums/ HOWEVER, this time ALL must plan on paying for the meeting by check. At this stage we are unable to take credit-card payments, and are not sure when this will change. Rich

1 0