March 2014 - mpi-forum - mailman3.cels.anl.gov

Status of vendor MPI 3.0 RMA implementations
by Dan Holmes 24 Mar '14

24 Mar '14

What is the current status of MPI 3.0 RMA support in vendor implementations? Both MPICH and OpenMPI now claim full compliance. Other than that, the latest information I have is likely to be out-dated. Cheers, Dan. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: [Mpi-forum] Use of MPI_STATUS_IGNORE
by Fab Tillier 20 Mar '14

20 Mar '14

Yes, perfect, thank you! -Fab -----Original Message----- From: mpi-forum [mailto:[email protected]] On Behalf Of Rolf Rabenseifner Sent: Wednesday, March 19, 2014 11:39 PM To: Main MPI Forum mailing list Subject: Re: [Mpi-forum] Use of MPI_STATUS_IGNORE Dear Fab, MPI-3.0 p32:32-36 may answer your question? I also expect that this wording is at the best place. Best regards Rolf ----- Original Message ----- > From: "Fab Tillier" <ftillier(a)microsoft.com> > To: mpi-forum(a)lists.mpi-forum.org > Sent: Thursday, March 20, 2014 5:42:05 AM > Subject: [Mpi-forum] Use of MPI_STATUS_IGNORE > > > > > > Is MPI_STATUS_IGNORE valid as the status parameter to the following > functions: > > - MPI_Request_get_status > > - MPI_Probe > > - MPI_Iprobe > > > > Should the standard clarify either way? > > > > Thanks, > > -Fab > _______________________________________________ > 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: Room 1.307) _______________________________________________ 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] Use of MPI_STATUS_IGNORE
by Rolf Rabenseifner 20 Mar '14

20 Mar '14

Dear Fab, MPI-3.0 p32:32-36 may answer your question? I also expect that this wording is at the best place. Best regards Rolf ----- Original Message ----- > From: "Fab Tillier" <ftillier(a)microsoft.com> > To: mpi-forum(a)lists.mpi-forum.org > Sent: Thursday, March 20, 2014 5:42:05 AM > Subject: [Mpi-forum] Use of MPI_STATUS_IGNORE > > > > > > Is MPI_STATUS_IGNORE valid as the status parameter to the following > functions: > > - MPI_Request_get_status > > - MPI_Probe > > - MPI_Iprobe > > > > Should the standard clarify either way? > > > > Thanks, > > -Fab > _______________________________________________ > 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: Room 1.307)

1 0

Use of MPI_STATUS_IGNORE
by Fab Tillier 19 Mar '14

19 Mar '14

Is MPI_STATUS_IGNORE valid as the status parameter to the following functions: - MPI_Request_get_status - MPI_Probe - MPI_Iprobe Should the standard clarify either way? Thanks, -Fab

1 0

DNS migration of mpi-forum.org
by Jeff Squyres (jsquyres) 18 Mar '14

18 Mar '14

Tomorrow at 9am US Eastern, IU will be changing the IU-hosted IP addresses of *.mpi-forum.org (and all of its associated services: email, web, etc.). They're hoping it causes no downtime -- there should be proxies in place to relay traffic from the old IP addresses for the next week or two, so that no one should notice anything different while the DNS change is propagating. svn.mpi-forum.org will not be affected. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [Mpi-forum] MPI_ERR_UNSUPPORTED_DATAREP error class definition scoped too tightly
by Rajeev Thakur 13 Mar '14

13 Mar '14

Even if we remove the reference to File_set_view, people may not expect non-I/O functions to return any of those error classes. It is located in the I/O chapter, the section title is "I/O Error Classes", and the first line of the section is "The implementation dependent error codes returned by the I/O routines can be converted into the error classes defined in Table 13.3." There is another error class there that could be used elsewhere: MPI_ERR_NOT_SAME - Collective argument not identical on all processes, or collective routines called in a different order by different processes Rajeev On Mar 13, 2014, at 5:08 PM, Fab Tillier <ftillier(a)microsoft.com> wrote: > Ok, how about removing the reference to MPI_FILE_SET_VIEW, then? > > I'd like to return MPI_ERR_UNSUPPORTED_DATAREP as the error class in MPI_PACK_* functions for that case, and the current text kind of prohibits that. > > We can then rationalize the location of error classes in MPI-4. > > -Fab > > Rajeev Thakur wrote on Thu, 13 Mar 2014 at 12:52:44 > >> The table on pg 551 is about I/O error codes and classes. So >> Pack_external/Unpack_external (from 9 chapters away) would look out of >> place there. The real solution might be to move the I/O error codes >> and classes from the I/O chapter to the chapter on error codes and >> classes, but that would be more than a ticket 0 change. >> >> Rajeev >> >> >> >> On Mar 13, 2014, at 12:02 PM, Fab Tillier <ftillier(a)microsoft.com> wrote: >> >>> Hi folks, >>> >>> The standard defines MPI_ERR_UNSUPPORTED_DATAREP as an I/O error >> class, with the meaning "Unsupported datarep passed to >> MPI_FILE_SET_VIEW". However, datareps are also passed as input to >> MPI_PACK_EXTERNAL and MPI_UNPACK_EXTERNAL. Shouldn't these functions >> use the same error class for unsupported datareps, rather than >> MPI_ERR_ARG? >>> >>> Can we update the description of MPI_ERR_UNSUPPORTED_DATAREP >> (page 551, line 10) to also include MPI_PACK_EXTERNAL and >> MPI_UNPACK_EXTERNAL as a ticket-0 item for MPI 3.1, or will this need >> to happen in a later version? >>> >>> Thanks, >>> -Fab >>> _______________________________________________ >>> 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 > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Summary of decisions made at last week's forum meeting
by Schulz, Martin 13 Mar '14

13 Mar '14

Hi all, During last week's forum meeting, we made several decisions which have larger impact. Those are summarized below (please especially read the chapter committee and future meeting parts, which is very important) and are also in the slides that Jeff already posted to the web site. Also, I updated the main webpages to reflect this information - please let me know if you have any questions or comments. Thanks, Martin 1) Timeline for MPI 3.1 We decided (per formal vote) to stick with the timeline decided on in Chicago in December to aim for ratifying an MPI 3.1 standard (which is mainly the integration of errata and smaller additions) during the meeting in December 2014. This means we have the following timeline: - Last chance for readings of new tickets was the March 2014 meeting - Last chance for first votes during the June 2014 meeting - Last chance for second votes during the September 2014 meeting in Japan (also last chance for adding errata items) - Final chapter and document votes in December 2014 2) Document integration procedures for MPI 3.1 Chapter committees will be responsible for integrating and reviewing all changes into the standard document. For already voted in tickets, errata items, and ticket 0 changes, this process can start immediately, at the latest, though, this work needs to be done between the September and December meetings. Please keep in mind that we have SC and Thanksgiving in this time period and hence the earlier this process can start, the better. We decided to no longer use the Latex change macros for adding the new text, since those led to bad document quality (feel free to still use them for working group documents and ticket presentations - I am just talking about the main document). Instead we will rely on "svn diff" for change tracking. To make this work, please don't reflow any text! Also, please make sure you follow the document instructions contained in the MPI document repository (see README) to make sure we get a consistent document. At the end of the process, every chapter committee chair is expected to provide: - A new PDF of the chapter with all changes integrated (clean document, without any change bars) - An SVN diff document (informal to help people track things) compared to a clean copy of MPI 3.0 - A side document detailing all changes from MPI 3.0 (tickets, errata item, ticket 0 items beyond typos, e.g., examples) These documents need to be reviewed by the chapter committee and made available at least two weeks before the December meeting. 3) Chapter committees To make this process work, we need *active and responsive* chapter committees. The current members for each chapter are listed on the MPI 3.1 web pages. However, this information is a bit old by now and probably includes inactive members. Therefore: - if you are on a chapter committee and want to continue to work on that role, please send me email in the next few weeks - otherwise, I'll assume you do no longer want to serve (which is fine as well) - if you don't want to serve, you can also send me email and I'll remove you immediately. - if you are not serving on a particular committee, but would like to, let me know and I'll add you We also need to pick chairs again. For the following groups we have volunteers from the last forum: - P2P: Dan Holmes - Groups: Pavan Balaji - RMA: Bill Gropp - External interfaces: Pavan Balaji - Tools: Kathryn Mohror - Language Bindings: Jeff Squyres but this is obviously not complete and we need more volunteers for the rest. Please let me know if you want to sign up for leading the integration and review efforts for one of the remaining chapters. 4) Tickets We have many outdated tickets in the system and it is getting hard to distinguish them from the active ones. Please help cleaning up the system. In particular, we now have "version" entries for MPI 3.0 errata, MPI 3.1, and MPI 4.0. Those should be the only official categories for any currently open tickets. The also existing intermediate solution of "MPI <next>" will go away (that's where a majority of old tickets is) and I will close all those tickets in the next months. If you want to keep a ticket from this group alive, please adjust it to the right version. Also, new tickets should only be created after discussions in the working group and after the group decides to put this idea forward towards the MPI voting process. Before that, it would be better to maintain information in the working group Wikis. 5) Next meetings We talked about the meeting schedule for 2015 - here are the proposed locations and dates: - March 2-5 in Portland, OR - June 1-4 in Chicago, IL - September with EuroMPI (France?) - December 7-10 in San Jose, CA We are checking on room availability, but we also need to check for conflicts. If you are aware of any, please let me know asap. We should conclude this discussion at the latest by the next meeting so people have a fair warning. 6) Logo Finally, we decided on a new logo (with a formal vote that produced a clear result in the first round of votes) - the forum decided to use the logo from group 1. Thanks to Huiwei Lu from ANL for creating it! Jeff and his team already switched the logo on the website (thanks!) and I'll make higher res versions available on the web site as well. ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [Mpi-forum] MPI_ERR_UNSUPPORTED_DATAREP error class definition scoped too tightly
by Fab Tillier 13 Mar '14

13 Mar '14

Ok, how about removing the reference to MPI_FILE_SET_VIEW, then? I'd like to return MPI_ERR_UNSUPPORTED_DATAREP as the error class in MPI_PACK_* functions for that case, and the current text kind of prohibits that. We can then rationalize the location of error classes in MPI-4. -Fab Rajeev Thakur wrote on Thu, 13 Mar 2014 at 12:52:44 > The table on pg 551 is about I/O error codes and classes. So > Pack_external/Unpack_external (from 9 chapters away) would look out of > place there. The real solution might be to move the I/O error codes > and classes from the I/O chapter to the chapter on error codes and > classes, but that would be more than a ticket 0 change. > > Rajeev > > > > On Mar 13, 2014, at 12:02 PM, Fab Tillier <ftillier(a)microsoft.com> wrote: > >> Hi folks, >> >> The standard defines MPI_ERR_UNSUPPORTED_DATAREP as an I/O error > class, with the meaning "Unsupported datarep passed to > MPI_FILE_SET_VIEW". However, datareps are also passed as input to > MPI_PACK_EXTERNAL and MPI_UNPACK_EXTERNAL. Shouldn't these functions > use the same error class for unsupported datareps, rather than > MPI_ERR_ARG? >> >> Can we update the description of MPI_ERR_UNSUPPORTED_DATAREP > (page 551, line 10) to also include MPI_PACK_EXTERNAL and > MPI_UNPACK_EXTERNAL as a ticket-0 item for MPI 3.1, or will this need > to happen in a later version? >> >> Thanks, >> -Fab >> _______________________________________________ >> 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

1 0

Re: [Mpi-forum] MPI_ERR_UNSUPPORTED_DATAREP error class definition scoped too tightly
by Rajeev Thakur 13 Mar '14

13 Mar '14

The table on pg 551 is about I/O error codes and classes. So Pack_external/Unpack_external (from 9 chapters away) would look out of place there. The real solution might be to move the I/O error codes and classes from the I/O chapter to the chapter on error codes and classes, but that would be more than a ticket 0 change. Rajeev On Mar 13, 2014, at 12:02 PM, Fab Tillier <ftillier(a)microsoft.com> wrote: > Hi folks, > > The standard defines MPI_ERR_UNSUPPORTED_DATAREP as an I/O error class, with the meaning “Unsupported datarep passed to MPI_FILE_SET_VIEW”. However, datareps are also passed as input to MPI_PACK_EXTERNAL and MPI_UNPACK_EXTERNAL. Shouldn’t these functions use the same error class for unsupported datareps, rather than MPI_ERR_ARG? > > Can we update the description of MPI_ERR_UNSUPPORTED_DATAREP (page 551, line 10) to also include MPI_PACK_EXTERNAL and MPI_UNPACK_EXTERNAL as a ticket-0 item for MPI 3.1, or will this need to happen in a later version? > > Thanks, > -Fab > _______________________________________________ > 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] info key text normative?
by Jeff Hammond 13 Mar '14

13 Mar '14

I am referring to the specific case where info key text says "X is the default behavior" and I wonder if X is binding if this info key is not used. Jeff On Thu, Mar 13, 2014 at 12:14 PM, Fab Tillier <ftillier(a)microsoft.com> wrote: > Hi Jeff, > > Jeff Hammond wrote on Thu, 13 Mar 2014 at 09:48:59 > >> Is the text that describes info keys normative, i.e. binding? > > Yes, the mechanics of info keys are well defined, and the standard defines reserved keys for file objects (page 500). > >> I thought implementations were free to ignore info keys and thus >> the text defining them was not necessarily normative. > > Implementations can ignore keys, but this doesn't change how info keys behave from an interface perspective. > > At least that's my take on it. > -Fab > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Jeff Hammond jeff.science(a)gmail.com

1 0