July 2012 - mpi-forum - mailman3.cels.anl.gov

Re: [Mpi-forum] Chapter Reviews
by Rolf Rabenseifner 23 Jul '12

23 Jul '12

Alexander, thank you for your detailed review on Annex 1. Details: ----------------- > 665/14: Remove comma in "C, and Fortran". Apparently, C++ was there. :) done. > 665/16: Replace "chapter" by "section" (tentative). not done. > 665/22: Replace " is listed in the left column" by "s are listed below". The table has only one column now. C++, once again. done. > 665/22: Probably, the whole first sentence should go: there are many Fortran-only tables below, and much more. I let it there. > 665/25 (table): Where is MPI_ERR_NOT_IMPLEMENTED or something? Would be good for those parts of the MPI-3 standard that will naturally lag behind others or cannot be provided on the target platform (like those new windows). Partial implementation / subsetting is not supported by the MPI standard. One may use MPI_OTHER. > 667/4-17: Do not use abbreviations; add underscores to the MPI_T error code names, like: MPI_T_CANNOT_INIT, and so on (otherwise difficult to read and unlike old error codes, but for the MPI_ERR_LASTCODE). If accepted, also affects the MPI_T sections. I'll forward this to the tools group. They changed CANTINIT into CANNOTINIT. They keep the names without underscores. Underscores are used only for the structural parts. It is currently under discussion and will be fixed this week. > 669/12: Add "signed " ahead of "long long" (like in the previous line). Done as on page 26 > 669/25: Why bother pointing out the header? Remove this line. It is as on page 26 > 671/1: Remove " and C++" in the parentheses. No C++ binding, right? Yes, removed ecverywhere. > 674/43: Add "." (period) at the end of the sentence. done. > 676/29-30: Fix indentation. Done. > 676/36: Fix indentation. Done. > 677/29 (table): Some, if not all, of these are predefined memory locations in Fortran. Would be good to highlight this, like in the earlier table w/ the MPI_BOTTOM inside. Done. > 680/9-10: Add underscores for better legibility. If accepted, impacts the MPI_T chapter. Not done - same reason as for MPI_T_ERR... names. > 681/1: "and mpi module" - could've been handled by a special Fortran 2008 compatibility module instead. > 681/4: Same here. Decided long time ago in the language chapter. Can't be reported other here in the appLang chapter. > 682/20: Here and elsewhere: (optionally) add after this line > END SUBROTINE > END INTERFACE We always show only the important header lines and never the trailing lines. Therefore would not change this. p684:36 - p686:37 and same lines in MPI-2.2 also do not have the END SUBROUTINE lines. > 682/31: Same. > 682/37: Same. > 682/48: Same. > 683/6: Same. > 683/16: Same. > 683/23: Same. > 683/29: Same. > 683/36: Same. > 683/43: Same. > 684/5: Same. > 684/10: Same. > 684/16: Same. > 684/25: Same. > 684/34: Same. Dito. > 759/25-27: Remove these lines: empty sections. It is hard to do because they are generated automatically. I'll ask Bill. > 788/18: Remove this line: the section is empty. It is hard to do because they are generated automatically. I'll ask Bill. Thanks again for your detailed and helpful review. Best regards Rolf ----- Original Message ----- > From: "Alexander Supalov" <alexander.supalov(a)intel.com> > To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > Sent: Friday, July 20, 2012 7:28:54 AM > Subject: Re: [Mpi-forum] Chapter Reviews > Done (see attached). What is the procedure to vet and implement these > changes? > > > > By the way, whoever is going to review chapter 17, please look into > 602/1-6: > > > > Compliant MPI-3 implementations providing a Fortran interface must > provide provide > > one or both of the following: > > _ The USE mpi_f08 Fortran support method. > > _ The USE mpi and INCLUDE 'mpif.h' Fortran support methods. > > > > Double “provide” aside, this passage amounts to opening the door to a > silent removal (not even deprecation) of the old Fortran interface. > This cannot be the real intent of the Forum, I hope. Also, some > advices to the implementors effectively suggest breaking backward > compatibility on the old Fortran interface, if retained, up to and > including a failed application build and changes to the application > necessary as a consequence. Again, I think this is a bit too much of a > good thing. > > > > > > From: mpi-forum-bounces(a)lists.mpi-forum.org > [mailto:[email protected]] On Behalf Of Richard > Graham > Sent: Thursday, July 19, 2012 5:29 PM > To: Main MPI Forum mailing list > Subject: Re: [Mpi-forum] Chapter Reviews > > > > Feel free to take it – thanks !!!! > > > > Rich > > > > > > From: mpi-forum-bounces(a)lists.mpi-forum.org > [mailto:[email protected]] On Behalf Of Supalov, > Alexander > Sent: Thursday, July 19, 2012 11:02 AM > To: Main MPI Forum mailing list > Subject: Re: [Mpi-forum] Chapter Reviews > > > > Hi Rich, > > > > It might help those interested if you described the applicable > deadlines, the desired output of the review, and the resp. correction > procedure, should it become necessary. > > > > I hate to see my favorite Appendix A orphaned. Anyone against my > taking on it? > > > > Best regards. > > > > Alexander > > > > > > From: mpi-forum-bounces(a)lists.mpi-forum.org > [mailto:[email protected]] On Behalf Of Richard > Graham > Sent: Thursday, July 19, 2012 4:45 PM > To: mpi-forum(a)lists.mpi-forum.org > Subject: [Mpi-forum] Chapter Reviews > > > > We are currently doing chapter reviews for the forum – all tickets are > committed and reviewed. If anyone has changes to make please > coordinate this morning (Thursday 7/19/2012 – Chicago time) with the > person who is doing the review. After these are done, responsibility > will revert to the chapter committees. I will send out a separate > note on the timelines we agreed to yesterday, but in a nutshell, all > changes must be completed and reviewed by Thursday 7/26/2012, 5pm > Pacific time, so that we can prepare a draft version to be posted for > comment. > > > > If someone remote would like to take the responsibility for an > unclaimed chapter, please let me know. > > > > Thanks, > > Rich > > > > Chapter Reviewer > > Front Matter Mohamad > > Chap 1 Brian B. > > Chap 2 Scott > > Chap 3 Anh > > Chap 4 Terry > > Chap 5 Nathan > > Chap 6 Darius > > Chap 7 Shinji > > Chap 8 Pavan > > Chap 9 Howard - done > > Chap 10 Hideyuki > > Chap 11 Howard > > Chap 12 Brian S. > > Chap 13 Brian S. > > Chap 14 Rich > > Chap 15 > > Chap 16 > > Chap 17 > > Appendix A > > Appendix B Jeff/Rolf > > Bib > > Indices > > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer, > Christian Lamprechter > Registergericht: Muenchen HRB 47456 > Ust.-IdNr./VAT Registration No.: DE129385895 > Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer, > Christian Lamprechter > Registergericht: Muenchen HRB 47456 > Ust.-IdNr./VAT Registration No.: DE129385895 > Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 > _______________________________________________ > 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] Chapter Reviews
by Rolf Rabenseifner 23 Jul '12

23 Jul '12

Rich, Brian, Bronis, and reviewers of - Chap 15 Deprecated - Chap 16 Removed Functions - Chap 17 Language Bindings Please can I get the info, who took these 3 chapters for reviewing? I only remember that Bronis or Brian took one of these. (Alexander Supalov did Annex A. and I already made most corrections based on his reply) Best regards Rolf ----- Original Message ----- > From: "Richard Graham" <richardg(a)mellanox.com> > To: mpi-forum(a)lists.mpi-forum.org > Sent: Thursday, July 19, 2012 4:44:44 PM > Subject: [Mpi-forum] Chapter Reviews > We are currently doing chapter reviews for the forum – all tickets are > committed and reviewed. If anyone has changes to make please > coordinate this morning (Thursday 7/19/2012 – Chicago time) with the > person who is doing the review. After these are done, responsibility > will revert to the chapter committees. I will send out a separate > note on the timelines we agreed to yesterday, but in a nutshell, all > changes must be completed and reviewed by Thursday 7/26/2012, 5pm > Pacific time, so that we can prepare a draft version to be posted for > comment. > > > > If someone remote would like to take the responsibility for an > unclaimed chapter, please let me know. > > > > Thanks, > > Rich > > > > Chapter Reviewer > > Front Matter Mohamad > > Chap 1 Brian B. > > Chap 2 Scott > > Chap 3 Anh > > Chap 4 Terry > > Chap 5 Nathan > > Chap 6 Darius > > Chap 7 Shinji > > Chap 8 Pavan > > Chap 9 Howard - done > > Chap 10 Hideyuki > > Chap 11 Howard > > Chap 12 Brian S. > > Chap 13 Brian S. > > Chap 14 Rich > > Chap 15 > > Chap 16 > > Chap 17 > > Appendix A > > Appendix B Jeff/Rolf > > Bib > > Indices > _______________________________________________ > 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] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE
by Rolf Rabenseifner 23 Jul '12

23 Jul '12

Martin et al., Consistently with your proposal, I would recommend: 1) Sect 14.3.9 "Return Codes for the MPI tool information interface" last sentence reads All return codes with the prefix MPI_T_ must be unique values and cannot overlap with any other return values returned by the MPI implementation. but should read > All return codes with the prefix MPI_T_ must be unique values and > cannot overlap with any other error codes and error classes > returned by the MPI > implementation. Further, they shall be treated as MPI error classes as > defined in Chapter 8.4 and follow the same rules and restrictions, especially they must satisfy > >>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. 2) A.1.1 the first three tables are headed by Error classes Error classes (continued) Return Codes for the MPI tool information interface and these lines should read Error classes Error classes (continued) Error classes (continued) 3) The last line of A.1.1, 2nd table MPI_ERR_LASTCODE should move after the last MPI_T_ERR_... code in the 3rd table. Okay? The topic about user-callability of MPI_ERROR_CLASS and MPI_ERROR_STRING outside of the initialized MPI should be revisited in MPI-3.1. This is not evident for the tools' developers because they know the meaning of their MPI_T_ERR... classes and only classes are returned. I would like to have a final "okay" before I execute the changes in chap-appLang. Best regards Rolf ----- Original Message ----- > From: "Martin Schulz" <schulzm(a)llnl.gov> > To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > Sent: Monday, July 23, 2012 1:23:40 AM > Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE > Hi Rolf, all, > > I thought we had discussed the error semantics of MPI_T in several > meetings/readings and nobody objected, but I generally agree with your > comments below. However, they are not really error classes (at least > in the tools group we/I never thought about them this way), but just > well defined return codes. Nevertheless, they fit the model and > semantics of classes and hence should integrated into the same rules > for consistency. I also agree with Bronis, though, that larger > feedback on this would be good to avoid errors because of rushing it. > > To keep changes minimal, I would suggest that we only change the > following sentence, which IMHO is sufficient (and would essentially > follow option b): > > All return codes with the prefix MPI_T_ must be unique values and > cannot overlap with any other return values returned by the MPI > implementation. Further, they shall be treated as MPI error classes as > defined in Chapter 8.4 and follow the same rules and restrictions. > > This would also make changes in the appendix unnecessary. > > As for making MPI_ERROR_CLASS and MPI_ERROR_STRING callable before > Init (and then also after finalize), yes that would be very useful, > but is a general issue not only related to MPI_T. If we decide this is > too invasive at this point, I would like to see this at least in 3.1. > > Martin > > > > > On Jul 22, 2012, at 1:46 PM, Rolf Rabenseifner wrote: > > > About 1. question: > > > > I changed the headers of the three error code tables in the Annex > > according to Tables 8.1 and 8.2 from "Return codes" > > into "Error classes". > > > > svn r1505: I used also "Error classes" for the tools table > > svn r1507: I went back to the official ticket 266 text "Return > > codes" > > > > The Tools group should decide whether > > a. they want to stay with special return codes that are not > > part of the rule in Set. 8.4 > > > > 0 = MPI_SUCCESS < MPI_ERR_... <= MPI_ERR_LASTCODE > > > > In this case they should change "return code" > > into "error codes are returned" plus noting that > > the routine MPI_ERROR_STRING can be applied > > with the open question, whether MPI_EEROR_STRING > > can be applied before a call to MPI_INIT. > > > > Similar problem with failed MPI_INIT and analysing its > > returned error code: > > One needs at least MPI_ERROR_CLASS and MPI_ERROR_STRING > > callable before MPI_INIT. > > > > b. or you may use the same terminology as in Sect. 8.4, > > then new table 14.5 must show "Error classes". > > > > In this case you should integrate the MPI_T_ERR_... > > into the MPI_ERR_LASTCODE rule. > > > > You need at least MPI_ERROR_CLASS and MPI_ERROR_STRING > > callable before MPI_INIT. > > > > I would prefer solution b together combined with the > > minimal solution for failed MPI_INIT, i.e., > > adding MPI_ERROR_CLASS and MPI_ERROR_STRING to > > the list of routines callable outside of MPI's > > initialization. > > > > > > About 2. question: MPI_T_ERR_CANTINIT -_> MPI_T_ERR_CANNOTINIT > > > > svn r1506: done by Bronis in chap-tools/mpit.tex > > svn r1508: done by Rolf in chap-appLang/appLang-Const.tex > > > > 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> > >> Cc: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > >> Sent: Sunday, July 22, 2012 10:03:44 PM > >> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE > >> Rolf: > >> > >> OK, I am changing MPI_T_ERR_CANTINIT to MPI_T_ERR_CANNOTINIT. > >> > >> As said before, we need more opinions on the first question. > >> > >> Bronis > >> > >> > >> On Sun, 22 Jul 2012, Bronis R. de Supinski wrote: > >> > >>> > >>> Rolf: > >>> > >>> Re: > >>>> Dear Bronis, Martin, Dave, and Kathryn, > >>>> (Profiling/Tools chapter responsibles) > >>>> > >>>> (you may forward this to the tools list - I'm not on that list) > >>>> > >>>> Two important questions: > >>>> > >>>> 1. Alexander Supalov detected that we did it wrong: > >>>> The MPI_T_ERR_... list must be part of the total error > >>>> list and sorted in before MPI_ERR_LASTCODE. > >>>> > >>>> I will change this in chap-appLang/appLang-Const.tex > >>>> > >>>> Please look, if there must be some additional wording on this. > >>>> For example, the last sentence of Section 14.3.9 > >>>> > >>>> "All return codes with the prefix MPI_T_ must be unique values > >>>> and > >>>> cannot overlap with any other return values returned by the MPI > >>>> implementation." > >>> > >>> The above wording clearly states that the return values > >>> should be consistent with MPI_ERR_* return values. So, > >>> either the above wording needs to change (I do not see > >>> why MPI_T_* return values need to be distinct from > >>> MPI_ERR_* return values since the user should know that > >>> they were using an MPI_T_* function) or we need to adopt > >>> something like what you suggest. > >>> > >>> I think we need broader opinions to make the decision. > >>> > >>> I am concerned that wrapping up the document for MPI 3.0 > >>> has led to a fast and loose attitude about making broader > >>> changes "in order to get it done." This attitude can > >>> easily lead to suboptimal solutions. > >>> > >>> Bronis > >>> > >>> > >>> > >>>> may be modified into > >>>> > >>>> "All return codes with the prefix MPI_T_ must be unique values > >>>> and > >>>> cannot overlap with any other return values returned by the MPI > >>>> implementation and satisfy > >>>> > >>>> 0 = MPI_SUCCESS < MPI_T_ERR_... <= MPI_ERR_LASTCODE. " > >>>> > >>>> or > >>>> 0 = MPI_SUCCESS < MPI_ERR_... < MPI_T_ERR_... <= > >>>> MPI_ERR_LASTCODE. > >>>> > >>>> or > >>>> 0 = MPI_SUCCESS < MPI_ERR_... <= MPI_ERR_LASTCODE < > >>>> MPI_T_ERR_... <= MPI_T_ERR_LASTCODE. > >>>> > >>>> and the MPI_ERR_LASTCODE and/or MPI_T_ERR_LASTCODE may be also > >>>> repeated > >>>> in Table 14.5 as last entry, as done for the first value > >>>> MPI_SUCCESS. > >>>> > >>>> This proposal is based on Section 8.4, the sentence > >>>> > >>>> "The error codes satisfy, > >>>> 0 = MPI_SUCCESS < MPI_ERR_... <= MPI_ERR_LASTCODE: " > >>>> > >>>> Please confirm, that Alexander is right, > >>>> please include me in your discussion and > >>>> please tell me your result > >>>> that I can do the correct changes in chap-appLang > >>>> and you in chap-tools. > >>>> > >>>> 2. Qeustion is less important; it is about naming: > >>>> Alexander also noticed that your names do not fit to the names > >>>> used in the past: > >>>> > >>>> MPI_T_ERR_CANTINIT --> MPI_T_ERR_CANNOTINIT (we do not use > >>>> abbrevations) > >>>> > >>>> or > >>>> > >>>> MPI_T_ERR_CANTINIT --> MPI_T_ERR_CANNOT_INIT (we do not use > >>>> abbrevations) > >>>> > >>>> In most cases, we do not combine words without underscore. > >>>> > >>>> As far as I see, you can do the underscores. > >>>> Be sure to stay at maximum with 30 characters. > >>>> > >>>> Current longest MPI_T constants: > >>>> > >>>> 123456789012345678901234567890 > >>>> MPI_T_PVAR_CLASS_HIGHWATERMARK > >>>> MPI_T_PVAR_CLASS_LOWWATERMARK > >>>> MPI_T_VERBOSITY_MPIDEV_DETAIL > >>>> > >>>> Based on this, I would stay with you names based on your MPI_T > >>>> rule: > >>>> MPI_T_<structual-areas-with-underscores>_<final-name-without-underscores> > >>>> > >>>> i.e., I would only change > >>>> > >>>> MPI_T_ERR_CANTINIT --> MPI_T_ERR_CANNOTINIT > >>>> > >>>> Please tell me also your decision > >>>> that I can do the correct changes in chap-appLang > >>>> and you in chap-tools. > >>>> > >>>> 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) > >>>> > >>> _______________________________________________ > >>> 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 > > ________________________________________________________________________ > Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm > CASC @ Lawrence Livermore National Laboratory, Livermore, USA > > > > > _______________________________________________ > 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] MPI_INFO_GET_ENV naming question
by Rolf Rabenseifner 23 Jul '12

23 Jul '12

George et al., can I change MPI_INFO_GET_ENV into MPI_INFO_ENV in one step in all three chapters: chap-inquiry chap-appLang chap-changes ? Best regards Rolf ----- Original Message ----- > From: "Martin Schulz" <schulzm(a)llnl.gov> > To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > Cc: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > Sent: Monday, July 23, 2012 12:40:35 AM > Subject: Re: [Mpi-forum] MPI_INFO_GET_ENV naming question > Hi Rolf, all, > > (this is mainly directed at George, Marc, and the Environment chapter > committee) > > On Jul 22, 2012, at 3:41 AM, Rolf Rabenseifner wrote: > > > Martin, > > > > Can we take this as a decision? > > So far there is no objection. > > I am very much in favor of it - I think it makes things much less > confusing. Also, I agree, so far all comments were in favor of the > change. > > > It must be changed in tools and appLang, therefore, I need a clear > > decision for appLang (as chapter author). > > It doesn't affect the tools chapter - it's in the environment chapter > that I helped edit for the time of the meeting in Chicago. This is > George's chapter and Marc's ticket, though, and we haven't heard from > them. Also, George would have to implement it or at least OK the > change. I can make the changes, if this is our decision, but I would > need to hear from George before going in and editing. > > Martin > > > > > > Please tell. > > > > Best regards > > Rolf > > > > > > ----- Original Message ----- > >> From: "William Gropp" <wgropp(a)illinois.edu> > >> To: "Martin Schulz" <schulzm(a)llnl.gov>, "Main MPI Forum mailing > >> list" <mpi-forum(a)lists.mpi-forum.org> > >> Sent: Friday, July 20, 2012 6:11:41 PM > >> Subject: Re: [Mpi-forum] MPI_INFO_GET_ENV naming question > >> I prefer MPI_INFO_ENV . Using GET in the name will be confusing. > >> > >> Bill > >> > >> 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 > >> > >> > >> > >> On Jul 19, 2012, at 12:25 PM, Schulz, Martin wrote: > >> > >>> Hi all, > >>> > >>> During the chapter review for Chapter 8, the environment chapter, > >>> a > >>> question came up at the forum, which we thought requires wider > >>> feedback. > >>> > >>> Ticket 313 introduced an info object into MPI 3.0 that allows > >>> users > >>> to query the environment, which is called MPI_INFO_GET_ENV. This > >>> name, however, contains a verb and hence follows the naming > >>> structure of an MPI function, but is a constant. Hence, should we > >>> really go with this name or should we rename this into a name > >>> without a verb, like MPI_INFO_ENV, to avoid confusion? People in > >>> the > >>> room were leaning towards the latter and this is clearly ticket 0 > >>> at > >>> this point, but we wanted to ask to make sure there is no > >>> unintended > >>> impact with that change. > >>> > >>> Comments? > >>> Thanks, > >>> > >>> Martin > >>> > >>> > >>> ________________________________________________________________________ > >>> Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm > >>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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) > > ________________________________________________________________________ > Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm > CASC @ Lawrence Livermore National Laboratory, Livermore, USA -- 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

MPI_ADDRESS should be MPI_GET_ADDRESS?
by William Gropp 22 Jul '12

22 Jul '12

In chap-binding/binding-2.tex, there is an occurrence of MPI\_ADDRESS that I believe should be MPI\_GET\_ADDRESS: @@ -5270,7 +5284,7 @@ \item Routines that create persistent request \item \mpifunc{MPI\_BUFFER\_ATTACH} \item \mpifunc{MPI\_BUFFER\_DETACH} -\item \mpifunc{MPI\_ADDRESS} +\item \MPIupdate{3.0}{278}{\mpifunc{MPI\_ADDRESS}}{\mpifunc{MPI\_GET\_ADDRESS} I there are no dissents, I can commit this with the missing example annotations for the example checker. Bill 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] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE
by Schulz, Martin 22 Jul '12

22 Jul '12

Hi Rolf, all, I thought we had discussed the error semantics of MPI_T in several meetings/readings and nobody objected, but I generally agree with your comments below. However, they are not really error classes (at least in the tools group we/I never thought about them this way), but just well defined return codes. Nevertheless, they fit the model and semantics of classes and hence should integrated into the same rules for consistency. I also agree with Bronis, though, that larger feedback on this would be good to avoid errors because of rushing it. To keep changes minimal, I would suggest that we only change the following sentence, which IMHO is sufficient (and would essentially follow option b): All return codes with the prefix MPI_T_ must be unique values and cannot overlap with any other return values returned by the MPI implementation. Further, they shall be treated as MPI error classes as defined in Chapter 8.4 and follow the same rules and restrictions. This would also make changes in the appendix unnecessary. As for making MPI_ERROR_CLASS and MPI_ERROR_STRING callable before Init (and then also after finalize), yes that would be very useful, but is a general issue not only related to MPI_T. If we decide this is too invasive at this point, I would like to see this at least in 3.1. Martin On Jul 22, 2012, at 1:46 PM, Rolf Rabenseifner wrote: > About 1. question: > > I changed the headers of the three error code tables in the Annex > according to Tables 8.1 and 8.2 from "Return codes" > into "Error classes". > > svn r1505: I used also "Error classes" for the tools table > svn r1507: I went back to the official ticket 266 text "Return codes" > > The Tools group should decide whether > a. they want to stay with special return codes that are not > part of the rule in Set. 8.4 > > 0 = MPI_SUCCESS < MPI_ERR_... <= MPI_ERR_LASTCODE > > In this case they should change "return code" > into "error codes are returned" plus noting that > the routine MPI_ERROR_STRING can be applied > with the open question, whether MPI_EEROR_STRING > can be applied before a call to MPI_INIT. > > Similar problem with failed MPI_INIT and analysing its > returned error code: > One needs at least MPI_ERROR_CLASS and MPI_ERROR_STRING > callable before MPI_INIT. > > b. or you may use the same terminology as in Sect. 8.4, > then new table 14.5 must show "Error classes". > > In this case you should integrate the MPI_T_ERR_... > into the MPI_ERR_LASTCODE rule. > > You need at least MPI_ERROR_CLASS and MPI_ERROR_STRING > callable before MPI_INIT. > > I would prefer solution b together combined with the > minimal solution for failed MPI_INIT, i.e., > adding MPI_ERROR_CLASS and MPI_ERROR_STRING to > the list of routines callable outside of MPI's > initialization. > > > About 2. question: MPI_T_ERR_CANTINIT -_> MPI_T_ERR_CANNOTINIT > > svn r1506: done by Bronis in chap-tools/mpit.tex > svn r1508: done by Rolf in chap-appLang/appLang-Const.tex > > 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> >> Cc: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> >> Sent: Sunday, July 22, 2012 10:03:44 PM >> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE >> Rolf: >> >> OK, I am changing MPI_T_ERR_CANTINIT to MPI_T_ERR_CANNOTINIT. >> >> As said before, we need more opinions on the first question. >> >> Bronis >> >> >> On Sun, 22 Jul 2012, Bronis R. de Supinski wrote: >> >>> >>> Rolf: >>> >>> Re: >>>> Dear Bronis, Martin, Dave, and Kathryn, >>>> (Profiling/Tools chapter responsibles) >>>> >>>> (you may forward this to the tools list - I'm not on that list) >>>> >>>> Two important questions: >>>> >>>> 1. Alexander Supalov detected that we did it wrong: >>>> The MPI_T_ERR_... list must be part of the total error >>>> list and sorted in before MPI_ERR_LASTCODE. >>>> >>>> I will change this in chap-appLang/appLang-Const.tex >>>> >>>> Please look, if there must be some additional wording on this. >>>> For example, the last sentence of Section 14.3.9 >>>> >>>> "All return codes with the prefix MPI_T_ must be unique values and >>>> cannot overlap with any other return values returned by the MPI >>>> implementation." >>> >>> The above wording clearly states that the return values >>> should be consistent with MPI_ERR_* return values. So, >>> either the above wording needs to change (I do not see >>> why MPI_T_* return values need to be distinct from >>> MPI_ERR_* return values since the user should know that >>> they were using an MPI_T_* function) or we need to adopt >>> something like what you suggest. >>> >>> I think we need broader opinions to make the decision. >>> >>> I am concerned that wrapping up the document for MPI 3.0 >>> has led to a fast and loose attitude about making broader >>> changes "in order to get it done." This attitude can >>> easily lead to suboptimal solutions. >>> >>> Bronis >>> >>> >>> >>>> may be modified into >>>> >>>> "All return codes with the prefix MPI_T_ must be unique values and >>>> cannot overlap with any other return values returned by the MPI >>>> implementation and satisfy >>>> >>>> 0 = MPI_SUCCESS < MPI_T_ERR_... <= MPI_ERR_LASTCODE. " >>>> >>>> or >>>> 0 = MPI_SUCCESS < MPI_ERR_... < MPI_T_ERR_... <= >>>> MPI_ERR_LASTCODE. >>>> >>>> or >>>> 0 = MPI_SUCCESS < MPI_ERR_... <= MPI_ERR_LASTCODE < >>>> MPI_T_ERR_... <= MPI_T_ERR_LASTCODE. >>>> >>>> and the MPI_ERR_LASTCODE and/or MPI_T_ERR_LASTCODE may be also >>>> repeated >>>> in Table 14.5 as last entry, as done for the first value >>>> MPI_SUCCESS. >>>> >>>> This proposal is based on Section 8.4, the sentence >>>> >>>> "The error codes satisfy, >>>> 0 = MPI_SUCCESS < MPI_ERR_... <= MPI_ERR_LASTCODE: " >>>> >>>> Please confirm, that Alexander is right, >>>> please include me in your discussion and >>>> please tell me your result >>>> that I can do the correct changes in chap-appLang >>>> and you in chap-tools. >>>> >>>> 2. Qeustion is less important; it is about naming: >>>> Alexander also noticed that your names do not fit to the names >>>> used in the past: >>>> >>>> MPI_T_ERR_CANTINIT --> MPI_T_ERR_CANNOTINIT (we do not use >>>> abbrevations) >>>> >>>> or >>>> >>>> MPI_T_ERR_CANTINIT --> MPI_T_ERR_CANNOT_INIT (we do not use >>>> abbrevations) >>>> >>>> In most cases, we do not combine words without underscore. >>>> >>>> As far as I see, you can do the underscores. >>>> Be sure to stay at maximum with 30 characters. >>>> >>>> Current longest MPI_T constants: >>>> >>>> 123456789012345678901234567890 >>>> MPI_T_PVAR_CLASS_HIGHWATERMARK >>>> MPI_T_PVAR_CLASS_LOWWATERMARK >>>> MPI_T_VERBOSITY_MPIDEV_DETAIL >>>> >>>> Based on this, I would stay with you names based on your MPI_T >>>> rule: >>>> MPI_T_<structual-areas-with-underscores>_<final-name-without-underscores> >>>> >>>> i.e., I would only change >>>> >>>> MPI_T_ERR_CANTINIT --> MPI_T_ERR_CANNOTINIT >>>> >>>> Please tell me also your decision >>>> that I can do the correct changes in chap-appLang >>>> and you in chap-tools. >>>> >>>> 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) >>>> >>> _______________________________________________ >>> 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 ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [Mpi-forum] MPI_INFO_GET_ENV naming question
by Schulz, Martin 22 Jul '12

22 Jul '12

Hi Rolf, all, (this is mainly directed at George, Marc, and the Environment chapter committee) On Jul 22, 2012, at 3:41 AM, Rolf Rabenseifner wrote: > Martin, > > Can we take this as a decision? > So far there is no objection. I am very much in favor of it - I think it makes things much less confusing. Also, I agree, so far all comments were in favor of the change. > It must be changed in tools and appLang, therefore, I need a clear > decision for appLang (as chapter author). It doesn't affect the tools chapter - it's in the environment chapter that I helped edit for the time of the meeting in Chicago. This is George's chapter and Marc's ticket, though, and we haven't heard from them. Also, George would have to implement it or at least OK the change. I can make the changes, if this is our decision, but I would need to hear from George before going in and editing. Martin > > Please tell. > > Best regards > Rolf > > > ----- Original Message ----- >> From: "William Gropp" <wgropp(a)illinois.edu> >> To: "Martin Schulz" <schulzm(a)llnl.gov>, "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >> Sent: Friday, July 20, 2012 6:11:41 PM >> Subject: Re: [Mpi-forum] MPI_INFO_GET_ENV naming question >> I prefer MPI_INFO_ENV . Using GET in the name will be confusing. >> >> Bill >> >> 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 >> >> >> >> On Jul 19, 2012, at 12:25 PM, Schulz, Martin wrote: >> >>> Hi all, >>> >>> During the chapter review for Chapter 8, the environment chapter, a >>> question came up at the forum, which we thought requires wider >>> feedback. >>> >>> Ticket 313 introduced an info object into MPI 3.0 that allows users >>> to query the environment, which is called MPI_INFO_GET_ENV. This >>> name, however, contains a verb and hence follows the naming >>> structure of an MPI function, but is a constant. Hence, should we >>> really go with this name or should we rename this into a name >>> without a verb, like MPI_INFO_ENV, to avoid confusion? People in the >>> room were leaning towards the latter and this is clearly ticket 0 at >>> this point, but we wanted to ask to make sure there is no unintended >>> impact with that change. >>> >>> Comments? >>> Thanks, >>> >>> Martin >>> >>> >>> ________________________________________________________________________ >>> Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm >>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA >>> >>> >>> >>> >>> _______________________________________________ >>> 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) ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE
by Rolf Rabenseifner 22 Jul '12

22 Jul '12

About 1. question: I changed the headers of the three error code tables in the Annex according to Tables 8.1 and 8.2 from "Return codes" into "Error classes". svn r1505: I used also "Error classes" for the tools table svn r1507: I went back to the official ticket 266 text "Return codes" The Tools group should decide whether a. they want to stay with special return codes that are not part of the rule in Set. 8.4 0 = MPI_SUCCESS < MPI_ERR_... <= MPI_ERR_LASTCODE In this case they should change "return code" into "error codes are returned" plus noting that the routine MPI_ERROR_STRING can be applied with the open question, whether MPI_EEROR_STRING can be applied before a call to MPI_INIT. Similar problem with failed MPI_INIT and analysing its returned error code: One needs at least MPI_ERROR_CLASS and MPI_ERROR_STRING callable before MPI_INIT. b. or you may use the same terminology as in Sect. 8.4, then new table 14.5 must show "Error classes". In this case you should integrate the MPI_T_ERR_... into the MPI_ERR_LASTCODE rule. You need at least MPI_ERROR_CLASS and MPI_ERROR_STRING callable before MPI_INIT. I would prefer solution b together combined with the minimal solution for failed MPI_INIT, i.e., adding MPI_ERROR_CLASS and MPI_ERROR_STRING to the list of routines callable outside of MPI's initialization. About 2. question: MPI_T_ERR_CANTINIT -_> MPI_T_ERR_CANNOTINIT svn r1506: done by Bronis in chap-tools/mpit.tex svn r1508: done by Rolf in chap-appLang/appLang-Const.tex 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> > Cc: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > Sent: Sunday, July 22, 2012 10:03:44 PM > Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE > Rolf: > > OK, I am changing MPI_T_ERR_CANTINIT to MPI_T_ERR_CANNOTINIT. > > As said before, we need more opinions on the first question. > > Bronis > > > On Sun, 22 Jul 2012, Bronis R. de Supinski wrote: > > > > > Rolf: > > > > Re: > >> Dear Bronis, Martin, Dave, and Kathryn, > >> (Profiling/Tools chapter responsibles) > >> > >> (you may forward this to the tools list - I'm not on that list) > >> > >> Two important questions: > >> > >> 1. Alexander Supalov detected that we did it wrong: > >> The MPI_T_ERR_... list must be part of the total error > >> list and sorted in before MPI_ERR_LASTCODE. > >> > >> I will change this in chap-appLang/appLang-Const.tex > >> > >> Please look, if there must be some additional wording on this. > >> For example, the last sentence of Section 14.3.9 > >> > >> "All return codes with the prefix MPI_T_ must be unique values and > >> cannot overlap with any other return values returned by the MPI > >> implementation." > > > > The above wording clearly states that the return values > > should be consistent with MPI_ERR_* return values. So, > > either the above wording needs to change (I do not see > > why MPI_T_* return values need to be distinct from > > MPI_ERR_* return values since the user should know that > > they were using an MPI_T_* function) or we need to adopt > > something like what you suggest. > > > > I think we need broader opinions to make the decision. > > > > I am concerned that wrapping up the document for MPI 3.0 > > has led to a fast and loose attitude about making broader > > changes "in order to get it done." This attitude can > > easily lead to suboptimal solutions. > > > > Bronis > > > > > > > >> may be modified into > >> > >> "All return codes with the prefix MPI_T_ must be unique values and > >> cannot overlap with any other return values returned by the MPI > >> implementation and satisfy > >> > >> 0 = MPI_SUCCESS < MPI_T_ERR_... <= MPI_ERR_LASTCODE. " > >> > >> or > >> 0 = MPI_SUCCESS < MPI_ERR_... < MPI_T_ERR_... <= > >> MPI_ERR_LASTCODE. > >> > >> or > >> 0 = MPI_SUCCESS < MPI_ERR_... <= MPI_ERR_LASTCODE < > >> MPI_T_ERR_... <= MPI_T_ERR_LASTCODE. > >> > >> and the MPI_ERR_LASTCODE and/or MPI_T_ERR_LASTCODE may be also > >> repeated > >> in Table 14.5 as last entry, as done for the first value > >> MPI_SUCCESS. > >> > >> This proposal is based on Section 8.4, the sentence > >> > >> "The error codes satisfy, > >> 0 = MPI_SUCCESS < MPI_ERR_... <= MPI_ERR_LASTCODE: " > >> > >> Please confirm, that Alexander is right, > >> please include me in your discussion and > >> please tell me your result > >> that I can do the correct changes in chap-appLang > >> and you in chap-tools. > >> > >> 2. Qeustion is less important; it is about naming: > >> Alexander also noticed that your names do not fit to the names > >> used in the past: > >> > >> MPI_T_ERR_CANTINIT --> MPI_T_ERR_CANNOTINIT (we do not use > >> abbrevations) > >> > >> or > >> > >> MPI_T_ERR_CANTINIT --> MPI_T_ERR_CANNOT_INIT (we do not use > >> abbrevations) > >> > >> In most cases, we do not combine words without underscore. > >> > >> As far as I see, you can do the underscores. > >> Be sure to stay at maximum with 30 characters. > >> > >> Current longest MPI_T constants: > >> > >> 123456789012345678901234567890 > >> MPI_T_PVAR_CLASS_HIGHWATERMARK > >> MPI_T_PVAR_CLASS_LOWWATERMARK > >> MPI_T_VERBOSITY_MPIDEV_DETAIL > >> > >> Based on this, I would stay with you names based on your MPI_T > >> rule: > >> MPI_T_<structual-areas-with-underscores>_<final-name-without-underscores> > >> > >> i.e., I would only change > >> > >> MPI_T_ERR_CANTINIT --> MPI_T_ERR_CANNOTINIT > >> > >> Please tell me also your decision > >> that I can do the correct changes in chap-appLang > >> and you in chap-tools. > >> > >> 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) > >> > > _______________________________________________ > > 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] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE
by Bronis R. de Supinski 22 Jul '12

22 Jul '12

Rolf: OK, I am changing MPI_T_ERR_CANTINIT to MPI_T_ERR_CANNOTINIT. As said before, we need more opinions on the first question. Bronis On Sun, 22 Jul 2012, Bronis R. de Supinski wrote: > > Rolf: > > Re: >> Dear Bronis, Martin, Dave, and Kathryn, >> (Profiling/Tools chapter responsibles) >> >> (you may forward this to the tools list - I'm not on that list) >> >> Two important questions: >> >> 1. Alexander Supalov detected that we did it wrong: >> The MPI_T_ERR_... list must be part of the total error >> list and sorted in before MPI_ERR_LASTCODE. >> >> I will change this in chap-appLang/appLang-Const.tex >> >> Please look, if there must be some additional wording on this. >> For example, the last sentence of Section 14.3.9 >> >> "All return codes with the prefix MPI_T_ must be unique values and >> cannot overlap with any other return values returned by the MPI >> implementation." > > The above wording clearly states that the return values > should be consistent with MPI_ERR_* return values. So, > either the above wording needs to change (I do not see > why MPI_T_* return values need to be distinct from > MPI_ERR_* return values since the user should know that > they were using an MPI_T_* function) or we need to adopt > something like what you suggest. > > I think we need broader opinions to make the decision. > > I am concerned that wrapping up the document for MPI 3.0 > has led to a fast and loose attitude about making broader > changes "in order to get it done." This attitude can > easily lead to suboptimal solutions. > > Bronis > > > >> may be modified into >> >> "All return codes with the prefix MPI_T_ must be unique values and >> cannot overlap with any other return values returned by the MPI >> implementation and satisfy >> >> 0 = MPI_SUCCESS < MPI_T_ERR_... <= MPI_ERR_LASTCODE. " >> >> or >> 0 = MPI_SUCCESS < MPI_ERR_... < MPI_T_ERR_... <= MPI_ERR_LASTCODE. >> >> or >> 0 = MPI_SUCCESS < MPI_ERR_... <= MPI_ERR_LASTCODE < MPI_T_ERR_... <= MPI_T_ERR_LASTCODE. >> >> and the MPI_ERR_LASTCODE and/or MPI_T_ERR_LASTCODE may be also repeated >> in Table 14.5 as last entry, as done for the first value MPI_SUCCESS. >> >> This proposal is based on Section 8.4, the sentence >> >> "The error codes satisfy, >> 0 = MPI_SUCCESS < MPI_ERR_... <= MPI_ERR_LASTCODE: " >> >> Please confirm, that Alexander is right, >> please include me in your discussion and >> please tell me your result >> that I can do the correct changes in chap-appLang >> and you in chap-tools. >> >> 2. Qeustion is less important; it is about naming: >> Alexander also noticed that your names do not fit to the names >> used in the past: >> >> MPI_T_ERR_CANTINIT --> MPI_T_ERR_CANNOTINIT (we do not use abbrevations) >> >> or >> >> MPI_T_ERR_CANTINIT --> MPI_T_ERR_CANNOT_INIT (we do not use abbrevations) >> >> In most cases, we do not combine words without underscore. >> >> As far as I see, you can do the underscores. >> Be sure to stay at maximum with 30 characters. >> >> Current longest MPI_T constants: >> >> 123456789012345678901234567890 >> MPI_T_PVAR_CLASS_HIGHWATERMARK >> MPI_T_PVAR_CLASS_LOWWATERMARK >> MPI_T_VERBOSITY_MPIDEV_DETAIL >> >> Based on this, I would stay with you names based on your MPI_T rule: >> MPI_T_<structual-areas-with-underscores>_<final-name-without-underscores> >> >> i.e., I would only change >> >> MPI_T_ERR_CANTINIT --> MPI_T_ERR_CANNOTINIT >> >> Please tell me also your decision >> that I can do the correct changes in chap-appLang >> and you in chap-tools. >> >> 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) >> > _______________________________________________ > 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] Chapter Reviews
by William Gropp 22 Jul '12

22 Jul '12

I will remind everyone that gfortran doesn't have enough Fortran 2008 support to provide mpi_f08 . Its true that gfortran is behind most other Fortran compilers and it is time to provide an F'08 binding; but expecting every user to be able to switch to the F08 binding immediately is not realistic. Bill 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 On Jul 20, 2012, at 2:43 AM, Rolf Rabenseifner wrote: > Both mpich2 and OpenMPI have committed to provide mpi_f08, > therefore there is not a real problem. > There are other MPI's arround that never provided any Fortran > support. Also okay.

1 0