mpi-forum

Download

[email protected]

July 2012

27 participants
235 discussions

Proposal for the mailing text with our public draft MPI-3.0
by Rolf Rabenseifner 25 Jul '12

25 Jul '12

Rich and all, Here a first proposal for correction. I'll send it out to about 14000 HPC people, mainly in Europe, this Friday morning in Europe - text should be finilized on Thursday. Jeff, I did a test on mpi-comments(a)mpi-forum.org through a mail from my not registered colleague (Christoph niethammer), Please can you check. ------------------------------------------------- Subject: MPI-3.0 public draft for comments [Our apologies if you receive multiple copies or you are not related to MPI] Dear MPI-user, The MPI-Forum has developed MPI-3.0, a new version of the MPI standard. We are interested in your comments about the public draft available from July 27 until Sep. 6, 2012 at http://meetings.mpi-forum.org/draft_standard/mpi3.0_draft_2.pdf Your requests/comments can be - Small requests/corrections that can be resolved before finishing 3.0. - Undetected severe inconsistencies or bugs that may delay 3.0. - Wishes for additional enhancements or new functionality to be taken into account in the next release of MPI (i.e. MPI-3.1 or MPI-4.0). Please comment before Sep. 6, 2012 by email to mpi-comments(a)mpi-forum.org Before sending an email, you need to subscribe to the list via http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments Best regards The MPI Forum ----------------------------------------------------- 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] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE
by Rolf Rabenseifner 25 Jul '12

25 Jul '12

Bronis, you're right. Latest text is okay with me. Martin, Adam, Kathryn, Dave, p lease can you also confirm if okay for you. Best regards Rolf ----- Original Message ----- > From: "Bronis R. de Supinski" <bronis(a)llnl.gov> > To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > Cc: "Martin Schulz" <schulzm(a)llnl.gov>, "Kathryn Mohror" <mohror1(a)llnl.gov>, "Dave Goodell" <goodell(a)mcs.anl.gov>, > "Adam T. Moody" <moody20(a)llnl.gov>, "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > Sent: Wednesday, July 25, 2012 2:54:46 PM > Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE > Rolf: > > Um, not quite. The first paragraph should read "error > codes", not "error classes". The routines return error > codes, all of which happen to be error classes. > > I have modified below. > > Bronis > > > On Wed, 25 Jul 2012, Rolf Rabenseifner wrote: > > > Bronis, Martin, Adam, Kathryn, Dave, and all, > > > > Okay, now I understand - I thought Martin's arguments were okay > > for shortening the text - but the original long form is more > > consistent. > > > > Can we therefore agree on the text below. > > It is the text from Bronis plus Adams rationale plus the other > > changes from the original mail. > > > > I would like to have enough okays. > > > > ------------------------------ > > | Changed and new text is marked with a bar. > > ------------------------- > > 1) Sect 14.3.9 "Return Codes for the MPI tool information interface" > > reads > > > > All functions defined as part of the MPI tool information > > interface > > return an integer return code (see Table 14.5) to indicate whether > > the function was completed successfully or was aborted. In the > > latter case the return code indicates the reason for not > > completing > > the routine. None of the return codes returned by an routine > > impact the execution of the MPI process and do not invoke MPI > > error > > handlers. The execution of the MPI process continues as if the > > call would have completed. However, the MPI implementation > > is not required to check all user provided parameters; if a user > > passes invalid parameter values to any routine the behavior of > > the implementation is undefined. > > > > 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 functions defined as part of the MPI tool information interface > return an integer error code (see Table 14.5) to indicate whether > the function was completed successfully or was aborted. In the > latter case the error code indicates the reason for not completing > the routine. None of the error codes returned by an routine > impact the execution of the MPI process and do not invoke MPI error > handlers. The execution of the MPI process continues as if the > call would have completed. However, the MPI implementation > is not required to check all user provided parameters; if a user > passes invalid parameter values to any routine the behavior of > the implementation is undefined. > > All return codes with the prefix MPI_T_ are error codes. They must be > unique values and cannot overlap with any other error codes or 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. In particular, they must satisfy: > > 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. > > Rationale: > All MPI tool information interface functions must return error > classes, > because applications cannot portably call MPI_ERROR_CLASS before > MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to an error > class. End of rationale. > > > > > > > 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. > > ------------------------------ > > > > Best regards > > Rolf > > > > ----- Original Message ----- > >> From: "Bronis R. de Supinski" <bronis(a)llnl.gov> > >> To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > >> Cc: "Martin Schulz" <schulzm(a)llnl.gov>, "Kathryn Mohror" > >> <mohror1(a)llnl.gov>, "Dave Goodell" <goodell(a)mcs.anl.gov>, > >> "Adam T. Moody" <moody20(a)llnl.gov>, "Main MPI Forum mailing list" > >> <mpi-forum(a)lists.mpi-forum.org> > >> Sent: Wednesday, July 25, 2012 12:07:55 PM > >> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE > >> Rolf: > >> > >> Hmm. Aoparently you did not follow. I do not agree to > >> Martin's change to my suggested wording. I think > >> stating that they return error classes is confusing > >> and not consistent with Section 8.4. That section states: > >> > >> ------------------ > >> > >> The error codes returned by MPI are left entirely to the > >> implementation > >> (with the exception of MPI_SUCCESS). This is done to allow an > >> implementation > >> to provide as much information as possible in the error code (for > >> use > >> with > >> MPI_ERROR_STRING). > >> > >> To make it possible for an application to interpret an error code, > >> the > >> routine MPI_ERROR_CLASS converts any error code into one of a small > >> set of > >> standard error codes, called error classes. Valid error classes are > >> shown > >> in Table 8.1 and Table 8.2. > >> > >> ------------------ > >> > >> This passage clearly states that all MPI routines return error > >> codes > >> (as > >> is consistent with correct design). To obtain an error code, one > >> MUST > >> use MPI_ERROR_CLASS. Martin's change incorrectly makes MPI_T > >> functions > >> return error classes. My wording instead has them return error > >> codes, > >> consistent with existing practice. My wording merely states that > >> they > >> are ALSO error classes. > >> > >> As stated previously, I object to Martin's incorrect > >> simplification, > >> which was the cause of the confusion that generated significant > >> discussion on this topic. We should not codify it. > >> > >> Bronis > >> > >> > >> > >> > >> On Wed, 25 Jul 2012, Rolf Rabenseifner wrote: > >> > >>> Martin, Kathryn, Bronis, Dave, Adam, and all, > >>> > >>> I try to sum up the current proposed text change. > >>> I hope I caught all your proposed text changes. > >>> > >>> If I understand correctly, > >>> then there is no further objection and the whole > >>> tools chapter committee is in favor to do this change. > >>> > >>> My review: I is now fully consistent with the existing > >>> MPI error handling and fulfills all needs of > >>> the MPI_T_ routines. > >>> > >>> Please give your okay as soon as possible. > >>> > >>> As soon as I get the final okay from you all, > >>> I'll execute the change in one consistent svn step in tools and > >>> appLang. > >>> > >>> ------------------------- > >>> | Changed and new text is marked with a bar. > >>> ------------------------- > >>> 1) Sect 14.3.9 "Return Codes for the MPI tool information > >>> interface" > >>> reads > >>> > >>> All functions defined as part of the MPI tool information > >>> interface > >>> return an integer return code (see Table 14.5) to indicate > >>> whether > >>> the function was completed successfully or was aborted. In the > >>> latter case the return code indicates the reason for not > >>> completing > >>> the routine. None of the return codes returned by an routine > >>> impact the execution of the MPI process and do not invoke MPI > >>> error > >>> handlers. The execution of the MPI process continues as if the > >>> call would have completed. However, the MPI implementation > >>> is not required to check all user provided parameters; if a user > >>> passes invalid parameter values to any routine the behavior of > >>> the implementation is undefined. > >>> > >>> 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 functions defined as part of the MPI tool information > >>> interface > >>> | return an MPI error class, as defined in Table 14.5, to > >>> | indicate > >>> | whether > >>> the function was completed successfully or was aborted. In the > >>> latter case the error class indicates the reason for not > >>> completing > >>> the routine. None of the error classes returned by an routine > >>> impact the execution of the MPI process and do not invoke MPI > >>> error > >>> handlers. The execution of the MPI process continues as if the > >>> call would have completed. However, the MPI implementation > >>> is not required to check all user provided parameters; if a user > >>> passes invalid parameter values to any routine the behavior of > >>> the implementation is undefined. > >>> > >>> | All MPI error classes with the prefix MPI\_T\_ must be unique > >>> | values > >>> | and cannot overlap with any other error codes or error > >>> | classes returned by the MPI implementation and must follow > >>> | the same rules and restrictions laid out in Chapter 8.4. In > >>> | particular, > >>> | they must satisfy: > >>> | > >>> | 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. > >>> | > >>> | Rationale: > >>> | All MPI tool information interface functions must return error > >>> | classes, > >>> | because applications cannot portably call MPI_ERROR_CLASS > >>> | before > >>> | MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to > >>> | an > >>> | error > >>> | class. End of rationale. > >>> > >>> 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. > >>> -------------------- > >>> > >>> Best regards > >>> Rolf > >>> > >>> ----- Original Message ----- > >>>> From: "Bronis R. de Supinski" <bronis(a)llnl.gov> > >>>> To: "Martin Schulz" <schulzm(a)llnl.gov> > >>>> Cc: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > >>>> Sent: Wednesday, July 25, 2012 7:15:59 AM > >>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and > >>>> MPI_ERR_LASTCODE > >>>> Martin: > >>>> > >>>> Because using the error classes wording is what caused > >>>> the original confusion. Further, your wording precludes > >>>> ever allowing an implementation to extend the return codes. > >>>> > >>>> Frankly, your opinion is that calling them error classes > >>>> is less confusing but we have already seen that experts > >>>> are confused by that. > >>>> > >>>> As to your second suggestion, it would be simpler if you > >>>> showed just the change to make it clearer that it is just > >>>> a ticket 0 change instead of asking people to wade through > >>>> the comparison of two lengthy passages. > >>>> > >>>> Bronis > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> On Tue, 24 Jul 2012, Schulz, Martin wrote: > >>>> > >>>>> Hi Bronis, > >>>>> > >>>>> On Jul 25, 2012, at 12:19 AM, Bronis R. de Supinski wrote: > >>>>> > >>>>>> > >>>>>> Martin: > >>>>>> > >>>>>> You are incorrect. The text in 8.4 explicitly states that > >>>>>> all error classes are error codes. My text was straightforward > >>>>> > >>>>> Yes, that's what I said as well. Error classes are a subset of > >>>>> error > >>>>> codes. > >>>>> > >>>>>> and not as long and awkward as your suggestion that attempts > >>>>> > >>>>> In the first suggestion I just replaced one word and then cut > >>>>> duplicate text (the new version is shorter) - your text said > >>>>> that > >>>>> all return codes are error codes and I still think this is not > >>>>> quite > >>>>> correct or at least ambiguous. We are defining their values with > >>>>> constants in the Table, something that we can't do for error > >>>>> codes > >>>>> that are not classes. Hence, I just suggested to replace "All > >>>>> return > >>>>> codes with the prefix MPI_T_ are error codes." with "All return > >>>>> codes with the prefix MPI_T_ are error classes.". Otherwise we > >>>>> are > >>>>> first saying that return codes can be (arbitrary) error codes, > >>>>> but > >>>>> then we state they should behave as classes. Why not say they > >>>>> are > >>>>> classes from the beginning? > >>>>> > >>>>>> to make a non-existent distinction. I vote for Adam's suggested > >>>>>> rationale that extended my wording. > >>>>> > >>>>> In the second suggestion, I was actually trying to get rid of > >>>>> the > >>>>> term MPI_T return codes, since this has caused the confusion. I > >>>>> think this is cleaner (and the text overall is actually shorter > >>>>> - > >>>>> I > >>>>> just quoted the whole subsection 14.3.9 for context). The text > >>>>> is > >>>>> itself is virtually unchanged from the approved ticket. However, > >>>>> I > >>>>> have said that I am fine with either version. > >>>>> > >>>>> Martin > >>>>> > >>>>> > >>>>>> > >>>>>> Bronis > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Tue, 24 Jul 2012, Schulz, Martin wrote: > >>>>>> > >>>>>>> I agree with Adam's rational - that is a good addition. > >>>>>>> > >>>>>>> However, I don't think the last proposal (which was, I believe > >>>>>>> in > >>>>>>> Bronis's email) > >>>>>>> > >>>>>>>> All return codes with the prefix MPI_T_ are error codes. > >>>>>>>> They > >>>>>>>> must be > >>>>>>>> unique values and cannot overlap with any other error codes > >>>>>>>> or > >>>>>>>> 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. In particular, they must > >>>>>>>> satisfy: > >>>>>>>> > >>>>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. > >>>>>>> > >>>>>>> > >>>>>>> is consistent with 8.4 (although that chapter is not quite > >>>>>>> consistent in itself, but that's a different issue). If we > >>>>>>> want > >>>>>>> to > >>>>>>> fully embed the MPI_T return codes into the MPI error > >>>>>>> class/code > >>>>>>> terminology (which I agree with), then MPI_T return codes are > >>>>>>> not > >>>>>>> error codes, but classes, since we are defining their values. > >>>>>>> Codes that are not classes are left to the implementation. 8.4 > >>>>>>> also states that MPI routines can return classes and that > >>>>>>> classes > >>>>>>> are a subset of codes. Hence, I think the following is > >>>>>>> correct: > >>>>>>> > >>>>>>>> All return codes with the prefix MPI_T_ are error classes. > >>>>>>>> They > >>>>>>>> must be > >>>>>>>> unique values and cannot overlap with any other error codes > >>>>>>>> or > >>>>>>>> error > >>>>>>>> classes returned by the MPI implementation. Further, they > >>>>>>>> shall > >>>>>>>> follow > >>>>>>>> the same rules and restrictions as defined in Chapter 8.4. In > >>>>>>>> particular, > >>>>>>>> they must satisfy: > >>>>>>>> > >>>>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. > >>>>>>> > >>>>>>> However, this is starting to get awkward and repetitive. > >>>>>>> Hence, > >>>>>>> we > >>>>>>> may want to rewrite 14.3.9 as follows: > >>>>>>> > >>>>>>> Old text (currently in approved for 14.3.9): > >>>>>>> > >>>>>>>> All functions defined as part of the MPI tool information > >>>>>>>> interface > >>>>>>>> return an integer return code (see Table 14.5) to indicate > >>>>>>>> whether > >>>>>>>> the function was completed successfully or was aborted. In > >>>>>>>> the > >>>>>>>> latter case the return code indicates the reason for not > >>>>>>>> completing > >>>>>>>> the routine. None of the return codes returned by an routine > >>>>>>>> impact the execution of the MPI process and do not invoke MPI > >>>>>>>> error > >>>>>>>> handlers. The execution of the MPI process continues as if > >>>>>>>> the > >>>>>>>> call would have completed. However, the \MPI/ implementation > >>>>>>>> is not required to check all user provided parameters; if a > >>>>>>>> user > >>>>>>>> passes invalid parameter values to any routine the behavior > >>>>>>>> of > >>>>>>>> the implementation is undefined. > >>>>>>>> > >>>>>>>> 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. > >>>>>>> > >>>>>>> New suggested text: > >>>>>>> > >>>>>>>> All functions defined as part of the MPI tool information > >>>>>>>> interface > >>>>>>>> return an MPI error class, as defined in Table 14.5, to > >>>>>>>> indicate > >>>>>>>> whether > >>>>>>>> the function was completed successfully or was aborted. In > >>>>>>>> the > >>>>>>>> latter case the error class indicates the reason for not > >>>>>>>> completing > >>>>>>>> the routine. None of the error classes returned by an routine > >>>>>>>> impact the execution of the MPI process and do not invoke MPI > >>>>>>>> error > >>>>>>>> handlers. The execution of the MPI process continues as if > >>>>>>>> the > >>>>>>>> call would have completed. However, the MPI implementation > >>>>>>>> is not required to check all user provided parameters; if a > >>>>>>>> user > >>>>>>>> passes invalid parameter values to any routine the behavior > >>>>>>>> of > >>>>>>>> the implementation is undefined. > >>>>>>>> > >>>>>>>> All MPI error classes with the prefix MPI\_T\_ must be unique > >>>>>>>> values > >>>>>>>> and cannot overlap with any other error codes or error > >>>>>>>> classes returned by the MPI implementation and must follow > >>>>>>>> the same rules and restrictions laid out in Chapter 8.4. In > >>>>>>>> particular, > >>>>>>>> they must satisfy: > >>>>>>>> > >>>>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. > >>>>>>>> > >>>>>>>> Rationale: > >>>>>>>> All MPI tool information interface functions must return > >>>>>>>> error > >>>>>>>> classes, > >>>>>>>> because applications cannot portably call MPI_ERROR_CLASS > >>>>>>>> before > >>>>>>>> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to > >>>>>>>> an > >>>>>>>> error > >>>>>>>> class. > >>>>>>> > >>>>>>> I can go either way (just making the minor change mention > >>>>>>> above > >>>>>>> and adding Adam's rational) or with the larger adjustment. I > >>>>>>> believe those two are semantically equivalent. > >>>>>>> > >>>>>>> Martin > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Jul 24, 2012, at 2:31 PM, Mohror, Kathryn wrote: > >>>>>>> > >>>>>>>> I am in favor of adding Adam's rationale. > >>>>>>>> > >>>>>>>>> Rationale: > >>>>>>>>> All MPI tool information interface functions must return > >>>>>>>>> error > >>>>>>>>> classes, > >>>>>>>>> because applications cannot portably call MPI_ERROR_CLASS > >>>>>>>>> before > >>>>>>>>> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code > >>>>>>>>> to > >>>>>>>>> an > >>>>>>>>> error > >>>>>>>>> class. > >>>>>>>> > >>>>>>>> Kathryn > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: mpi-forum-bounces(a)lists.mpi-forum.org > >>>>>>>>> [mailto:mpi-forum- > >>>>>>>>> bounces(a)lists.mpi-forum.org] On Behalf Of Adam T. Moody > >>>>>>>>> Sent: Tuesday, July 24, 2012 11:23 AM > >>>>>>>>> To: Main MPI Forum mailing list > >>>>>>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and > >>>>>>>>> MPI_ERR_LASTCODE > >>>>>>>>> > >>>>>>>>> I think we are all converging, but there is one point that I > >>>>>>>>> wanted to > >>>>>>>>> bring up: > >>>>>>>>> > >>>>>>>>> Can one call ERROR_CLASS/STRING before MPI_INIT? > >>>>>>>>> > >>>>>>>>> The current standard doesn't allow this, since > >>>>>>>>> ERROR_CLASS/STRING are > >>>>>>>>> not in the list of functions that one can call before INIT. > >>>>>>>>> However, > >>>>>>>>> Rolf pointed out that the previous standard didn't need to > >>>>>>>>> allow > >>>>>>>>> this, > >>>>>>>>> because there is no way to replace the default error handler > >>>>>>>>> (which is > >>>>>>>>> that errors are fatal) until after INIT. Thus, if one of > >>>>>>>>> these > >>>>>>>>> functions throws an error before INIT, it triggers the > >>>>>>>>> ERRORS_ARE_FATAL > >>>>>>>>> handler and never returns. > >>>>>>>>> > >>>>>>>>> However, since MPI_T_ errors do not kick off the error > >>>>>>>>> handlers, > >>>>>>>>> now we > >>>>>>>>> have the case where error codes can be returned before > >>>>>>>>> MPI_INIT. > >>>>>>>>> However, again, since ERROR_CLASS/STRING are not in the list > >>>>>>>>> of > >>>>>>>>> functions that one can call before INIT, it is implied that > >>>>>>>>> users cannot > >>>>>>>>> call these functions until after MPI_INIT. It would be nice > >>>>>>>>> to > >>>>>>>>> add a > >>>>>>>>> rationale statement along these lines to the latest proposed > >>>>>>>>> text, e.g.: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> All return codes with the prefix MPI_T_ are error codes. > >>>>>>>>> They > >>>>>>>>> must be > >>>>>>>>> unique values and cannot overlap with any other error codes > >>>>>>>>> or > >>>>>>>>> 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. In particular, they must > >>>>>>>>> satisfy: > >>>>>>>>> > >>>>>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. > >>>>>>>>> > >>>>>>>>> Rationale: > >>>>>>>>> All MPI tool information interface functions must return > >>>>>>>>> error > >>>>>>>>> classes, > >>>>>>>>> because applications cannot portably call MPI_ERROR_CLASS > >>>>>>>>> before > >>>>>>>>> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code > >>>>>>>>> to > >>>>>>>>> an > >>>>>>>>> error > >>>>>>>>> class. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Note the above is more restrictive than it needs to be, > >>>>>>>>> since > >>>>>>>>> it > >>>>>>>>> seems > >>>>>>>>> that we could allow MPI_T to return arbitrary error codes > >>>>>>>>> *after* > >>>>>>>>> MPI_INIT. However, it seems we're already imposing the > >>>>>>>>> restriction that > >>>>>>>>> they always return error classes. > >>>>>>>>> -Adam > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Mohror, Kathryn wrote: > >>>>>>>>> > >>>>>>>>>> I see the meaning of classes and codes now. I was a bit > >>>>>>>>>> confused by the > >>>>>>>>> wording in 8.4. I still think it's a bit weird that > >>>>>>>>> everywhere > >>>>>>>>> else in the standard, > >>>>>>>>> the codes returned need to be converted to classes to get a > >>>>>>>>> portable > >>>>>>>>> understanding of the error, but in MPI_T we will return > >>>>>>>>> classes, > >>>>>>>>> so the meaning > >>>>>>>>> is already known without conversion. > >>>>>>>>>> > >>>>>>>>>> However, that said, Bronis' wording of Rolf's suggested > >>>>>>>>>> change > >>>>>>>>>> seems to > >>>>>>>>> make that distinction clearer. I am okay with Bronis' text: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> All return codes with the prefix MPI_T_ are error codes. > >>>>>>>>>>> They > >>>>>>>>>>> must be > >>>>>>>>>>> unique values and cannot overlap with any other error > >>>>>>>>>>> codes > >>>>>>>>>>> or 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. In particular, they must > >>>>>>>>>>> satisfy: > >>>>>>>>>>> > >>>>>>>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Kathryn > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: mpi-forum-bounces(a)lists.mpi-forum.org > >>>>>>>>>>> [mailto:mpi-forum- > >>>>>>>>>>> bounces(a)lists.mpi-forum.org] On Behalf Of William Gropp > >>>>>>>>>>> Sent: Tuesday, July 24, 2012 8:31 AM > >>>>>>>>>>> To: Main MPI Forum mailing list > >>>>>>>>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and > >>>>>>>>>>> MPI_ERR_LASTCODE > >>>>>>>>>>> > >>>>>>>>>>> MPI error codes, combined with MPI_Error_string, permit an > >>>>>>>>>>> MPI > >>>>>>>>>>> implementation to return a instance-specific and detailed > >>>>>>>>>>> error message. > >>>>>>>>> Error > >>>>>>>>>>> classes, like Unix error codes, have only slightly more > >>>>>>>>>>> information that > >>>>>>>>>>> "something went wrong". > >>>>>>>>>>> > >>>>>>>>>>> Because MPI error classes are error codes, its possible to > >>>>>>>>>>> return the error > >>>>>>>>> class; > >>>>>>>>>>> this can be used before Init and after Finalize now. But > >>>>>>>>>>> between Init and > >>>>>>>>>>> Finalize, codes permit but do not require an > >>>>>>>>>>> implementation > >>>>>>>>>>> to > >>>>>>>>>>> return more > >>>>>>>>>>> helpful information. I see no reason to require the MPI_T > >>>>>>>>>>> interface to be > >>>>>>>>> less > >>>>>>>>>>> user-friendly than the rest of the MPI interface. However, > >>>>>>>>>>> leaving this for > >>>>>>>>> 3.1 > >>>>>>>>>>> might make sense. > >>>>>>>>>>> > >>>>>>>>>>> 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 23, 2012, at 3:05 PM, Mohror, Kathryn wrote: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> I have some concerns over this. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> 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. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> If we are going to treat MPI_T error codes the same way > >>>>>>>>>>>> they > >>>>>>>>>>>> are in the rest > >>>>>>>>> of > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> the standard, does it make sense to say that "only classes > >>>>>>>>>>> are > >>>>>>>>>>> returned" by > >>>>>>>>>>> MPI_T calls? I think that MPI calls return codes and the > >>>>>>>>>>> codes > >>>>>>>>>>> are translated > >>>>>>>>> to > >>>>>>>>>>> classes by the MPI_ERROR_CLASS function. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> If MPI_ERROR_CLASS and MPI_ERROR_STRING are not available > >>>>>>>>>>>> before > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> MPI_Init, then this may be a hardship on tools. I imagine > >>>>>>>>>>> many > >>>>>>>>>>> tools doing a > >>>>>>>>>>> significant amount of set up before MPI_Init to avoid > >>>>>>>>>>> overhead. However, if > >>>>>>>>>>> there is no information about what the return codes mean, > >>>>>>>>>>> then > >>>>>>>>>>> tools may > >>>>>>>>> have > >>>>>>>>>>> difficulty. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> Possibly it makes more sense to treat MPI_T return values > >>>>>>>>>>>> differently than > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> MPI calls? Could the MPI_T return values be a set of > >>>>>>>>>>> defined > >>>>>>>>>>> codes instead? > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> Does anyone have different insight on error codes vs > >>>>>>>>>>>> classes? > >>>>>>>>>>>> > >>>>>>>>>>>> Kathryn > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>> From: mpi-forum-bounces(a)lists.mpi-forum.org > >>>>>>>>>>>>> [mailto:mpi-forum- > >>>>>>>>>>>>> bounces(a)lists.mpi-forum.org] On Behalf Of Bronis R. de > >>>>>>>>>>>>> Supinski > >>>>>>>>>>>>> Sent: Monday, July 23, 2012 10:37 AM > >>>>>>>>>>>>> To: Main MPI Forum mailing list > >>>>>>>>>>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and > >>>>>>>>>>>>> MPI_ERR_LASTCODE > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> OK by me. > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Mon, 23 Jul 2012, Dave Goodell wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> I agree, we should make these changes. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -Dave > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Jul 23, 2012, at 8:55 AM CDT, Schulz, Martin wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Hi Rolf, all, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I agree with your suggestions and I am in favor of > >>>>>>>>>>>>>>> making > >>>>>>>>>>>>>>> these > >>>>>>>>> changes. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>> Bronis (as well as Kathryn and Dave as the remaining > >>>>>>>>>>>>> members > >>>>>>>>>>>>> in the > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> chapter > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> committee for tools) should concur, though. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>>> Anybody else have any concerns over these changes? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> As for the callability of the error functions, I also > >>>>>>>>>>>>>>> agree - let's target > >>>>>>>>> those > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>> in > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> 3.1. This change is not vital and bit too big for final > >>>>>>>>>>>>> edits. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Martin > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Jul 23, 2012, at 4:00 AM, Rolf Rabenseifner wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> 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) > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>> ____________________________________________________________________ > >>>>>>>>> __ > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> __ > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>>> 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 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>> 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 > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> 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 > >>>>>>> > >>>>>>> ________________________________________________________________________ > >>>>>>> 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 > >>>>>>> > >>>>> > >>>>> ________________________________________________________________________ > >>>>> 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) > >>> > > > > -- > > 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) > > -- 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 25 Jul '12

25 Jul '12

Rolf: Um, not quite. The first paragraph should read "error codes", not "error classes". The routines return error codes, all of which happen to be error classes. I have modified below. Bronis On Wed, 25 Jul 2012, Rolf Rabenseifner wrote: > Bronis, Martin, Adam, Kathryn, Dave, and all, > > Okay, now I understand - I thought Martin's arguments were okay > for shortening the text - but the original long form is more > consistent. > > Can we therefore agree on the text below. > It is the text from Bronis plus Adams rationale plus the other > changes from the original mail. > > I would like to have enough okays. > > ------------------------------ > | Changed and new text is marked with a bar. > ------------------------- > 1) Sect 14.3.9 "Return Codes for the MPI tool information interface" > reads > > All functions defined as part of the MPI tool information interface > return an integer return code (see Table 14.5) to indicate whether > the function was completed successfully or was aborted. In the > latter case the return code indicates the reason for not completing > the routine. None of the return codes returned by an routine > impact the execution of the MPI process and do not invoke MPI error > handlers. The execution of the MPI process continues as if the > call would have completed. However, the MPI implementation > is not required to check all user provided parameters; if a user > passes invalid parameter values to any routine the behavior of > the implementation is undefined. > > 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 functions defined as part of the MPI tool information interface return an integer error code (see Table 14.5) to indicate whether the function was completed successfully or was aborted. In the latter case the error code indicates the reason for not completing the routine. None of the error codes returned by an routine impact the execution of the MPI process and do not invoke MPI error handlers. The execution of the MPI process continues as if the call would have completed. However, the MPI implementation is not required to check all user provided parameters; if a user passes invalid parameter values to any routine the behavior of the implementation is undefined. All return codes with the prefix MPI_T_ are error codes. They must be unique values and cannot overlap with any other error codes or 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. In particular, they must satisfy: 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. Rationale: All MPI tool information interface functions must return error classes, because applications cannot portably call MPI_ERROR_CLASS before MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to an error class. End of rationale. > > 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. > ------------------------------ > > Best regards > Rolf > > ----- Original Message ----- >> From: "Bronis R. de Supinski" <bronis(a)llnl.gov> >> To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> >> Cc: "Martin Schulz" <schulzm(a)llnl.gov>, "Kathryn Mohror" <mohror1(a)llnl.gov>, "Dave Goodell" <goodell(a)mcs.anl.gov>, >> "Adam T. Moody" <moody20(a)llnl.gov>, "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >> Sent: Wednesday, July 25, 2012 12:07:55 PM >> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE >> Rolf: >> >> Hmm. Aoparently you did not follow. I do not agree to >> Martin's change to my suggested wording. I think >> stating that they return error classes is confusing >> and not consistent with Section 8.4. That section states: >> >> ------------------ >> >> The error codes returned by MPI are left entirely to the >> implementation >> (with the exception of MPI_SUCCESS). This is done to allow an >> implementation >> to provide as much information as possible in the error code (for use >> with >> MPI_ERROR_STRING). >> >> To make it possible for an application to interpret an error code, the >> routine MPI_ERROR_CLASS converts any error code into one of a small >> set of >> standard error codes, called error classes. Valid error classes are >> shown >> in Table 8.1 and Table 8.2. >> >> ------------------ >> >> This passage clearly states that all MPI routines return error codes >> (as >> is consistent with correct design). To obtain an error code, one MUST >> use MPI_ERROR_CLASS. Martin's change incorrectly makes MPI_T functions >> return error classes. My wording instead has them return error codes, >> consistent with existing practice. My wording merely states that they >> are ALSO error classes. >> >> As stated previously, I object to Martin's incorrect simplification, >> which was the cause of the confusion that generated significant >> discussion on this topic. We should not codify it. >> >> Bronis >> >> >> >> >> On Wed, 25 Jul 2012, Rolf Rabenseifner wrote: >> >>> Martin, Kathryn, Bronis, Dave, Adam, and all, >>> >>> I try to sum up the current proposed text change. >>> I hope I caught all your proposed text changes. >>> >>> If I understand correctly, >>> then there is no further objection and the whole >>> tools chapter committee is in favor to do this change. >>> >>> My review: I is now fully consistent with the existing >>> MPI error handling and fulfills all needs of >>> the MPI_T_ routines. >>> >>> Please give your okay as soon as possible. >>> >>> As soon as I get the final okay from you all, >>> I'll execute the change in one consistent svn step in tools and >>> appLang. >>> >>> ------------------------- >>> | Changed and new text is marked with a bar. >>> ------------------------- >>> 1) Sect 14.3.9 "Return Codes for the MPI tool information interface" >>> reads >>> >>> All functions defined as part of the MPI tool information >>> interface >>> return an integer return code (see Table 14.5) to indicate whether >>> the function was completed successfully or was aborted. In the >>> latter case the return code indicates the reason for not >>> completing >>> the routine. None of the return codes returned by an routine >>> impact the execution of the MPI process and do not invoke MPI >>> error >>> handlers. The execution of the MPI process continues as if the >>> call would have completed. However, the MPI implementation >>> is not required to check all user provided parameters; if a user >>> passes invalid parameter values to any routine the behavior of >>> the implementation is undefined. >>> >>> 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 functions defined as part of the MPI tool information >>> interface >>> | return an MPI error class, as defined in Table 14.5, to indicate >>> | whether >>> the function was completed successfully or was aborted. In the >>> latter case the error class indicates the reason for not >>> completing >>> the routine. None of the error classes returned by an routine >>> impact the execution of the MPI process and do not invoke MPI >>> error >>> handlers. The execution of the MPI process continues as if the >>> call would have completed. However, the MPI implementation >>> is not required to check all user provided parameters; if a user >>> passes invalid parameter values to any routine the behavior of >>> the implementation is undefined. >>> >>> | All MPI error classes with the prefix MPI\_T\_ must be unique >>> | values >>> | and cannot overlap with any other error codes or error >>> | classes returned by the MPI implementation and must follow >>> | the same rules and restrictions laid out in Chapter 8.4. In >>> | particular, >>> | they must satisfy: >>> | >>> | 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. >>> | >>> | Rationale: >>> | All MPI tool information interface functions must return error >>> | classes, >>> | because applications cannot portably call MPI_ERROR_CLASS before >>> | MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to an >>> | error >>> | class. End of rationale. >>> >>> 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. >>> -------------------- >>> >>> Best regards >>> Rolf >>> >>> ----- Original Message ----- >>>> From: "Bronis R. de Supinski" <bronis(a)llnl.gov> >>>> To: "Martin Schulz" <schulzm(a)llnl.gov> >>>> Cc: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >>>> Sent: Wednesday, July 25, 2012 7:15:59 AM >>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE >>>> Martin: >>>> >>>> Because using the error classes wording is what caused >>>> the original confusion. Further, your wording precludes >>>> ever allowing an implementation to extend the return codes. >>>> >>>> Frankly, your opinion is that calling them error classes >>>> is less confusing but we have already seen that experts >>>> are confused by that. >>>> >>>> As to your second suggestion, it would be simpler if you >>>> showed just the change to make it clearer that it is just >>>> a ticket 0 change instead of asking people to wade through >>>> the comparison of two lengthy passages. >>>> >>>> Bronis >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Tue, 24 Jul 2012, Schulz, Martin wrote: >>>> >>>>> Hi Bronis, >>>>> >>>>> On Jul 25, 2012, at 12:19 AM, Bronis R. de Supinski wrote: >>>>> >>>>>> >>>>>> Martin: >>>>>> >>>>>> You are incorrect. The text in 8.4 explicitly states that >>>>>> all error classes are error codes. My text was straightforward >>>>> >>>>> Yes, that's what I said as well. Error classes are a subset of >>>>> error >>>>> codes. >>>>> >>>>>> and not as long and awkward as your suggestion that attempts >>>>> >>>>> In the first suggestion I just replaced one word and then cut >>>>> duplicate text (the new version is shorter) - your text said that >>>>> all return codes are error codes and I still think this is not >>>>> quite >>>>> correct or at least ambiguous. We are defining their values with >>>>> constants in the Table, something that we can't do for error codes >>>>> that are not classes. Hence, I just suggested to replace "All >>>>> return >>>>> codes with the prefix MPI_T_ are error codes." with "All return >>>>> codes with the prefix MPI_T_ are error classes.". Otherwise we are >>>>> first saying that return codes can be (arbitrary) error codes, but >>>>> then we state they should behave as classes. Why not say they are >>>>> classes from the beginning? >>>>> >>>>>> to make a non-existent distinction. I vote for Adam's suggested >>>>>> rationale that extended my wording. >>>>> >>>>> In the second suggestion, I was actually trying to get rid of the >>>>> term MPI_T return codes, since this has caused the confusion. I >>>>> think this is cleaner (and the text overall is actually shorter - >>>>> I >>>>> just quoted the whole subsection 14.3.9 for context). The text is >>>>> itself is virtually unchanged from the approved ticket. However, I >>>>> have said that I am fine with either version. >>>>> >>>>> Martin >>>>> >>>>> >>>>>> >>>>>> Bronis >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, 24 Jul 2012, Schulz, Martin wrote: >>>>>> >>>>>>> I agree with Adam's rational - that is a good addition. >>>>>>> >>>>>>> However, I don't think the last proposal (which was, I believe >>>>>>> in >>>>>>> Bronis's email) >>>>>>> >>>>>>>> All return codes with the prefix MPI_T_ are error codes. They >>>>>>>> must be >>>>>>>> unique values and cannot overlap with any other error codes >>>>>>>> or >>>>>>>> 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. In particular, they must >>>>>>>> satisfy: >>>>>>>> >>>>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. >>>>>>> >>>>>>> >>>>>>> is consistent with 8.4 (although that chapter is not quite >>>>>>> consistent in itself, but that's a different issue). If we want >>>>>>> to >>>>>>> fully embed the MPI_T return codes into the MPI error class/code >>>>>>> terminology (which I agree with), then MPI_T return codes are >>>>>>> not >>>>>>> error codes, but classes, since we are defining their values. >>>>>>> Codes that are not classes are left to the implementation. 8.4 >>>>>>> also states that MPI routines can return classes and that >>>>>>> classes >>>>>>> are a subset of codes. Hence, I think the following is correct: >>>>>>> >>>>>>>> All return codes with the prefix MPI_T_ are error classes. They >>>>>>>> must be >>>>>>>> unique values and cannot overlap with any other error codes or >>>>>>>> error >>>>>>>> classes returned by the MPI implementation. Further, they shall >>>>>>>> follow >>>>>>>> the same rules and restrictions as defined in Chapter 8.4. In >>>>>>>> particular, >>>>>>>> they must satisfy: >>>>>>>> >>>>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. >>>>>>> >>>>>>> However, this is starting to get awkward and repetitive. Hence, >>>>>>> we >>>>>>> may want to rewrite 14.3.9 as follows: >>>>>>> >>>>>>> Old text (currently in approved for 14.3.9): >>>>>>> >>>>>>>> All functions defined as part of the MPI tool information >>>>>>>> interface >>>>>>>> return an integer return code (see Table 14.5) to indicate >>>>>>>> whether >>>>>>>> the function was completed successfully or was aborted. In the >>>>>>>> latter case the return code indicates the reason for not >>>>>>>> completing >>>>>>>> the routine. None of the return codes returned by an routine >>>>>>>> impact the execution of the MPI process and do not invoke MPI >>>>>>>> error >>>>>>>> handlers. The execution of the MPI process continues as if the >>>>>>>> call would have completed. However, the \MPI/ implementation >>>>>>>> is not required to check all user provided parameters; if a >>>>>>>> user >>>>>>>> passes invalid parameter values to any routine the behavior of >>>>>>>> the implementation is undefined. >>>>>>>> >>>>>>>> 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. >>>>>>> >>>>>>> New suggested text: >>>>>>> >>>>>>>> All functions defined as part of the MPI tool information >>>>>>>> interface >>>>>>>> return an MPI error class, as defined in Table 14.5, to >>>>>>>> indicate >>>>>>>> whether >>>>>>>> the function was completed successfully or was aborted. In the >>>>>>>> latter case the error class indicates the reason for not >>>>>>>> completing >>>>>>>> the routine. None of the error classes returned by an routine >>>>>>>> impact the execution of the MPI process and do not invoke MPI >>>>>>>> error >>>>>>>> handlers. The execution of the MPI process continues as if the >>>>>>>> call would have completed. However, the MPI implementation >>>>>>>> is not required to check all user provided parameters; if a >>>>>>>> user >>>>>>>> passes invalid parameter values to any routine the behavior of >>>>>>>> the implementation is undefined. >>>>>>>> >>>>>>>> All MPI error classes with the prefix MPI\_T\_ must be unique >>>>>>>> values >>>>>>>> and cannot overlap with any other error codes or error >>>>>>>> classes returned by the MPI implementation and must follow >>>>>>>> the same rules and restrictions laid out in Chapter 8.4. In >>>>>>>> particular, >>>>>>>> they must satisfy: >>>>>>>> >>>>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. >>>>>>>> >>>>>>>> Rationale: >>>>>>>> All MPI tool information interface functions must return error >>>>>>>> classes, >>>>>>>> because applications cannot portably call MPI_ERROR_CLASS >>>>>>>> before >>>>>>>> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to >>>>>>>> an >>>>>>>> error >>>>>>>> class. >>>>>>> >>>>>>> I can go either way (just making the minor change mention above >>>>>>> and adding Adam's rational) or with the larger adjustment. I >>>>>>> believe those two are semantically equivalent. >>>>>>> >>>>>>> Martin >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Jul 24, 2012, at 2:31 PM, Mohror, Kathryn wrote: >>>>>>> >>>>>>>> I am in favor of adding Adam's rationale. >>>>>>>> >>>>>>>>> Rationale: >>>>>>>>> All MPI tool information interface functions must return error >>>>>>>>> classes, >>>>>>>>> because applications cannot portably call MPI_ERROR_CLASS >>>>>>>>> before >>>>>>>>> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to >>>>>>>>> an >>>>>>>>> error >>>>>>>>> class. >>>>>>>> >>>>>>>> Kathryn >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:mpi-forum- >>>>>>>>> bounces(a)lists.mpi-forum.org] On Behalf Of Adam T. Moody >>>>>>>>> Sent: Tuesday, July 24, 2012 11:23 AM >>>>>>>>> To: Main MPI Forum mailing list >>>>>>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and >>>>>>>>> MPI_ERR_LASTCODE >>>>>>>>> >>>>>>>>> I think we are all converging, but there is one point that I >>>>>>>>> wanted to >>>>>>>>> bring up: >>>>>>>>> >>>>>>>>> Can one call ERROR_CLASS/STRING before MPI_INIT? >>>>>>>>> >>>>>>>>> The current standard doesn't allow this, since >>>>>>>>> ERROR_CLASS/STRING are >>>>>>>>> not in the list of functions that one can call before INIT. >>>>>>>>> However, >>>>>>>>> Rolf pointed out that the previous standard didn't need to >>>>>>>>> allow >>>>>>>>> this, >>>>>>>>> because there is no way to replace the default error handler >>>>>>>>> (which is >>>>>>>>> that errors are fatal) until after INIT. Thus, if one of these >>>>>>>>> functions throws an error before INIT, it triggers the >>>>>>>>> ERRORS_ARE_FATAL >>>>>>>>> handler and never returns. >>>>>>>>> >>>>>>>>> However, since MPI_T_ errors do not kick off the error >>>>>>>>> handlers, >>>>>>>>> now we >>>>>>>>> have the case where error codes can be returned before >>>>>>>>> MPI_INIT. >>>>>>>>> However, again, since ERROR_CLASS/STRING are not in the list >>>>>>>>> of >>>>>>>>> functions that one can call before INIT, it is implied that >>>>>>>>> users cannot >>>>>>>>> call these functions until after MPI_INIT. It would be nice to >>>>>>>>> add a >>>>>>>>> rationale statement along these lines to the latest proposed >>>>>>>>> text, e.g.: >>>>>>>>> >>>>>>>>> >>>>>>>>> All return codes with the prefix MPI_T_ are error codes. They >>>>>>>>> must be >>>>>>>>> unique values and cannot overlap with any other error codes or >>>>>>>>> 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. In particular, they must >>>>>>>>> satisfy: >>>>>>>>> >>>>>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. >>>>>>>>> >>>>>>>>> Rationale: >>>>>>>>> All MPI tool information interface functions must return error >>>>>>>>> classes, >>>>>>>>> because applications cannot portably call MPI_ERROR_CLASS >>>>>>>>> before >>>>>>>>> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to >>>>>>>>> an >>>>>>>>> error >>>>>>>>> class. >>>>>>>>> >>>>>>>>> >>>>>>>>> Note the above is more restrictive than it needs to be, since >>>>>>>>> it >>>>>>>>> seems >>>>>>>>> that we could allow MPI_T to return arbitrary error codes >>>>>>>>> *after* >>>>>>>>> MPI_INIT. However, it seems we're already imposing the >>>>>>>>> restriction that >>>>>>>>> they always return error classes. >>>>>>>>> -Adam >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Mohror, Kathryn wrote: >>>>>>>>> >>>>>>>>>> I see the meaning of classes and codes now. I was a bit >>>>>>>>>> confused by the >>>>>>>>> wording in 8.4. I still think it's a bit weird that everywhere >>>>>>>>> else in the standard, >>>>>>>>> the codes returned need to be converted to classes to get a >>>>>>>>> portable >>>>>>>>> understanding of the error, but in MPI_T we will return >>>>>>>>> classes, >>>>>>>>> so the meaning >>>>>>>>> is already known without conversion. >>>>>>>>>> >>>>>>>>>> However, that said, Bronis' wording of Rolf's suggested >>>>>>>>>> change >>>>>>>>>> seems to >>>>>>>>> make that distinction clearer. I am okay with Bronis' text: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> All return codes with the prefix MPI_T_ are error codes. >>>>>>>>>>> They >>>>>>>>>>> must be >>>>>>>>>>> unique values and cannot overlap with any other error codes >>>>>>>>>>> or 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. In particular, they must >>>>>>>>>>> satisfy: >>>>>>>>>>> >>>>>>>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Kathryn >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: mpi-forum-bounces(a)lists.mpi-forum.org >>>>>>>>>>> [mailto:mpi-forum- >>>>>>>>>>> bounces(a)lists.mpi-forum.org] On Behalf Of William Gropp >>>>>>>>>>> Sent: Tuesday, July 24, 2012 8:31 AM >>>>>>>>>>> To: Main MPI Forum mailing list >>>>>>>>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and >>>>>>>>>>> MPI_ERR_LASTCODE >>>>>>>>>>> >>>>>>>>>>> MPI error codes, combined with MPI_Error_string, permit an >>>>>>>>>>> MPI >>>>>>>>>>> implementation to return a instance-specific and detailed >>>>>>>>>>> error message. >>>>>>>>> Error >>>>>>>>>>> classes, like Unix error codes, have only slightly more >>>>>>>>>>> information that >>>>>>>>>>> "something went wrong". >>>>>>>>>>> >>>>>>>>>>> Because MPI error classes are error codes, its possible to >>>>>>>>>>> return the error >>>>>>>>> class; >>>>>>>>>>> this can be used before Init and after Finalize now. But >>>>>>>>>>> between Init and >>>>>>>>>>> Finalize, codes permit but do not require an implementation >>>>>>>>>>> to >>>>>>>>>>> return more >>>>>>>>>>> helpful information. I see no reason to require the MPI_T >>>>>>>>>>> interface to be >>>>>>>>> less >>>>>>>>>>> user-friendly than the rest of the MPI interface. However, >>>>>>>>>>> leaving this for >>>>>>>>> 3.1 >>>>>>>>>>> might make sense. >>>>>>>>>>> >>>>>>>>>>> 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 23, 2012, at 3:05 PM, Mohror, Kathryn wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I have some concerns over this. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> 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. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> If we are going to treat MPI_T error codes the same way >>>>>>>>>>>> they >>>>>>>>>>>> are in the rest >>>>>>>>> of >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> the standard, does it make sense to say that "only classes >>>>>>>>>>> are >>>>>>>>>>> returned" by >>>>>>>>>>> MPI_T calls? I think that MPI calls return codes and the >>>>>>>>>>> codes >>>>>>>>>>> are translated >>>>>>>>> to >>>>>>>>>>> classes by the MPI_ERROR_CLASS function. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> If MPI_ERROR_CLASS and MPI_ERROR_STRING are not available >>>>>>>>>>>> before >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> MPI_Init, then this may be a hardship on tools. I imagine >>>>>>>>>>> many >>>>>>>>>>> tools doing a >>>>>>>>>>> significant amount of set up before MPI_Init to avoid >>>>>>>>>>> overhead. However, if >>>>>>>>>>> there is no information about what the return codes mean, >>>>>>>>>>> then >>>>>>>>>>> tools may >>>>>>>>> have >>>>>>>>>>> difficulty. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Possibly it makes more sense to treat MPI_T return values >>>>>>>>>>>> differently than >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> MPI calls? Could the MPI_T return values be a set of defined >>>>>>>>>>> codes instead? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Does anyone have different insight on error codes vs >>>>>>>>>>>> classes? >>>>>>>>>>>> >>>>>>>>>>>> Kathryn >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: mpi-forum-bounces(a)lists.mpi-forum.org >>>>>>>>>>>>> [mailto:mpi-forum- >>>>>>>>>>>>> bounces(a)lists.mpi-forum.org] On Behalf Of Bronis R. de >>>>>>>>>>>>> Supinski >>>>>>>>>>>>> Sent: Monday, July 23, 2012 10:37 AM >>>>>>>>>>>>> To: Main MPI Forum mailing list >>>>>>>>>>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and >>>>>>>>>>>>> MPI_ERR_LASTCODE >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> OK by me. >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, 23 Jul 2012, Dave Goodell wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> I agree, we should make these changes. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Dave >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Jul 23, 2012, at 8:55 AM CDT, Schulz, Martin wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Rolf, all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I agree with your suggestions and I am in favor of >>>>>>>>>>>>>>> making >>>>>>>>>>>>>>> these >>>>>>>>> changes. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> Bronis (as well as Kathryn and Dave as the remaining >>>>>>>>>>>>> members >>>>>>>>>>>>> in the >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> chapter >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> committee for tools) should concur, though. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> Anybody else have any concerns over these changes? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As for the callability of the error functions, I also >>>>>>>>>>>>>>> agree - let's target >>>>>>>>> those >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> in >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> 3.1. This change is not vital and bit too big for final >>>>>>>>>>>>> edits. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Martin >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Jul 23, 2012, at 4:00 AM, Rolf Rabenseifner wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 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) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> ____________________________________________________________________ >>>>>>>>> __ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> __ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>> >>>>>>> ________________________________________________________________________ >>>>>>> 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 >>>>>>> >>>>> >>>>> ________________________________________________________________________ >>>>> 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) >>> > > -- > 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 25 Jul '12

25 Jul '12

Bronis, Martin, Adam, Kathryn, Dave, and all, Okay, now I understand - I thought Martin's arguments were okay for shortening the text - but the original long form is more consistent. Can we therefore agree on the text below. It is the text from Bronis plus Adams rationale plus the other changes from the original mail. I would like to have enough okays. ------------------------------ | Changed and new text is marked with a bar. ------------------------- 1) Sect 14.3.9 "Return Codes for the MPI tool information interface" reads All functions defined as part of the MPI tool information interface return an integer return code (see Table 14.5) to indicate whether the function was completed successfully or was aborted. In the latter case the return code indicates the reason for not completing the routine. None of the return codes returned by an routine impact the execution of the MPI process and do not invoke MPI error handlers. The execution of the MPI process continues as if the call would have completed. However, the MPI implementation is not required to check all user provided parameters; if a user passes invalid parameter values to any routine the behavior of the implementation is undefined. 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 functions defined as part of the MPI tool information interface return an integer return code (see Table 14.5) to indicate whether the function was completed successfully or was aborted. In the latter case the error class indicates the reason for not completing the routine. None of the error classes returned by an routine impact the execution of the MPI process and do not invoke MPI error handlers. The execution of the MPI process continues as if the call would have completed. However, the MPI implementation is not required to check all user provided parameters; if a user passes invalid parameter values to any routine the behavior of the implementation is undefined. | All return codes with the prefix MPI_T_ are error codes. They must be | unique values and cannot overlap with any other error codes or 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. In particular, they must satisfy: | | 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. | | Rationale: | All MPI tool information interface functions must return error classes, | because applications cannot portably call MPI_ERROR_CLASS before | MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to an error | class. End of rationale. 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. ------------------------------ Best regards Rolf ----- Original Message ----- > From: "Bronis R. de Supinski" <bronis(a)llnl.gov> > To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > Cc: "Martin Schulz" <schulzm(a)llnl.gov>, "Kathryn Mohror" <mohror1(a)llnl.gov>, "Dave Goodell" <goodell(a)mcs.anl.gov>, > "Adam T. Moody" <moody20(a)llnl.gov>, "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > Sent: Wednesday, July 25, 2012 12:07:55 PM > Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE > Rolf: > > Hmm. Aoparently you did not follow. I do not agree to > Martin's change to my suggested wording. I think > stating that they return error classes is confusing > and not consistent with Section 8.4. That section states: > > ------------------ > > The error codes returned by MPI are left entirely to the > implementation > (with the exception of MPI_SUCCESS). This is done to allow an > implementation > to provide as much information as possible in the error code (for use > with > MPI_ERROR_STRING). > > To make it possible for an application to interpret an error code, the > routine MPI_ERROR_CLASS converts any error code into one of a small > set of > standard error codes, called error classes. Valid error classes are > shown > in Table 8.1 and Table 8.2. > > ------------------ > > This passage clearly states that all MPI routines return error codes > (as > is consistent with correct design). To obtain an error code, one MUST > use MPI_ERROR_CLASS. Martin's change incorrectly makes MPI_T functions > return error classes. My wording instead has them return error codes, > consistent with existing practice. My wording merely states that they > are ALSO error classes. > > As stated previously, I object to Martin's incorrect simplification, > which was the cause of the confusion that generated significant > discussion on this topic. We should not codify it. > > Bronis > > > > > On Wed, 25 Jul 2012, Rolf Rabenseifner wrote: > > > Martin, Kathryn, Bronis, Dave, Adam, and all, > > > > I try to sum up the current proposed text change. > > I hope I caught all your proposed text changes. > > > > If I understand correctly, > > then there is no further objection and the whole > > tools chapter committee is in favor to do this change. > > > > My review: I is now fully consistent with the existing > > MPI error handling and fulfills all needs of > > the MPI_T_ routines. > > > > Please give your okay as soon as possible. > > > > As soon as I get the final okay from you all, > > I'll execute the change in one consistent svn step in tools and > > appLang. > > > > ------------------------- > > | Changed and new text is marked with a bar. > > ------------------------- > > 1) Sect 14.3.9 "Return Codes for the MPI tool information interface" > > reads > > > > All functions defined as part of the MPI tool information > > interface > > return an integer return code (see Table 14.5) to indicate whether > > the function was completed successfully or was aborted. In the > > latter case the return code indicates the reason for not > > completing > > the routine. None of the return codes returned by an routine > > impact the execution of the MPI process and do not invoke MPI > > error > > handlers. The execution of the MPI process continues as if the > > call would have completed. However, the MPI implementation > > is not required to check all user provided parameters; if a user > > passes invalid parameter values to any routine the behavior of > > the implementation is undefined. > > > > 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 functions defined as part of the MPI tool information > > interface > > | return an MPI error class, as defined in Table 14.5, to indicate > > | whether > > the function was completed successfully or was aborted. In the > > latter case the error class indicates the reason for not > > completing > > the routine. None of the error classes returned by an routine > > impact the execution of the MPI process and do not invoke MPI > > error > > handlers. The execution of the MPI process continues as if the > > call would have completed. However, the MPI implementation > > is not required to check all user provided parameters; if a user > > passes invalid parameter values to any routine the behavior of > > the implementation is undefined. > > > > | All MPI error classes with the prefix MPI\_T\_ must be unique > > | values > > | and cannot overlap with any other error codes or error > > | classes returned by the MPI implementation and must follow > > | the same rules and restrictions laid out in Chapter 8.4. In > > | particular, > > | they must satisfy: > > | > > | 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. > > | > > | Rationale: > > | All MPI tool information interface functions must return error > > | classes, > > | because applications cannot portably call MPI_ERROR_CLASS before > > | MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to an > > | error > > | class. End of rationale. > > > > 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. > > -------------------- > > > > Best regards > > Rolf > > > > ----- Original Message ----- > >> From: "Bronis R. de Supinski" <bronis(a)llnl.gov> > >> To: "Martin Schulz" <schulzm(a)llnl.gov> > >> Cc: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > >> Sent: Wednesday, July 25, 2012 7:15:59 AM > >> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE > >> Martin: > >> > >> Because using the error classes wording is what caused > >> the original confusion. Further, your wording precludes > >> ever allowing an implementation to extend the return codes. > >> > >> Frankly, your opinion is that calling them error classes > >> is less confusing but we have already seen that experts > >> are confused by that. > >> > >> As to your second suggestion, it would be simpler if you > >> showed just the change to make it clearer that it is just > >> a ticket 0 change instead of asking people to wade through > >> the comparison of two lengthy passages. > >> > >> Bronis > >> > >> > >> > >> > >> > >> > >> On Tue, 24 Jul 2012, Schulz, Martin wrote: > >> > >>> Hi Bronis, > >>> > >>> On Jul 25, 2012, at 12:19 AM, Bronis R. de Supinski wrote: > >>> > >>>> > >>>> Martin: > >>>> > >>>> You are incorrect. The text in 8.4 explicitly states that > >>>> all error classes are error codes. My text was straightforward > >>> > >>> Yes, that's what I said as well. Error classes are a subset of > >>> error > >>> codes. > >>> > >>>> and not as long and awkward as your suggestion that attempts > >>> > >>> In the first suggestion I just replaced one word and then cut > >>> duplicate text (the new version is shorter) - your text said that > >>> all return codes are error codes and I still think this is not > >>> quite > >>> correct or at least ambiguous. We are defining their values with > >>> constants in the Table, something that we can't do for error codes > >>> that are not classes. Hence, I just suggested to replace "All > >>> return > >>> codes with the prefix MPI_T_ are error codes." with "All return > >>> codes with the prefix MPI_T_ are error classes.". Otherwise we are > >>> first saying that return codes can be (arbitrary) error codes, but > >>> then we state they should behave as classes. Why not say they are > >>> classes from the beginning? > >>> > >>>> to make a non-existent distinction. I vote for Adam's suggested > >>>> rationale that extended my wording. > >>> > >>> In the second suggestion, I was actually trying to get rid of the > >>> term MPI_T return codes, since this has caused the confusion. I > >>> think this is cleaner (and the text overall is actually shorter - > >>> I > >>> just quoted the whole subsection 14.3.9 for context). The text is > >>> itself is virtually unchanged from the approved ticket. However, I > >>> have said that I am fine with either version. > >>> > >>> Martin > >>> > >>> > >>>> > >>>> Bronis > >>>> > >>>> > >>>> > >>>> > >>>> On Tue, 24 Jul 2012, Schulz, Martin wrote: > >>>> > >>>>> I agree with Adam's rational - that is a good addition. > >>>>> > >>>>> However, I don't think the last proposal (which was, I believe > >>>>> in > >>>>> Bronis's email) > >>>>> > >>>>>> All return codes with the prefix MPI_T_ are error codes. They > >>>>>> must be > >>>>>> unique values and cannot overlap with any other error codes > >>>>>> or > >>>>>> 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. In particular, they must > >>>>>> satisfy: > >>>>>> > >>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. > >>>>> > >>>>> > >>>>> is consistent with 8.4 (although that chapter is not quite > >>>>> consistent in itself, but that's a different issue). If we want > >>>>> to > >>>>> fully embed the MPI_T return codes into the MPI error class/code > >>>>> terminology (which I agree with), then MPI_T return codes are > >>>>> not > >>>>> error codes, but classes, since we are defining their values. > >>>>> Codes that are not classes are left to the implementation. 8.4 > >>>>> also states that MPI routines can return classes and that > >>>>> classes > >>>>> are a subset of codes. Hence, I think the following is correct: > >>>>> > >>>>>> All return codes with the prefix MPI_T_ are error classes. They > >>>>>> must be > >>>>>> unique values and cannot overlap with any other error codes or > >>>>>> error > >>>>>> classes returned by the MPI implementation. Further, they shall > >>>>>> follow > >>>>>> the same rules and restrictions as defined in Chapter 8.4. In > >>>>>> particular, > >>>>>> they must satisfy: > >>>>>> > >>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. > >>>>> > >>>>> However, this is starting to get awkward and repetitive. Hence, > >>>>> we > >>>>> may want to rewrite 14.3.9 as follows: > >>>>> > >>>>> Old text (currently in approved for 14.3.9): > >>>>> > >>>>>> All functions defined as part of the MPI tool information > >>>>>> interface > >>>>>> return an integer return code (see Table 14.5) to indicate > >>>>>> whether > >>>>>> the function was completed successfully or was aborted. In the > >>>>>> latter case the return code indicates the reason for not > >>>>>> completing > >>>>>> the routine. None of the return codes returned by an routine > >>>>>> impact the execution of the MPI process and do not invoke MPI > >>>>>> error > >>>>>> handlers. The execution of the MPI process continues as if the > >>>>>> call would have completed. However, the \MPI/ implementation > >>>>>> is not required to check all user provided parameters; if a > >>>>>> user > >>>>>> passes invalid parameter values to any routine the behavior of > >>>>>> the implementation is undefined. > >>>>>> > >>>>>> 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. > >>>>> > >>>>> New suggested text: > >>>>> > >>>>>> All functions defined as part of the MPI tool information > >>>>>> interface > >>>>>> return an MPI error class, as defined in Table 14.5, to > >>>>>> indicate > >>>>>> whether > >>>>>> the function was completed successfully or was aborted. In the > >>>>>> latter case the error class indicates the reason for not > >>>>>> completing > >>>>>> the routine. None of the error classes returned by an routine > >>>>>> impact the execution of the MPI process and do not invoke MPI > >>>>>> error > >>>>>> handlers. The execution of the MPI process continues as if the > >>>>>> call would have completed. However, the MPI implementation > >>>>>> is not required to check all user provided parameters; if a > >>>>>> user > >>>>>> passes invalid parameter values to any routine the behavior of > >>>>>> the implementation is undefined. > >>>>>> > >>>>>> All MPI error classes with the prefix MPI\_T\_ must be unique > >>>>>> values > >>>>>> and cannot overlap with any other error codes or error > >>>>>> classes returned by the MPI implementation and must follow > >>>>>> the same rules and restrictions laid out in Chapter 8.4. In > >>>>>> particular, > >>>>>> they must satisfy: > >>>>>> > >>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. > >>>>>> > >>>>>> Rationale: > >>>>>> All MPI tool information interface functions must return error > >>>>>> classes, > >>>>>> because applications cannot portably call MPI_ERROR_CLASS > >>>>>> before > >>>>>> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to > >>>>>> an > >>>>>> error > >>>>>> class. > >>>>> > >>>>> I can go either way (just making the minor change mention above > >>>>> and adding Adam's rational) or with the larger adjustment. I > >>>>> believe those two are semantically equivalent. > >>>>> > >>>>> Martin > >>>>> > >>>>> > >>>>> > >>>>> On Jul 24, 2012, at 2:31 PM, Mohror, Kathryn wrote: > >>>>> > >>>>>> I am in favor of adding Adam's rationale. > >>>>>> > >>>>>>> Rationale: > >>>>>>> All MPI tool information interface functions must return error > >>>>>>> classes, > >>>>>>> because applications cannot portably call MPI_ERROR_CLASS > >>>>>>> before > >>>>>>> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to > >>>>>>> an > >>>>>>> error > >>>>>>> class. > >>>>>> > >>>>>> Kathryn > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:mpi-forum- > >>>>>>> bounces(a)lists.mpi-forum.org] On Behalf Of Adam T. Moody > >>>>>>> Sent: Tuesday, July 24, 2012 11:23 AM > >>>>>>> To: Main MPI Forum mailing list > >>>>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and > >>>>>>> MPI_ERR_LASTCODE > >>>>>>> > >>>>>>> I think we are all converging, but there is one point that I > >>>>>>> wanted to > >>>>>>> bring up: > >>>>>>> > >>>>>>> Can one call ERROR_CLASS/STRING before MPI_INIT? > >>>>>>> > >>>>>>> The current standard doesn't allow this, since > >>>>>>> ERROR_CLASS/STRING are > >>>>>>> not in the list of functions that one can call before INIT. > >>>>>>> However, > >>>>>>> Rolf pointed out that the previous standard didn't need to > >>>>>>> allow > >>>>>>> this, > >>>>>>> because there is no way to replace the default error handler > >>>>>>> (which is > >>>>>>> that errors are fatal) until after INIT. Thus, if one of these > >>>>>>> functions throws an error before INIT, it triggers the > >>>>>>> ERRORS_ARE_FATAL > >>>>>>> handler and never returns. > >>>>>>> > >>>>>>> However, since MPI_T_ errors do not kick off the error > >>>>>>> handlers, > >>>>>>> now we > >>>>>>> have the case where error codes can be returned before > >>>>>>> MPI_INIT. > >>>>>>> However, again, since ERROR_CLASS/STRING are not in the list > >>>>>>> of > >>>>>>> functions that one can call before INIT, it is implied that > >>>>>>> users cannot > >>>>>>> call these functions until after MPI_INIT. It would be nice to > >>>>>>> add a > >>>>>>> rationale statement along these lines to the latest proposed > >>>>>>> text, e.g.: > >>>>>>> > >>>>>>> > >>>>>>> All return codes with the prefix MPI_T_ are error codes. They > >>>>>>> must be > >>>>>>> unique values and cannot overlap with any other error codes or > >>>>>>> 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. In particular, they must > >>>>>>> satisfy: > >>>>>>> > >>>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. > >>>>>>> > >>>>>>> Rationale: > >>>>>>> All MPI tool information interface functions must return error > >>>>>>> classes, > >>>>>>> because applications cannot portably call MPI_ERROR_CLASS > >>>>>>> before > >>>>>>> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to > >>>>>>> an > >>>>>>> error > >>>>>>> class. > >>>>>>> > >>>>>>> > >>>>>>> Note the above is more restrictive than it needs to be, since > >>>>>>> it > >>>>>>> seems > >>>>>>> that we could allow MPI_T to return arbitrary error codes > >>>>>>> *after* > >>>>>>> MPI_INIT. However, it seems we're already imposing the > >>>>>>> restriction that > >>>>>>> they always return error classes. > >>>>>>> -Adam > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Mohror, Kathryn wrote: > >>>>>>> > >>>>>>>> I see the meaning of classes and codes now. I was a bit > >>>>>>>> confused by the > >>>>>>> wording in 8.4. I still think it's a bit weird that everywhere > >>>>>>> else in the standard, > >>>>>>> the codes returned need to be converted to classes to get a > >>>>>>> portable > >>>>>>> understanding of the error, but in MPI_T we will return > >>>>>>> classes, > >>>>>>> so the meaning > >>>>>>> is already known without conversion. > >>>>>>>> > >>>>>>>> However, that said, Bronis' wording of Rolf's suggested > >>>>>>>> change > >>>>>>>> seems to > >>>>>>> make that distinction clearer. I am okay with Bronis' text: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> All return codes with the prefix MPI_T_ are error codes. > >>>>>>>>> They > >>>>>>>>> must be > >>>>>>>>> unique values and cannot overlap with any other error codes > >>>>>>>>> or 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. In particular, they must > >>>>>>>>> satisfy: > >>>>>>>>> > >>>>>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> Kathryn > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: mpi-forum-bounces(a)lists.mpi-forum.org > >>>>>>>>> [mailto:mpi-forum- > >>>>>>>>> bounces(a)lists.mpi-forum.org] On Behalf Of William Gropp > >>>>>>>>> Sent: Tuesday, July 24, 2012 8:31 AM > >>>>>>>>> To: Main MPI Forum mailing list > >>>>>>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and > >>>>>>>>> MPI_ERR_LASTCODE > >>>>>>>>> > >>>>>>>>> MPI error codes, combined with MPI_Error_string, permit an > >>>>>>>>> MPI > >>>>>>>>> implementation to return a instance-specific and detailed > >>>>>>>>> error message. > >>>>>>> Error > >>>>>>>>> classes, like Unix error codes, have only slightly more > >>>>>>>>> information that > >>>>>>>>> "something went wrong". > >>>>>>>>> > >>>>>>>>> Because MPI error classes are error codes, its possible to > >>>>>>>>> return the error > >>>>>>> class; > >>>>>>>>> this can be used before Init and after Finalize now. But > >>>>>>>>> between Init and > >>>>>>>>> Finalize, codes permit but do not require an implementation > >>>>>>>>> to > >>>>>>>>> return more > >>>>>>>>> helpful information. I see no reason to require the MPI_T > >>>>>>>>> interface to be > >>>>>>> less > >>>>>>>>> user-friendly than the rest of the MPI interface. However, > >>>>>>>>> leaving this for > >>>>>>> 3.1 > >>>>>>>>> might make sense. > >>>>>>>>> > >>>>>>>>> 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 23, 2012, at 3:05 PM, Mohror, Kathryn wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> I have some concerns over this. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> 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. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> If we are going to treat MPI_T error codes the same way > >>>>>>>>>> they > >>>>>>>>>> are in the rest > >>>>>>> of > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> the standard, does it make sense to say that "only classes > >>>>>>>>> are > >>>>>>>>> returned" by > >>>>>>>>> MPI_T calls? I think that MPI calls return codes and the > >>>>>>>>> codes > >>>>>>>>> are translated > >>>>>>> to > >>>>>>>>> classes by the MPI_ERROR_CLASS function. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> If MPI_ERROR_CLASS and MPI_ERROR_STRING are not available > >>>>>>>>>> before > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> MPI_Init, then this may be a hardship on tools. I imagine > >>>>>>>>> many > >>>>>>>>> tools doing a > >>>>>>>>> significant amount of set up before MPI_Init to avoid > >>>>>>>>> overhead. However, if > >>>>>>>>> there is no information about what the return codes mean, > >>>>>>>>> then > >>>>>>>>> tools may > >>>>>>> have > >>>>>>>>> difficulty. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Possibly it makes more sense to treat MPI_T return values > >>>>>>>>>> differently than > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> MPI calls? Could the MPI_T return values be a set of defined > >>>>>>>>> codes instead? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Does anyone have different insight on error codes vs > >>>>>>>>>> classes? > >>>>>>>>>> > >>>>>>>>>> Kathryn > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: mpi-forum-bounces(a)lists.mpi-forum.org > >>>>>>>>>>> [mailto:mpi-forum- > >>>>>>>>>>> bounces(a)lists.mpi-forum.org] On Behalf Of Bronis R. de > >>>>>>>>>>> Supinski > >>>>>>>>>>> Sent: Monday, July 23, 2012 10:37 AM > >>>>>>>>>>> To: Main MPI Forum mailing list > >>>>>>>>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and > >>>>>>>>>>> MPI_ERR_LASTCODE > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> OK by me. > >>>>>>>>>>> > >>>>>>>>>>> On Mon, 23 Jul 2012, Dave Goodell wrote: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> I agree, we should make these changes. > >>>>>>>>>>>> > >>>>>>>>>>>> -Dave > >>>>>>>>>>>> > >>>>>>>>>>>> On Jul 23, 2012, at 8:55 AM CDT, Schulz, Martin wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> Hi Rolf, all, > >>>>>>>>>>>>> > >>>>>>>>>>>>> I agree with your suggestions and I am in favor of > >>>>>>>>>>>>> making > >>>>>>>>>>>>> these > >>>>>>> changes. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> Bronis (as well as Kathryn and Dave as the remaining > >>>>>>>>>>> members > >>>>>>>>>>> in the > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> chapter > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> committee for tools) should concur, though. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> Anybody else have any concerns over these changes? > >>>>>>>>>>>>> > >>>>>>>>>>>>> As for the callability of the error functions, I also > >>>>>>>>>>>>> agree - let's target > >>>>>>> those > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>> in > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> 3.1. This change is not vital and bit too big for final > >>>>>>>>>>> edits. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Martin > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Jul 23, 2012, at 4:00 AM, Rolf Rabenseifner wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> 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) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>> ____________________________________________________________________ > >>>>>>> __ > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> __ > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> 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 > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> 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 > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> 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 > >>>>> > >>>>> ________________________________________________________________________ > >>>>> 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 > >>>>> > >>> > >>> ________________________________________________________________________ > >>> 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) > > -- 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 25 Jul '12

25 Jul '12

Rolf: Hmm. Aoparently you did not follow. I do not agree to Martin's change to my suggested wording. I think stating that they return error classes is confusing and not consistent with Section 8.4. That section states: ------------------ The error codes returned by MPI are left entirely to the implementation (with the exception of MPI_SUCCESS). This is done to allow an implementation to provide as much information as possible in the error code (for use with MPI_ERROR_STRING). To make it possible for an application to interpret an error code, the routine MPI_ERROR_CLASS converts any error code into one of a small set of standard error codes, called error classes. Valid error classes are shown in Table 8.1 and Table 8.2. ------------------ This passage clearly states that all MPI routines return error codes (as is consistent with correct design). To obtain an error code, one MUST use MPI_ERROR_CLASS. Martin's change incorrectly makes MPI_T functions return error classes. My wording instead has them return error codes, consistent with existing practice. My wording merely states that they are ALSO error classes. As stated previously, I object to Martin's incorrect simplification, which was the cause of the confusion that generated significant discussion on this topic. We should not codify it. Bronis On Wed, 25 Jul 2012, Rolf Rabenseifner wrote: > Martin, Kathryn, Bronis, Dave, Adam, and all, > > I try to sum up the current proposed text change. > I hope I caught all your proposed text changes. > > If I understand correctly, > then there is no further objection and the whole > tools chapter committee is in favor to do this change. > > My review: I is now fully consistent with the existing > MPI error handling and fulfills all needs of > the MPI_T_ routines. > > Please give your okay as soon as possible. > > As soon as I get the final okay from you all, > I'll execute the change in one consistent svn step in tools and appLang. > > ------------------------- > | Changed and new text is marked with a bar. > ------------------------- > 1) Sect 14.3.9 "Return Codes for the MPI tool information interface" > reads > > All functions defined as part of the MPI tool information interface > return an integer return code (see Table 14.5) to indicate whether > the function was completed successfully or was aborted. In the > latter case the return code indicates the reason for not completing > the routine. None of the return codes returned by an routine > impact the execution of the MPI process and do not invoke MPI error > handlers. The execution of the MPI process continues as if the > call would have completed. However, the MPI implementation > is not required to check all user provided parameters; if a user > passes invalid parameter values to any routine the behavior of > the implementation is undefined. > > 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 functions defined as part of the MPI tool information interface > | return an MPI error class, as defined in Table 14.5, to indicate whether > the function was completed successfully or was aborted. In the > latter case the error class indicates the reason for not completing > the routine. None of the error classes returned by an routine > impact the execution of the MPI process and do not invoke MPI error > handlers. The execution of the MPI process continues as if the > call would have completed. However, the MPI implementation > is not required to check all user provided parameters; if a user > passes invalid parameter values to any routine the behavior of > the implementation is undefined. > > | All MPI error classes with the prefix MPI\_T\_ must be unique values > | and cannot overlap with any other error codes or error > | classes returned by the MPI implementation and must follow > | the same rules and restrictions laid out in Chapter 8.4. In particular, > | they must satisfy: > | > | 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. > | > | Rationale: > | All MPI tool information interface functions must return error classes, > | because applications cannot portably call MPI_ERROR_CLASS before > | MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to an error > | class. End of rationale. > > 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. > -------------------- > > Best regards > Rolf > > ----- Original Message ----- >> From: "Bronis R. de Supinski" <bronis(a)llnl.gov> >> To: "Martin Schulz" <schulzm(a)llnl.gov> >> Cc: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >> Sent: Wednesday, July 25, 2012 7:15:59 AM >> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE >> Martin: >> >> Because using the error classes wording is what caused >> the original confusion. Further, your wording precludes >> ever allowing an implementation to extend the return codes. >> >> Frankly, your opinion is that calling them error classes >> is less confusing but we have already seen that experts >> are confused by that. >> >> As to your second suggestion, it would be simpler if you >> showed just the change to make it clearer that it is just >> a ticket 0 change instead of asking people to wade through >> the comparison of two lengthy passages. >> >> Bronis >> >> >> >> >> >> >> On Tue, 24 Jul 2012, Schulz, Martin wrote: >> >>> Hi Bronis, >>> >>> On Jul 25, 2012, at 12:19 AM, Bronis R. de Supinski wrote: >>> >>>> >>>> Martin: >>>> >>>> You are incorrect. The text in 8.4 explicitly states that >>>> all error classes are error codes. My text was straightforward >>> >>> Yes, that's what I said as well. Error classes are a subset of error >>> codes. >>> >>>> and not as long and awkward as your suggestion that attempts >>> >>> In the first suggestion I just replaced one word and then cut >>> duplicate text (the new version is shorter) - your text said that >>> all return codes are error codes and I still think this is not quite >>> correct or at least ambiguous. We are defining their values with >>> constants in the Table, something that we can't do for error codes >>> that are not classes. Hence, I just suggested to replace "All return >>> codes with the prefix MPI_T_ are error codes." with "All return >>> codes with the prefix MPI_T_ are error classes.". Otherwise we are >>> first saying that return codes can be (arbitrary) error codes, but >>> then we state they should behave as classes. Why not say they are >>> classes from the beginning? >>> >>>> to make a non-existent distinction. I vote for Adam's suggested >>>> rationale that extended my wording. >>> >>> In the second suggestion, I was actually trying to get rid of the >>> term MPI_T return codes, since this has caused the confusion. I >>> think this is cleaner (and the text overall is actually shorter - I >>> just quoted the whole subsection 14.3.9 for context). The text is >>> itself is virtually unchanged from the approved ticket. However, I >>> have said that I am fine with either version. >>> >>> Martin >>> >>> >>>> >>>> Bronis >>>> >>>> >>>> >>>> >>>> On Tue, 24 Jul 2012, Schulz, Martin wrote: >>>> >>>>> I agree with Adam's rational - that is a good addition. >>>>> >>>>> However, I don't think the last proposal (which was, I believe in >>>>> Bronis's email) >>>>> >>>>>> All return codes with the prefix MPI_T_ are error codes. They >>>>>> must be >>>>>> unique values and cannot overlap with any other error codes or >>>>>> 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. In particular, they must >>>>>> satisfy: >>>>>> >>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. >>>>> >>>>> >>>>> is consistent with 8.4 (although that chapter is not quite >>>>> consistent in itself, but that's a different issue). If we want to >>>>> fully embed the MPI_T return codes into the MPI error class/code >>>>> terminology (which I agree with), then MPI_T return codes are not >>>>> error codes, but classes, since we are defining their values. >>>>> Codes that are not classes are left to the implementation. 8.4 >>>>> also states that MPI routines can return classes and that classes >>>>> are a subset of codes. Hence, I think the following is correct: >>>>> >>>>>> All return codes with the prefix MPI_T_ are error classes. They >>>>>> must be >>>>>> unique values and cannot overlap with any other error codes or >>>>>> error >>>>>> classes returned by the MPI implementation. Further, they shall >>>>>> follow >>>>>> the same rules and restrictions as defined in Chapter 8.4. In >>>>>> particular, >>>>>> they must satisfy: >>>>>> >>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. >>>>> >>>>> However, this is starting to get awkward and repetitive. Hence, we >>>>> may want to rewrite 14.3.9 as follows: >>>>> >>>>> Old text (currently in approved for 14.3.9): >>>>> >>>>>> All functions defined as part of the MPI tool information >>>>>> interface >>>>>> return an integer return code (see Table 14.5) to indicate >>>>>> whether >>>>>> the function was completed successfully or was aborted. In the >>>>>> latter case the return code indicates the reason for not >>>>>> completing >>>>>> the routine. None of the return codes returned by an routine >>>>>> impact the execution of the MPI process and do not invoke MPI >>>>>> error >>>>>> handlers. The execution of the MPI process continues as if the >>>>>> call would have completed. However, the \MPI/ implementation >>>>>> is not required to check all user provided parameters; if a user >>>>>> passes invalid parameter values to any routine the behavior of >>>>>> the implementation is undefined. >>>>>> >>>>>> 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. >>>>> >>>>> New suggested text: >>>>> >>>>>> All functions defined as part of the MPI tool information >>>>>> interface >>>>>> return an MPI error class, as defined in Table 14.5, to indicate >>>>>> whether >>>>>> the function was completed successfully or was aborted. In the >>>>>> latter case the error class indicates the reason for not >>>>>> completing >>>>>> the routine. None of the error classes returned by an routine >>>>>> impact the execution of the MPI process and do not invoke MPI >>>>>> error >>>>>> handlers. The execution of the MPI process continues as if the >>>>>> call would have completed. However, the MPI implementation >>>>>> is not required to check all user provided parameters; if a user >>>>>> passes invalid parameter values to any routine the behavior of >>>>>> the implementation is undefined. >>>>>> >>>>>> All MPI error classes with the prefix MPI\_T\_ must be unique >>>>>> values >>>>>> and cannot overlap with any other error codes or error >>>>>> classes returned by the MPI implementation and must follow >>>>>> the same rules and restrictions laid out in Chapter 8.4. In >>>>>> particular, >>>>>> they must satisfy: >>>>>> >>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. >>>>>> >>>>>> Rationale: >>>>>> All MPI tool information interface functions must return error >>>>>> classes, >>>>>> because applications cannot portably call MPI_ERROR_CLASS before >>>>>> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to an >>>>>> error >>>>>> class. >>>>> >>>>> I can go either way (just making the minor change mention above >>>>> and adding Adam's rational) or with the larger adjustment. I >>>>> believe those two are semantically equivalent. >>>>> >>>>> Martin >>>>> >>>>> >>>>> >>>>> On Jul 24, 2012, at 2:31 PM, Mohror, Kathryn wrote: >>>>> >>>>>> I am in favor of adding Adam's rationale. >>>>>> >>>>>>> Rationale: >>>>>>> All MPI tool information interface functions must return error >>>>>>> classes, >>>>>>> because applications cannot portably call MPI_ERROR_CLASS before >>>>>>> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to an >>>>>>> error >>>>>>> class. >>>>>> >>>>>> Kathryn >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:mpi-forum- >>>>>>> bounces(a)lists.mpi-forum.org] On Behalf Of Adam T. Moody >>>>>>> Sent: Tuesday, July 24, 2012 11:23 AM >>>>>>> To: Main MPI Forum mailing list >>>>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and >>>>>>> MPI_ERR_LASTCODE >>>>>>> >>>>>>> I think we are all converging, but there is one point that I >>>>>>> wanted to >>>>>>> bring up: >>>>>>> >>>>>>> Can one call ERROR_CLASS/STRING before MPI_INIT? >>>>>>> >>>>>>> The current standard doesn't allow this, since >>>>>>> ERROR_CLASS/STRING are >>>>>>> not in the list of functions that one can call before INIT. >>>>>>> However, >>>>>>> Rolf pointed out that the previous standard didn't need to allow >>>>>>> this, >>>>>>> because there is no way to replace the default error handler >>>>>>> (which is >>>>>>> that errors are fatal) until after INIT. Thus, if one of these >>>>>>> functions throws an error before INIT, it triggers the >>>>>>> ERRORS_ARE_FATAL >>>>>>> handler and never returns. >>>>>>> >>>>>>> However, since MPI_T_ errors do not kick off the error handlers, >>>>>>> now we >>>>>>> have the case where error codes can be returned before MPI_INIT. >>>>>>> However, again, since ERROR_CLASS/STRING are not in the list of >>>>>>> functions that one can call before INIT, it is implied that >>>>>>> users cannot >>>>>>> call these functions until after MPI_INIT. It would be nice to >>>>>>> add a >>>>>>> rationale statement along these lines to the latest proposed >>>>>>> text, e.g.: >>>>>>> >>>>>>> >>>>>>> All return codes with the prefix MPI_T_ are error codes. They >>>>>>> must be >>>>>>> unique values and cannot overlap with any other error codes or >>>>>>> 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. In particular, they must >>>>>>> satisfy: >>>>>>> >>>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. >>>>>>> >>>>>>> Rationale: >>>>>>> All MPI tool information interface functions must return error >>>>>>> classes, >>>>>>> because applications cannot portably call MPI_ERROR_CLASS before >>>>>>> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to an >>>>>>> error >>>>>>> class. >>>>>>> >>>>>>> >>>>>>> Note the above is more restrictive than it needs to be, since it >>>>>>> seems >>>>>>> that we could allow MPI_T to return arbitrary error codes >>>>>>> *after* >>>>>>> MPI_INIT. However, it seems we're already imposing the >>>>>>> restriction that >>>>>>> they always return error classes. >>>>>>> -Adam >>>>>>> >>>>>>> >>>>>>> >>>>>>> Mohror, Kathryn wrote: >>>>>>> >>>>>>>> I see the meaning of classes and codes now. I was a bit >>>>>>>> confused by the >>>>>>> wording in 8.4. I still think it's a bit weird that everywhere >>>>>>> else in the standard, >>>>>>> the codes returned need to be converted to classes to get a >>>>>>> portable >>>>>>> understanding of the error, but in MPI_T we will return classes, >>>>>>> so the meaning >>>>>>> is already known without conversion. >>>>>>>> >>>>>>>> However, that said, Bronis' wording of Rolf's suggested change >>>>>>>> seems to >>>>>>> make that distinction clearer. I am okay with Bronis' text: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> All return codes with the prefix MPI_T_ are error codes. They >>>>>>>>> must be >>>>>>>>> unique values and cannot overlap with any other error codes >>>>>>>>> or 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. In particular, they must >>>>>>>>> satisfy: >>>>>>>>> >>>>>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Kathryn >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:mpi-forum- >>>>>>>>> bounces(a)lists.mpi-forum.org] On Behalf Of William Gropp >>>>>>>>> Sent: Tuesday, July 24, 2012 8:31 AM >>>>>>>>> To: Main MPI Forum mailing list >>>>>>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and >>>>>>>>> MPI_ERR_LASTCODE >>>>>>>>> >>>>>>>>> MPI error codes, combined with MPI_Error_string, permit an MPI >>>>>>>>> implementation to return a instance-specific and detailed >>>>>>>>> error message. >>>>>>> Error >>>>>>>>> classes, like Unix error codes, have only slightly more >>>>>>>>> information that >>>>>>>>> "something went wrong". >>>>>>>>> >>>>>>>>> Because MPI error classes are error codes, its possible to >>>>>>>>> return the error >>>>>>> class; >>>>>>>>> this can be used before Init and after Finalize now. But >>>>>>>>> between Init and >>>>>>>>> Finalize, codes permit but do not require an implementation to >>>>>>>>> return more >>>>>>>>> helpful information. I see no reason to require the MPI_T >>>>>>>>> interface to be >>>>>>> less >>>>>>>>> user-friendly than the rest of the MPI interface. However, >>>>>>>>> leaving this for >>>>>>> 3.1 >>>>>>>>> might make sense. >>>>>>>>> >>>>>>>>> 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 23, 2012, at 3:05 PM, Mohror, Kathryn wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> I have some concerns over this. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> 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. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> If we are going to treat MPI_T error codes the same way they >>>>>>>>>> are in the rest >>>>>>> of >>>>>>>>>> >>>>>>>>>> >>>>>>>>> the standard, does it make sense to say that "only classes are >>>>>>>>> returned" by >>>>>>>>> MPI_T calls? I think that MPI calls return codes and the codes >>>>>>>>> are translated >>>>>>> to >>>>>>>>> classes by the MPI_ERROR_CLASS function. >>>>>>>>> >>>>>>>>> >>>>>>>>>> If MPI_ERROR_CLASS and MPI_ERROR_STRING are not available >>>>>>>>>> before >>>>>>>>>> >>>>>>>>>> >>>>>>>>> MPI_Init, then this may be a hardship on tools. I imagine many >>>>>>>>> tools doing a >>>>>>>>> significant amount of set up before MPI_Init to avoid >>>>>>>>> overhead. However, if >>>>>>>>> there is no information about what the return codes mean, then >>>>>>>>> tools may >>>>>>> have >>>>>>>>> difficulty. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Possibly it makes more sense to treat MPI_T return values >>>>>>>>>> differently than >>>>>>>>>> >>>>>>>>>> >>>>>>>>> MPI calls? Could the MPI_T return values be a set of defined >>>>>>>>> codes instead? >>>>>>>>> >>>>>>>>> >>>>>>>>>> Does anyone have different insight on error codes vs classes? >>>>>>>>>> >>>>>>>>>> Kathryn >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: mpi-forum-bounces(a)lists.mpi-forum.org >>>>>>>>>>> [mailto:mpi-forum- >>>>>>>>>>> bounces(a)lists.mpi-forum.org] On Behalf Of Bronis R. de >>>>>>>>>>> Supinski >>>>>>>>>>> Sent: Monday, July 23, 2012 10:37 AM >>>>>>>>>>> To: Main MPI Forum mailing list >>>>>>>>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and >>>>>>>>>>> MPI_ERR_LASTCODE >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> OK by me. >>>>>>>>>>> >>>>>>>>>>> On Mon, 23 Jul 2012, Dave Goodell wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I agree, we should make these changes. >>>>>>>>>>>> >>>>>>>>>>>> -Dave >>>>>>>>>>>> >>>>>>>>>>>> On Jul 23, 2012, at 8:55 AM CDT, Schulz, Martin wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Hi Rolf, all, >>>>>>>>>>>>> >>>>>>>>>>>>> I agree with your suggestions and I am in favor of making >>>>>>>>>>>>> these >>>>>>> changes. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> Bronis (as well as Kathryn and Dave as the remaining members >>>>>>>>>>> in the >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> chapter >>>>>>>>> >>>>>>>>> >>>>>>>>>>> committee for tools) should concur, though. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> Anybody else have any concerns over these changes? >>>>>>>>>>>>> >>>>>>>>>>>>> As for the callability of the error functions, I also >>>>>>>>>>>>> agree - let's target >>>>>>> those >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> in >>>>>>>>> >>>>>>>>> >>>>>>>>>>> 3.1. This change is not vital and bit too big for final >>>>>>>>>>> edits. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Martin >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Jul 23, 2012, at 4:00 AM, Rolf Rabenseifner wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> 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) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> ____________________________________________________________________ >>>>>>> __ >>>>>>>>> >>>>>>>>> >>>>>>>>>>> __ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>> >>>>> ________________________________________________________________________ >>>>> 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 >>>>> >>> >>> ________________________________________________________________________ >>> 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-3: MPI_T_... names
by Bronis R. de Supinski 25 Jul '12

25 Jul '12

OK. On Wed, 25 Jul 2012, Rolf Rabenseifner wrote: > After no objection by the tools chapter committee, > I would change everywhere (tools + appLang) in one svn step: > > - from old > MPI_T_ERR_CANNOTINIT > MPI_T_ERR_NOTINITIALIZED > MPI_T_ERR_MEMORY > MPI_T_ERR_CVAR_SETNOTNOW > MPI_T_ERR_CVAR_SETNEVER > MPI_T_ERR_PVAR_NOWRITE > MPI_T_ERR_PVAR_NOSTARTSTOP > MPI_T_ERR_PVAR_NOATOMIC > MPI_T_ERR_INVALIDINDEX > MPI_T_ERR_INVALIDITEM > MPI_T_ERR_INVALIDSESSION > MPI_T_ERR_INVALIDHANDLE > MPI_T_ERR_OUTOFHANDLES > MPI_T_ERR_OUTOFSESSIONS > to new > MPI_T_ERR_CANNOT_INIT > MPI_T_ERR_NOT_INITIALIZED > MPI_T_ERR_MEMORY (unchanged) > MPI_T_ERR_CVAR_SET_NOT_NOW > MPI_T_ERR_CVAR_SET_NEVER > MPI_T_ERR_PVAR_NO_WRITE > MPI_T_ERR_PVAR_NO_STARTSTOP > MPI_T_ERR_PVAR_NO_ATOMIC > MPI_T_ERR_INVALID_INDEX > MPI_T_ERR_INVALID_ITEM > MPI_T_ERR_INVALID_SESSION > MPI_T_ERR_INVALID_HANDLE > MPI_T_ERR_OUT_OF_HANDLES > MPI_T_ERR_OUT_OF_SESSIONS > > Best regards > 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: Tuesday, July 24, 2012 1:03:07 PM >> Subject: Re: [Mpi-forum] MPI-3: MPI_T_... names >> I have no strong opinion on this issue. >> >> On Tue, 24 Jul 2012, Rolf Rabenseifner wrote: >> >>> I started a new email-trunk, because this mail is mainly about >>> names. >>> >>> The problem with MPI_T_... names is that they are partially >>> very long: >>> >>> Current longest MPI_T constants: >>> >>> 123456789012345678901234567890 >>> MPI_T_PVAR_CLASS_HIGHWATERMARK (30) >>> MPI_T_PVAR_CLASS_LOWWATERMARK (29) >>> MPI_T_VERBOSITY_MPIDEV_DETAIL (29) >>> >>> The system is classes of constants are named with underscores, >>> e.g. MPI_T_PVAR_CLASS, the end-names without underscores, >>> e.g. HIGHWATERMARK. >>> >>> In the error codes, your right, they >>> - should change from >>> MPI_T_ERR_INVALIDINDEX >>> MPI_T_ERR_INVALIDITEM >>> MPI_T_ERR_INVALIDSESSION >>> MPI_T_ERR_INVALIDHANDLE >>> to >>> MPI_T_ERR_INVALID_INDEX >>> MPI_T_ERR_INVALID_ITEM >>> 123456789012345678901234567890 >>> MPI_T_ERR_INVALID_SESSION (25) >>> MPI_T_ERR_INVALID_HANDLE >>> because the class name is MPI_T_ERR_INVALID_ >>> >>> - and also >>> MPI_T_ERR_OUTOFHANDLES >>> MPI_T_ERR_OUTOFSESSIONS >>> to >>> MPI_T_ERR_OUT_OF_HANDLES >>> MPI_T_ERR_OUT_OF_SESSIONS >>> - and they may change >>> MPI_T_ERR_CANNOTINIT >>> MPI_T_ERR_NOTINITIALIZED >>> MPI_T_ERR_MEMORY >>> MPI_T_ERR_CVAR_SETNOTNOW >>> MPI_T_ERR_CVAR_SETNEVER >>> MPI_T_ERR_PVAR_NOWRITE >>> MPI_T_ERR_PVAR_NOSTARTSTOP >>> MPI_T_ERR_PVAR_NOATOMIC >>> to >>> MPI_T_ERR_CANNOT_INIT >>> MPI_T_ERR_NOT_INITIALIZED >>> MPI_T_ERR_MEMORY >>> MPI_T_ERR_CVAR_SET_NOT_NOW >>> MPI_T_ERR_CVAR_SET_NEVER >>> MPI_T_ERR_PVAR_NO_WRITE >>> 123456789012345678901234567890 >>> MPI_T_ERR_PVAR_NO_STARTSTOP (27) >>> MPI_T_ERR_PVAR_NO_ATOMIC >>> >>> All the other MPI_T_... names seem to be fine. >>> >>> Bets regards >>> Rolf >>> >>> ----- Original Message ----- >>>> From: "Alexander Supalov" <alexander.supalov(a)intel.com> >>>> To: "Martin Schulz" <schulzm(a)llnl.gov>, "Main MPI Forum mailing >>>> list" <mpi-forum(a)lists.mpi-forum.org> >>>> Sent: Tuesday, July 24, 2012 9:35:13 AM >>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE >>>> Hi everybody, >>>> >>>> I see that that my innocent remarks re. Annex A have lead to a lot >>>> of >>>> discussion. What I'm going to say may resemble Bart Simpson's "I >>>> didn't do it", but I think I have to: >>>> >>>> When commenting on the MPI_T_* names, I meant only their >>>> composition >>>> that differed from most other comparable MPI constant names in that >>>> it >>>> was 1) using contractions and 2) not using underscores to separate >>>> different words. The MPI_T_CANTINIT was but one example of this. I >>>> proposed to change all MPI_T_* names to follow the more traditional >>>> rules (i.e., 1) do not use contractions and 2) do use underscores), >>>> which lead to the MPI_T_CANNOT_INIT proposal that should be >>>> consistently followed up on for every other MPI_T_* name. The >>>> MPI_ERR_LASTCODE was mentioned as a counterexample of a known MPI >>>> constant name that was not following this set of rules either. Oh >>>> well, this is an old one and we won't change it. At no time did I >>>> intend the MPI_T series to become a part of the MPI_ERR series, >>>> although I must admit that they look really close when you start >>>> thinking about them. We will probably have enough time for this >>>> contemplation in the MPI 3.1 time frame. >>>> >>>> To sum up, my proposal now is: >>>> >>>> 1) Consider replacing contractions in all MPI_T_* names >>>> 2) Consider using underscores in all MPI_T_* names >>>> 3) Drop the MPI_ERR and MPI_T connection idea >>>> >>>> And if 1) and 2) are considered too invasive at this point, I won't >>>> go >>>> nuts either: after all, these are just constant names. >>>> >>>> Best regards. >>>> >>>> Alexander >>> >>> -- >>> 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] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE
by Rolf Rabenseifner 25 Jul '12

25 Jul '12

Martin, Kathryn, Bronis, Dave, Adam, and all, I try to sum up the current proposed text change. I hope I caught all your proposed text changes. If I understand correctly, then there is no further objection and the whole tools chapter committee is in favor to do this change. My review: I is now fully consistent with the existing MPI error handling and fulfills all needs of the MPI_T_ routines. Please give your okay as soon as possible. As soon as I get the final okay from you all, I'll execute the change in one consistent svn step in tools and appLang. ------------------------- | Changed and new text is marked with a bar. ------------------------- 1) Sect 14.3.9 "Return Codes for the MPI tool information interface" reads All functions defined as part of the MPI tool information interface return an integer return code (see Table 14.5) to indicate whether the function was completed successfully or was aborted. In the latter case the return code indicates the reason for not completing the routine. None of the return codes returned by an routine impact the execution of the MPI process and do not invoke MPI error handlers. The execution of the MPI process continues as if the call would have completed. However, the MPI implementation is not required to check all user provided parameters; if a user passes invalid parameter values to any routine the behavior of the implementation is undefined. 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 functions defined as part of the MPI tool information interface | return an MPI error class, as defined in Table 14.5, to indicate whether the function was completed successfully or was aborted. In the latter case the error class indicates the reason for not completing the routine. None of the error classes returned by an routine impact the execution of the MPI process and do not invoke MPI error handlers. The execution of the MPI process continues as if the call would have completed. However, the MPI implementation is not required to check all user provided parameters; if a user passes invalid parameter values to any routine the behavior of the implementation is undefined. | All MPI error classes with the prefix MPI\_T\_ must be unique values | and cannot overlap with any other error codes or error | classes returned by the MPI implementation and must follow | the same rules and restrictions laid out in Chapter 8.4. In particular, | they must satisfy: | | 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. | | Rationale: | All MPI tool information interface functions must return error classes, | because applications cannot portably call MPI_ERROR_CLASS before | MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to an error | class. End of rationale. 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. -------------------- Best regards Rolf ----- Original Message ----- > From: "Bronis R. de Supinski" <bronis(a)llnl.gov> > To: "Martin Schulz" <schulzm(a)llnl.gov> > Cc: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > Sent: Wednesday, July 25, 2012 7:15:59 AM > Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE > Martin: > > Because using the error classes wording is what caused > the original confusion. Further, your wording precludes > ever allowing an implementation to extend the return codes. > > Frankly, your opinion is that calling them error classes > is less confusing but we have already seen that experts > are confused by that. > > As to your second suggestion, it would be simpler if you > showed just the change to make it clearer that it is just > a ticket 0 change instead of asking people to wade through > the comparison of two lengthy passages. > > Bronis > > > > > > > On Tue, 24 Jul 2012, Schulz, Martin wrote: > > > Hi Bronis, > > > > On Jul 25, 2012, at 12:19 AM, Bronis R. de Supinski wrote: > > > >> > >> Martin: > >> > >> You are incorrect. The text in 8.4 explicitly states that > >> all error classes are error codes. My text was straightforward > > > > Yes, that's what I said as well. Error classes are a subset of error > > codes. > > > >> and not as long and awkward as your suggestion that attempts > > > > In the first suggestion I just replaced one word and then cut > > duplicate text (the new version is shorter) - your text said that > > all return codes are error codes and I still think this is not quite > > correct or at least ambiguous. We are defining their values with > > constants in the Table, something that we can't do for error codes > > that are not classes. Hence, I just suggested to replace "All return > > codes with the prefix MPI_T_ are error codes." with "All return > > codes with the prefix MPI_T_ are error classes.". Otherwise we are > > first saying that return codes can be (arbitrary) error codes, but > > then we state they should behave as classes. Why not say they are > > classes from the beginning? > > > >> to make a non-existent distinction. I vote for Adam's suggested > >> rationale that extended my wording. > > > > In the second suggestion, I was actually trying to get rid of the > > term MPI_T return codes, since this has caused the confusion. I > > think this is cleaner (and the text overall is actually shorter - I > > just quoted the whole subsection 14.3.9 for context). The text is > > itself is virtually unchanged from the approved ticket. However, I > > have said that I am fine with either version. > > > > Martin > > > > > >> > >> Bronis > >> > >> > >> > >> > >> On Tue, 24 Jul 2012, Schulz, Martin wrote: > >> > >>> I agree with Adam's rational - that is a good addition. > >>> > >>> However, I don't think the last proposal (which was, I believe in > >>> Bronis's email) > >>> > >>>> All return codes with the prefix MPI_T_ are error codes. They > >>>> must be > >>>> unique values and cannot overlap with any other error codes or > >>>> 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. In particular, they must > >>>> satisfy: > >>>> > >>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. > >>> > >>> > >>> is consistent with 8.4 (although that chapter is not quite > >>> consistent in itself, but that's a different issue). If we want to > >>> fully embed the MPI_T return codes into the MPI error class/code > >>> terminology (which I agree with), then MPI_T return codes are not > >>> error codes, but classes, since we are defining their values. > >>> Codes that are not classes are left to the implementation. 8.4 > >>> also states that MPI routines can return classes and that classes > >>> are a subset of codes. Hence, I think the following is correct: > >>> > >>>> All return codes with the prefix MPI_T_ are error classes. They > >>>> must be > >>>> unique values and cannot overlap with any other error codes or > >>>> error > >>>> classes returned by the MPI implementation. Further, they shall > >>>> follow > >>>> the same rules and restrictions as defined in Chapter 8.4. In > >>>> particular, > >>>> they must satisfy: > >>>> > >>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. > >>> > >>> However, this is starting to get awkward and repetitive. Hence, we > >>> may want to rewrite 14.3.9 as follows: > >>> > >>> Old text (currently in approved for 14.3.9): > >>> > >>>> All functions defined as part of the MPI tool information > >>>> interface > >>>> return an integer return code (see Table 14.5) to indicate > >>>> whether > >>>> the function was completed successfully or was aborted. In the > >>>> latter case the return code indicates the reason for not > >>>> completing > >>>> the routine. None of the return codes returned by an routine > >>>> impact the execution of the MPI process and do not invoke MPI > >>>> error > >>>> handlers. The execution of the MPI process continues as if the > >>>> call would have completed. However, the \MPI/ implementation > >>>> is not required to check all user provided parameters; if a user > >>>> passes invalid parameter values to any routine the behavior of > >>>> the implementation is undefined. > >>>> > >>>> 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. > >>> > >>> New suggested text: > >>> > >>>> All functions defined as part of the MPI tool information > >>>> interface > >>>> return an MPI error class, as defined in Table 14.5, to indicate > >>>> whether > >>>> the function was completed successfully or was aborted. In the > >>>> latter case the error class indicates the reason for not > >>>> completing > >>>> the routine. None of the error classes returned by an routine > >>>> impact the execution of the MPI process and do not invoke MPI > >>>> error > >>>> handlers. The execution of the MPI process continues as if the > >>>> call would have completed. However, the MPI implementation > >>>> is not required to check all user provided parameters; if a user > >>>> passes invalid parameter values to any routine the behavior of > >>>> the implementation is undefined. > >>>> > >>>> All MPI error classes with the prefix MPI\_T\_ must be unique > >>>> values > >>>> and cannot overlap with any other error codes or error > >>>> classes returned by the MPI implementation and must follow > >>>> the same rules and restrictions laid out in Chapter 8.4. In > >>>> particular, > >>>> they must satisfy: > >>>> > >>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. > >>>> > >>>> Rationale: > >>>> All MPI tool information interface functions must return error > >>>> classes, > >>>> because applications cannot portably call MPI_ERROR_CLASS before > >>>> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to an > >>>> error > >>>> class. > >>> > >>> I can go either way (just making the minor change mention above > >>> and adding Adam's rational) or with the larger adjustment. I > >>> believe those two are semantically equivalent. > >>> > >>> Martin > >>> > >>> > >>> > >>> On Jul 24, 2012, at 2:31 PM, Mohror, Kathryn wrote: > >>> > >>>> I am in favor of adding Adam's rationale. > >>>> > >>>>> Rationale: > >>>>> All MPI tool information interface functions must return error > >>>>> classes, > >>>>> because applications cannot portably call MPI_ERROR_CLASS before > >>>>> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to an > >>>>> error > >>>>> class. > >>>> > >>>> Kathryn > >>>> > >>>>> -----Original Message----- > >>>>> From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:mpi-forum- > >>>>> bounces(a)lists.mpi-forum.org] On Behalf Of Adam T. Moody > >>>>> Sent: Tuesday, July 24, 2012 11:23 AM > >>>>> To: Main MPI Forum mailing list > >>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and > >>>>> MPI_ERR_LASTCODE > >>>>> > >>>>> I think we are all converging, but there is one point that I > >>>>> wanted to > >>>>> bring up: > >>>>> > >>>>> Can one call ERROR_CLASS/STRING before MPI_INIT? > >>>>> > >>>>> The current standard doesn't allow this, since > >>>>> ERROR_CLASS/STRING are > >>>>> not in the list of functions that one can call before INIT. > >>>>> However, > >>>>> Rolf pointed out that the previous standard didn't need to allow > >>>>> this, > >>>>> because there is no way to replace the default error handler > >>>>> (which is > >>>>> that errors are fatal) until after INIT. Thus, if one of these > >>>>> functions throws an error before INIT, it triggers the > >>>>> ERRORS_ARE_FATAL > >>>>> handler and never returns. > >>>>> > >>>>> However, since MPI_T_ errors do not kick off the error handlers, > >>>>> now we > >>>>> have the case where error codes can be returned before MPI_INIT. > >>>>> However, again, since ERROR_CLASS/STRING are not in the list of > >>>>> functions that one can call before INIT, it is implied that > >>>>> users cannot > >>>>> call these functions until after MPI_INIT. It would be nice to > >>>>> add a > >>>>> rationale statement along these lines to the latest proposed > >>>>> text, e.g.: > >>>>> > >>>>> > >>>>> All return codes with the prefix MPI_T_ are error codes. They > >>>>> must be > >>>>> unique values and cannot overlap with any other error codes or > >>>>> 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. In particular, they must > >>>>> satisfy: > >>>>> > >>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. > >>>>> > >>>>> Rationale: > >>>>> All MPI tool information interface functions must return error > >>>>> classes, > >>>>> because applications cannot portably call MPI_ERROR_CLASS before > >>>>> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to an > >>>>> error > >>>>> class. > >>>>> > >>>>> > >>>>> Note the above is more restrictive than it needs to be, since it > >>>>> seems > >>>>> that we could allow MPI_T to return arbitrary error codes > >>>>> *after* > >>>>> MPI_INIT. However, it seems we're already imposing the > >>>>> restriction that > >>>>> they always return error classes. > >>>>> -Adam > >>>>> > >>>>> > >>>>> > >>>>> Mohror, Kathryn wrote: > >>>>> > >>>>>> I see the meaning of classes and codes now. I was a bit > >>>>>> confused by the > >>>>> wording in 8.4. I still think it's a bit weird that everywhere > >>>>> else in the standard, > >>>>> the codes returned need to be converted to classes to get a > >>>>> portable > >>>>> understanding of the error, but in MPI_T we will return classes, > >>>>> so the meaning > >>>>> is already known without conversion. > >>>>>> > >>>>>> However, that said, Bronis' wording of Rolf's suggested change > >>>>>> seems to > >>>>> make that distinction clearer. I am okay with Bronis' text: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> All return codes with the prefix MPI_T_ are error codes. They > >>>>>>> must be > >>>>>>> unique values and cannot overlap with any other error codes > >>>>>>> or 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. In particular, they must > >>>>>>> satisfy: > >>>>>>> > >>>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> Kathryn > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:mpi-forum- > >>>>>>> bounces(a)lists.mpi-forum.org] On Behalf Of William Gropp > >>>>>>> Sent: Tuesday, July 24, 2012 8:31 AM > >>>>>>> To: Main MPI Forum mailing list > >>>>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and > >>>>>>> MPI_ERR_LASTCODE > >>>>>>> > >>>>>>> MPI error codes, combined with MPI_Error_string, permit an MPI > >>>>>>> implementation to return a instance-specific and detailed > >>>>>>> error message. > >>>>> Error > >>>>>>> classes, like Unix error codes, have only slightly more > >>>>>>> information that > >>>>>>> "something went wrong". > >>>>>>> > >>>>>>> Because MPI error classes are error codes, its possible to > >>>>>>> return the error > >>>>> class; > >>>>>>> this can be used before Init and after Finalize now. But > >>>>>>> between Init and > >>>>>>> Finalize, codes permit but do not require an implementation to > >>>>>>> return more > >>>>>>> helpful information. I see no reason to require the MPI_T > >>>>>>> interface to be > >>>>> less > >>>>>>> user-friendly than the rest of the MPI interface. However, > >>>>>>> leaving this for > >>>>> 3.1 > >>>>>>> might make sense. > >>>>>>> > >>>>>>> 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 23, 2012, at 3:05 PM, Mohror, Kathryn wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> I have some concerns over this. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> 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. > >>>>>>>>> > >>>>>>>>> > >>>>>>>> If we are going to treat MPI_T error codes the same way they > >>>>>>>> are in the rest > >>>>> of > >>>>>>>> > >>>>>>>> > >>>>>>> the standard, does it make sense to say that "only classes are > >>>>>>> returned" by > >>>>>>> MPI_T calls? I think that MPI calls return codes and the codes > >>>>>>> are translated > >>>>> to > >>>>>>> classes by the MPI_ERROR_CLASS function. > >>>>>>> > >>>>>>> > >>>>>>>> If MPI_ERROR_CLASS and MPI_ERROR_STRING are not available > >>>>>>>> before > >>>>>>>> > >>>>>>>> > >>>>>>> MPI_Init, then this may be a hardship on tools. I imagine many > >>>>>>> tools doing a > >>>>>>> significant amount of set up before MPI_Init to avoid > >>>>>>> overhead. However, if > >>>>>>> there is no information about what the return codes mean, then > >>>>>>> tools may > >>>>> have > >>>>>>> difficulty. > >>>>>>> > >>>>>>> > >>>>>>>> Possibly it makes more sense to treat MPI_T return values > >>>>>>>> differently than > >>>>>>>> > >>>>>>>> > >>>>>>> MPI calls? Could the MPI_T return values be a set of defined > >>>>>>> codes instead? > >>>>>>> > >>>>>>> > >>>>>>>> Does anyone have different insight on error codes vs classes? > >>>>>>>> > >>>>>>>> Kathryn > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: mpi-forum-bounces(a)lists.mpi-forum.org > >>>>>>>>> [mailto:mpi-forum- > >>>>>>>>> bounces(a)lists.mpi-forum.org] On Behalf Of Bronis R. de > >>>>>>>>> Supinski > >>>>>>>>> Sent: Monday, July 23, 2012 10:37 AM > >>>>>>>>> To: Main MPI Forum mailing list > >>>>>>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and > >>>>>>>>> MPI_ERR_LASTCODE > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> OK by me. > >>>>>>>>> > >>>>>>>>> On Mon, 23 Jul 2012, Dave Goodell wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> I agree, we should make these changes. > >>>>>>>>>> > >>>>>>>>>> -Dave > >>>>>>>>>> > >>>>>>>>>> On Jul 23, 2012, at 8:55 AM CDT, Schulz, Martin wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> Hi Rolf, all, > >>>>>>>>>>> > >>>>>>>>>>> I agree with your suggestions and I am in favor of making > >>>>>>>>>>> these > >>>>> changes. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> Bronis (as well as Kathryn and Dave as the remaining members > >>>>>>>>> in the > >>>>>>>>> > >>>>>>>>> > >>>>>>> chapter > >>>>>>> > >>>>>>> > >>>>>>>>> committee for tools) should concur, though. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> Anybody else have any concerns over these changes? > >>>>>>>>>>> > >>>>>>>>>>> As for the callability of the error functions, I also > >>>>>>>>>>> agree - let's target > >>>>> those > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> in > >>>>>>> > >>>>>>> > >>>>>>>>> 3.1. This change is not vital and bit too big for final > >>>>>>>>> edits. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> Thanks, > >>>>>>>>>>> > >>>>>>>>>>> Martin > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On Jul 23, 2012, at 4:00 AM, Rolf Rabenseifner wrote: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> 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) > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> ____________________________________________________________________ > >>>>> __ > >>>>>>> > >>>>>>> > >>>>>>>>> __ > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> 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 > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> 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 > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > >>> > >>> ________________________________________________________________________ > >>> 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 > >>> > > > > ________________________________________________________________________ > > 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-3: MPI_T_... names
by Rolf Rabenseifner 25 Jul '12

25 Jul '12

After no objection by the tools chapter committee, I would change everywhere (tools + appLang) in one svn step: - from old MPI_T_ERR_CANNOTINIT MPI_T_ERR_NOTINITIALIZED MPI_T_ERR_MEMORY MPI_T_ERR_CVAR_SETNOTNOW MPI_T_ERR_CVAR_SETNEVER MPI_T_ERR_PVAR_NOWRITE MPI_T_ERR_PVAR_NOSTARTSTOP MPI_T_ERR_PVAR_NOATOMIC MPI_T_ERR_INVALIDINDEX MPI_T_ERR_INVALIDITEM MPI_T_ERR_INVALIDSESSION MPI_T_ERR_INVALIDHANDLE MPI_T_ERR_OUTOFHANDLES MPI_T_ERR_OUTOFSESSIONS to new MPI_T_ERR_CANNOT_INIT MPI_T_ERR_NOT_INITIALIZED MPI_T_ERR_MEMORY (unchanged) MPI_T_ERR_CVAR_SET_NOT_NOW MPI_T_ERR_CVAR_SET_NEVER MPI_T_ERR_PVAR_NO_WRITE MPI_T_ERR_PVAR_NO_STARTSTOP MPI_T_ERR_PVAR_NO_ATOMIC MPI_T_ERR_INVALID_INDEX MPI_T_ERR_INVALID_ITEM MPI_T_ERR_INVALID_SESSION MPI_T_ERR_INVALID_HANDLE MPI_T_ERR_OUT_OF_HANDLES MPI_T_ERR_OUT_OF_SESSIONS Best regards 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: Tuesday, July 24, 2012 1:03:07 PM > Subject: Re: [Mpi-forum] MPI-3: MPI_T_... names > I have no strong opinion on this issue. > > On Tue, 24 Jul 2012, Rolf Rabenseifner wrote: > > > I started a new email-trunk, because this mail is mainly about > > names. > > > > The problem with MPI_T_... names is that they are partially > > very long: > > > > Current longest MPI_T constants: > > > > 123456789012345678901234567890 > > MPI_T_PVAR_CLASS_HIGHWATERMARK (30) > > MPI_T_PVAR_CLASS_LOWWATERMARK (29) > > MPI_T_VERBOSITY_MPIDEV_DETAIL (29) > > > > The system is classes of constants are named with underscores, > > e.g. MPI_T_PVAR_CLASS, the end-names without underscores, > > e.g. HIGHWATERMARK. > > > > In the error codes, your right, they > > - should change from > > MPI_T_ERR_INVALIDINDEX > > MPI_T_ERR_INVALIDITEM > > MPI_T_ERR_INVALIDSESSION > > MPI_T_ERR_INVALIDHANDLE > > to > > MPI_T_ERR_INVALID_INDEX > > MPI_T_ERR_INVALID_ITEM > > 123456789012345678901234567890 > > MPI_T_ERR_INVALID_SESSION (25) > > MPI_T_ERR_INVALID_HANDLE > > because the class name is MPI_T_ERR_INVALID_ > > > > - and also > > MPI_T_ERR_OUTOFHANDLES > > MPI_T_ERR_OUTOFSESSIONS > > to > > MPI_T_ERR_OUT_OF_HANDLES > > MPI_T_ERR_OUT_OF_SESSIONS > > - and they may change > > MPI_T_ERR_CANNOTINIT > > MPI_T_ERR_NOTINITIALIZED > > MPI_T_ERR_MEMORY > > MPI_T_ERR_CVAR_SETNOTNOW > > MPI_T_ERR_CVAR_SETNEVER > > MPI_T_ERR_PVAR_NOWRITE > > MPI_T_ERR_PVAR_NOSTARTSTOP > > MPI_T_ERR_PVAR_NOATOMIC > > to > > MPI_T_ERR_CANNOT_INIT > > MPI_T_ERR_NOT_INITIALIZED > > MPI_T_ERR_MEMORY > > MPI_T_ERR_CVAR_SET_NOT_NOW > > MPI_T_ERR_CVAR_SET_NEVER > > MPI_T_ERR_PVAR_NO_WRITE > > 123456789012345678901234567890 > > MPI_T_ERR_PVAR_NO_STARTSTOP (27) > > MPI_T_ERR_PVAR_NO_ATOMIC > > > > All the other MPI_T_... names seem to be fine. > > > > Bets regards > > Rolf > > > > ----- Original Message ----- > >> From: "Alexander Supalov" <alexander.supalov(a)intel.com> > >> To: "Martin Schulz" <schulzm(a)llnl.gov>, "Main MPI Forum mailing > >> list" <mpi-forum(a)lists.mpi-forum.org> > >> Sent: Tuesday, July 24, 2012 9:35:13 AM > >> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE > >> Hi everybody, > >> > >> I see that that my innocent remarks re. Annex A have lead to a lot > >> of > >> discussion. What I'm going to say may resemble Bart Simpson's "I > >> didn't do it", but I think I have to: > >> > >> When commenting on the MPI_T_* names, I meant only their > >> composition > >> that differed from most other comparable MPI constant names in that > >> it > >> was 1) using contractions and 2) not using underscores to separate > >> different words. The MPI_T_CANTINIT was but one example of this. I > >> proposed to change all MPI_T_* names to follow the more traditional > >> rules (i.e., 1) do not use contractions and 2) do use underscores), > >> which lead to the MPI_T_CANNOT_INIT proposal that should be > >> consistently followed up on for every other MPI_T_* name. The > >> MPI_ERR_LASTCODE was mentioned as a counterexample of a known MPI > >> constant name that was not following this set of rules either. Oh > >> well, this is an old one and we won't change it. At no time did I > >> intend the MPI_T series to become a part of the MPI_ERR series, > >> although I must admit that they look really close when you start > >> thinking about them. We will probably have enough time for this > >> contemplation in the MPI 3.1 time frame. > >> > >> To sum up, my proposal now is: > >> > >> 1) Consider replacing contractions in all MPI_T_* names > >> 2) Consider using underscores in all MPI_T_* names > >> 3) Drop the MPI_ERR and MPI_T connection idea > >> > >> And if 1) and 2) are considered too invasive at this point, I won't > >> go > >> nuts either: after all, these are just constant names. > >> > >> Best regards. > >> > >> Alexander > > > > -- > > 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] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE
by Bronis R. de Supinski 25 Jul '12

25 Jul '12

Martin: Because using the error classes wording is what caused the original confusion. Further, your wording precludes ever allowing an implementation to extend the return codes. Frankly, your opinion is that calling them error classes is less confusing but we have already seen that experts are confused by that. As to your second suggestion, it would be simpler if you showed just the change to make it clearer that it is just a ticket 0 change instead of asking people to wade through the comparison of two lengthy passages. Bronis On Tue, 24 Jul 2012, Schulz, Martin wrote: > Hi Bronis, > > On Jul 25, 2012, at 12:19 AM, Bronis R. de Supinski wrote: > >> >> Martin: >> >> You are incorrect. The text in 8.4 explicitly states that >> all error classes are error codes. My text was straightforward > > Yes, that's what I said as well. Error classes are a subset of error codes. > >> and not as long and awkward as your suggestion that attempts > > In the first suggestion I just replaced one word and then cut duplicate text (the new version is shorter) - your text said that all return codes are error codes and I still think this is not quite correct or at least ambiguous. We are defining their values with constants in the Table, something that we can't do for error codes that are not classes. Hence, I just suggested to replace "All return codes with the prefix MPI_T_ are error codes." with "All return codes with the prefix MPI_T_ are error classes.". Otherwise we are first saying that return codes can be (arbitrary) error codes, but then we state they should behave as classes. Why not say they are classes from the beginning? > >> to make a non-existent distinction. I vote for Adam's suggested >> rationale that extended my wording. > > In the second suggestion, I was actually trying to get rid of the term MPI_T return codes, since this has caused the confusion. I think this is cleaner (and the text overall is actually shorter - I just quoted the whole subsection 14.3.9 for context). The text is itself is virtually unchanged from the approved ticket. However, I have said that I am fine with either version. > > Martin > > >> >> Bronis >> >> >> >> >> On Tue, 24 Jul 2012, Schulz, Martin wrote: >> >>> I agree with Adam's rational - that is a good addition. >>> >>> However, I don't think the last proposal (which was, I believe in Bronis's email) >>> >>>> All return codes with the prefix MPI_T_ are error codes. They must be >>>> unique values and cannot overlap with any other error codes or 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. In particular, they must satisfy: >>>> >>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. >>> >>> >>> is consistent with 8.4 (although that chapter is not quite consistent in itself, but that's a different issue). If we want to fully embed the MPI_T return codes into the MPI error class/code terminology (which I agree with), then MPI_T return codes are not error codes, but classes, since we are defining their values. Codes that are not classes are left to the implementation. 8.4 also states that MPI routines can return classes and that classes are a subset of codes. Hence, I think the following is correct: >>> >>>> All return codes with the prefix MPI_T_ are error classes. They must be >>>> unique values and cannot overlap with any other error codes or error >>>> classes returned by the MPI implementation. Further, they shall follow >>>> the same rules and restrictions as defined in Chapter 8.4. In particular, >>>> they must satisfy: >>>> >>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. >>> >>> However, this is starting to get awkward and repetitive. Hence, we may want to rewrite 14.3.9 as follows: >>> >>> Old text (currently in approved for 14.3.9): >>> >>>> All functions defined as part of the MPI tool information interface >>>> return an integer return code (see Table 14.5) to indicate whether >>>> the function was completed successfully or was aborted. In the >>>> latter case the return code indicates the reason for not completing >>>> the routine. None of the return codes returned by an routine >>>> impact the execution of the MPI process and do not invoke MPI error >>>> handlers. The execution of the MPI process continues as if the >>>> call would have completed. However, the \MPI/ implementation >>>> is not required to check all user provided parameters; if a user >>>> passes invalid parameter values to any routine the behavior of >>>> the implementation is undefined. >>>> >>>> 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. >>> >>> New suggested text: >>> >>>> All functions defined as part of the MPI tool information interface >>>> return an MPI error class, as defined in Table 14.5, to indicate whether >>>> the function was completed successfully or was aborted. In the >>>> latter case the error class indicates the reason for not completing >>>> the routine. None of the error classes returned by an routine >>>> impact the execution of the MPI process and do not invoke MPI error >>>> handlers. The execution of the MPI process continues as if the >>>> call would have completed. However, the MPI implementation >>>> is not required to check all user provided parameters; if a user >>>> passes invalid parameter values to any routine the behavior of >>>> the implementation is undefined. >>>> >>>> All MPI error classes with the prefix MPI\_T\_ must be unique values >>>> and cannot overlap with any other error codes or error >>>> classes returned by the MPI implementation and must follow >>>> the same rules and restrictions laid out in Chapter 8.4. In particular, >>>> they must satisfy: >>>> >>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. >>>> >>>> Rationale: >>>> All MPI tool information interface functions must return error classes, >>>> because applications cannot portably call MPI_ERROR_CLASS before >>>> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to an error >>>> class. >>> >>> I can go either way (just making the minor change mention above and adding Adam's rational) or with the larger adjustment. I believe those two are semantically equivalent. >>> >>> Martin >>> >>> >>> >>> On Jul 24, 2012, at 2:31 PM, Mohror, Kathryn wrote: >>> >>>> I am in favor of adding Adam's rationale. >>>> >>>>> Rationale: >>>>> All MPI tool information interface functions must return error classes, >>>>> because applications cannot portably call MPI_ERROR_CLASS before >>>>> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to an error >>>>> class. >>>> >>>> Kathryn >>>> >>>>> -----Original Message----- >>>>> From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:mpi-forum- >>>>> bounces(a)lists.mpi-forum.org] On Behalf Of Adam T. Moody >>>>> Sent: Tuesday, July 24, 2012 11:23 AM >>>>> To: Main MPI Forum mailing list >>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE >>>>> >>>>> I think we are all converging, but there is one point that I wanted to >>>>> bring up: >>>>> >>>>> Can one call ERROR_CLASS/STRING before MPI_INIT? >>>>> >>>>> The current standard doesn't allow this, since ERROR_CLASS/STRING are >>>>> not in the list of functions that one can call before INIT. However, >>>>> Rolf pointed out that the previous standard didn't need to allow this, >>>>> because there is no way to replace the default error handler (which is >>>>> that errors are fatal) until after INIT. Thus, if one of these >>>>> functions throws an error before INIT, it triggers the ERRORS_ARE_FATAL >>>>> handler and never returns. >>>>> >>>>> However, since MPI_T_ errors do not kick off the error handlers, now we >>>>> have the case where error codes can be returned before MPI_INIT. >>>>> However, again, since ERROR_CLASS/STRING are not in the list of >>>>> functions that one can call before INIT, it is implied that users cannot >>>>> call these functions until after MPI_INIT. It would be nice to add a >>>>> rationale statement along these lines to the latest proposed text, e.g.: >>>>> >>>>> >>>>> All return codes with the prefix MPI_T_ are error codes. They must be >>>>> unique values and cannot overlap with any other error codes or 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. In particular, they must satisfy: >>>>> >>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. >>>>> >>>>> Rationale: >>>>> All MPI tool information interface functions must return error classes, >>>>> because applications cannot portably call MPI_ERROR_CLASS before >>>>> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to an error >>>>> class. >>>>> >>>>> >>>>> Note the above is more restrictive than it needs to be, since it seems >>>>> that we could allow MPI_T to return arbitrary error codes *after* >>>>> MPI_INIT. However, it seems we're already imposing the restriction that >>>>> they always return error classes. >>>>> -Adam >>>>> >>>>> >>>>> >>>>> Mohror, Kathryn wrote: >>>>> >>>>>> I see the meaning of classes and codes now. I was a bit confused by the >>>>> wording in 8.4. I still think it's a bit weird that everywhere else in the standard, >>>>> the codes returned need to be converted to classes to get a portable >>>>> understanding of the error, but in MPI_T we will return classes, so the meaning >>>>> is already known without conversion. >>>>>> >>>>>> However, that said, Bronis' wording of Rolf's suggested change seems to >>>>> make that distinction clearer. I am okay with Bronis' text: >>>>>> >>>>>> >>>>>> >>>>>>> All return codes with the prefix MPI_T_ are error codes. They must be >>>>>>> unique values and cannot overlap with any other error codes or 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. In particular, they must satisfy: >>>>>>> >>>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. >>>>>>> >>>>>>> >>>>>> >>>>>> Kathryn >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:mpi-forum- >>>>>>> bounces(a)lists.mpi-forum.org] On Behalf Of William Gropp >>>>>>> Sent: Tuesday, July 24, 2012 8:31 AM >>>>>>> To: Main MPI Forum mailing list >>>>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE >>>>>>> >>>>>>> MPI error codes, combined with MPI_Error_string, permit an MPI >>>>>>> implementation to return a instance-specific and detailed error message. >>>>> Error >>>>>>> classes, like Unix error codes, have only slightly more information that >>>>>>> "something went wrong". >>>>>>> >>>>>>> Because MPI error classes are error codes, its possible to return the error >>>>> class; >>>>>>> this can be used before Init and after Finalize now. But between Init and >>>>>>> Finalize, codes permit but do not require an implementation to return more >>>>>>> helpful information. I see no reason to require the MPI_T interface to be >>>>> less >>>>>>> user-friendly than the rest of the MPI interface. However, leaving this for >>>>> 3.1 >>>>>>> might make sense. >>>>>>> >>>>>>> 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 23, 2012, at 3:05 PM, Mohror, Kathryn wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> I have some concerns over this. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> 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. >>>>>>>>> >>>>>>>>> >>>>>>>> If we are going to treat MPI_T error codes the same way they are in the rest >>>>> of >>>>>>>> >>>>>>>> >>>>>>> the standard, does it make sense to say that "only classes are returned" by >>>>>>> MPI_T calls? I think that MPI calls return codes and the codes are translated >>>>> to >>>>>>> classes by the MPI_ERROR_CLASS function. >>>>>>> >>>>>>> >>>>>>>> If MPI_ERROR_CLASS and MPI_ERROR_STRING are not available before >>>>>>>> >>>>>>>> >>>>>>> MPI_Init, then this may be a hardship on tools. I imagine many tools doing a >>>>>>> significant amount of set up before MPI_Init to avoid overhead. However, if >>>>>>> there is no information about what the return codes mean, then tools may >>>>> have >>>>>>> difficulty. >>>>>>> >>>>>>> >>>>>>>> Possibly it makes more sense to treat MPI_T return values differently than >>>>>>>> >>>>>>>> >>>>>>> MPI calls? Could the MPI_T return values be a set of defined codes instead? >>>>>>> >>>>>>> >>>>>>>> Does anyone have different insight on error codes vs classes? >>>>>>>> >>>>>>>> Kathryn >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:mpi-forum- >>>>>>>>> bounces(a)lists.mpi-forum.org] On Behalf Of Bronis R. de Supinski >>>>>>>>> Sent: Monday, July 23, 2012 10:37 AM >>>>>>>>> To: Main MPI Forum mailing list >>>>>>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE >>>>>>>>> >>>>>>>>> >>>>>>>>> OK by me. >>>>>>>>> >>>>>>>>> On Mon, 23 Jul 2012, Dave Goodell wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> I agree, we should make these changes. >>>>>>>>>> >>>>>>>>>> -Dave >>>>>>>>>> >>>>>>>>>> On Jul 23, 2012, at 8:55 AM CDT, Schulz, Martin wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Hi Rolf, all, >>>>>>>>>>> >>>>>>>>>>> I agree with your suggestions and I am in favor of making these >>>>> changes. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> Bronis (as well as Kathryn and Dave as the remaining members in the >>>>>>>>> >>>>>>>>> >>>>>>> chapter >>>>>>> >>>>>>> >>>>>>>>> committee for tools) should concur, though. >>>>>>>>> >>>>>>>>> >>>>>>>>>>> Anybody else have any concerns over these changes? >>>>>>>>>>> >>>>>>>>>>> As for the callability of the error functions, I also agree - let's target >>>>> those >>>>>>>>>>> >>>>>>>>>>> >>>>>>> in >>>>>>> >>>>>>> >>>>>>>>> 3.1. This change is not vital and bit too big for final edits. >>>>>>>>> >>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Martin >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Jul 23, 2012, at 4:00 AM, Rolf Rabenseifner wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> 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) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>> ____________________________________________________________________ >>>>> __ >>>>>>> >>>>>>> >>>>>>>>> __ >>>>>>>>> >>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>> ________________________________________________________________________ >>> 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 >>> > > ________________________________________________________________________ > 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 Schulz, Martin 25 Jul '12

25 Jul '12

Hi Bronis, On Jul 25, 2012, at 12:19 AM, Bronis R. de Supinski wrote: > > Martin: > > You are incorrect. The text in 8.4 explicitly states that > all error classes are error codes. My text was straightforward Yes, that's what I said as well. Error classes are a subset of error codes. > and not as long and awkward as your suggestion that attempts In the first suggestion I just replaced one word and then cut duplicate text (the new version is shorter) - your text said that all return codes are error codes and I still think this is not quite correct or at least ambiguous. We are defining their values with constants in the Table, something that we can't do for error codes that are not classes. Hence, I just suggested to replace "All return codes with the prefix MPI_T_ are error codes." with "All return codes with the prefix MPI_T_ are error classes.". Otherwise we are first saying that return codes can be (arbitrary) error codes, but then we state they should behave as classes. Why not say they are classes from the beginning? > to make a non-existent distinction. I vote for Adam's suggested > rationale that extended my wording. In the second suggestion, I was actually trying to get rid of the term MPI_T return codes, since this has caused the confusion. I think this is cleaner (and the text overall is actually shorter - I just quoted the whole subsection 14.3.9 for context). The text is itself is virtually unchanged from the approved ticket. However, I have said that I am fine with either version. Martin > > Bronis > > > > > On Tue, 24 Jul 2012, Schulz, Martin wrote: > >> I agree with Adam's rational - that is a good addition. >> >> However, I don't think the last proposal (which was, I believe in Bronis's email) >> >>> All return codes with the prefix MPI_T_ are error codes. They must be >>> unique values and cannot overlap with any other error codes or 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. In particular, they must satisfy: >>> >>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. >> >> >> is consistent with 8.4 (although that chapter is not quite consistent in itself, but that's a different issue). If we want to fully embed the MPI_T return codes into the MPI error class/code terminology (which I agree with), then MPI_T return codes are not error codes, but classes, since we are defining their values. Codes that are not classes are left to the implementation. 8.4 also states that MPI routines can return classes and that classes are a subset of codes. Hence, I think the following is correct: >> >>> All return codes with the prefix MPI_T_ are error classes. They must be >>> unique values and cannot overlap with any other error codes or error >>> classes returned by the MPI implementation. Further, they shall follow >>> the same rules and restrictions as defined in Chapter 8.4. In particular, >>> they must satisfy: >>> >>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. >> >> However, this is starting to get awkward and repetitive. Hence, we may want to rewrite 14.3.9 as follows: >> >> Old text (currently in approved for 14.3.9): >> >>> All functions defined as part of the MPI tool information interface >>> return an integer return code (see Table 14.5) to indicate whether >>> the function was completed successfully or was aborted. In the >>> latter case the return code indicates the reason for not completing >>> the routine. None of the return codes returned by an routine >>> impact the execution of the MPI process and do not invoke MPI error >>> handlers. The execution of the MPI process continues as if the >>> call would have completed. However, the \MPI/ implementation >>> is not required to check all user provided parameters; if a user >>> passes invalid parameter values to any routine the behavior of >>> the implementation is undefined. >>> >>> 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. >> >> New suggested text: >> >>> All functions defined as part of the MPI tool information interface >>> return an MPI error class, as defined in Table 14.5, to indicate whether >>> the function was completed successfully or was aborted. In the >>> latter case the error class indicates the reason for not completing >>> the routine. None of the error classes returned by an routine >>> impact the execution of the MPI process and do not invoke MPI error >>> handlers. The execution of the MPI process continues as if the >>> call would have completed. However, the MPI implementation >>> is not required to check all user provided parameters; if a user >>> passes invalid parameter values to any routine the behavior of >>> the implementation is undefined. >>> >>> All MPI error classes with the prefix MPI\_T\_ must be unique values >>> and cannot overlap with any other error codes or error >>> classes returned by the MPI implementation and must follow >>> the same rules and restrictions laid out in Chapter 8.4. In particular, >>> they must satisfy: >>> >>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. >>> >>> Rationale: >>> All MPI tool information interface functions must return error classes, >>> because applications cannot portably call MPI_ERROR_CLASS before >>> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to an error >>> class. >> >> I can go either way (just making the minor change mention above and adding Adam's rational) or with the larger adjustment. I believe those two are semantically equivalent. >> >> Martin >> >> >> >> On Jul 24, 2012, at 2:31 PM, Mohror, Kathryn wrote: >> >>> I am in favor of adding Adam's rationale. >>> >>>> Rationale: >>>> All MPI tool information interface functions must return error classes, >>>> because applications cannot portably call MPI_ERROR_CLASS before >>>> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to an error >>>> class. >>> >>> Kathryn >>> >>>> -----Original Message----- >>>> From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:mpi-forum- >>>> bounces(a)lists.mpi-forum.org] On Behalf Of Adam T. Moody >>>> Sent: Tuesday, July 24, 2012 11:23 AM >>>> To: Main MPI Forum mailing list >>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE >>>> >>>> I think we are all converging, but there is one point that I wanted to >>>> bring up: >>>> >>>> Can one call ERROR_CLASS/STRING before MPI_INIT? >>>> >>>> The current standard doesn't allow this, since ERROR_CLASS/STRING are >>>> not in the list of functions that one can call before INIT. However, >>>> Rolf pointed out that the previous standard didn't need to allow this, >>>> because there is no way to replace the default error handler (which is >>>> that errors are fatal) until after INIT. Thus, if one of these >>>> functions throws an error before INIT, it triggers the ERRORS_ARE_FATAL >>>> handler and never returns. >>>> >>>> However, since MPI_T_ errors do not kick off the error handlers, now we >>>> have the case where error codes can be returned before MPI_INIT. >>>> However, again, since ERROR_CLASS/STRING are not in the list of >>>> functions that one can call before INIT, it is implied that users cannot >>>> call these functions until after MPI_INIT. It would be nice to add a >>>> rationale statement along these lines to the latest proposed text, e.g.: >>>> >>>> >>>> All return codes with the prefix MPI_T_ are error codes. They must be >>>> unique values and cannot overlap with any other error codes or 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. In particular, they must satisfy: >>>> >>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. >>>> >>>> Rationale: >>>> All MPI tool information interface functions must return error classes, >>>> because applications cannot portably call MPI_ERROR_CLASS before >>>> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to an error >>>> class. >>>> >>>> >>>> Note the above is more restrictive than it needs to be, since it seems >>>> that we could allow MPI_T to return arbitrary error codes *after* >>>> MPI_INIT. However, it seems we're already imposing the restriction that >>>> they always return error classes. >>>> -Adam >>>> >>>> >>>> >>>> Mohror, Kathryn wrote: >>>> >>>>> I see the meaning of classes and codes now. I was a bit confused by the >>>> wording in 8.4. I still think it's a bit weird that everywhere else in the standard, >>>> the codes returned need to be converted to classes to get a portable >>>> understanding of the error, but in MPI_T we will return classes, so the meaning >>>> is already known without conversion. >>>>> >>>>> However, that said, Bronis' wording of Rolf's suggested change seems to >>>> make that distinction clearer. I am okay with Bronis' text: >>>>> >>>>> >>>>> >>>>>> All return codes with the prefix MPI_T_ are error codes. They must be >>>>>> unique values and cannot overlap with any other error codes or 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. In particular, they must satisfy: >>>>>> >>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE. >>>>>> >>>>>> >>>>> >>>>> Kathryn >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:mpi-forum- >>>>>> bounces(a)lists.mpi-forum.org] On Behalf Of William Gropp >>>>>> Sent: Tuesday, July 24, 2012 8:31 AM >>>>>> To: Main MPI Forum mailing list >>>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE >>>>>> >>>>>> MPI error codes, combined with MPI_Error_string, permit an MPI >>>>>> implementation to return a instance-specific and detailed error message. >>>> Error >>>>>> classes, like Unix error codes, have only slightly more information that >>>>>> "something went wrong". >>>>>> >>>>>> Because MPI error classes are error codes, its possible to return the error >>>> class; >>>>>> this can be used before Init and after Finalize now. But between Init and >>>>>> Finalize, codes permit but do not require an implementation to return more >>>>>> helpful information. I see no reason to require the MPI_T interface to be >>>> less >>>>>> user-friendly than the rest of the MPI interface. However, leaving this for >>>> 3.1 >>>>>> might make sense. >>>>>> >>>>>> 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 23, 2012, at 3:05 PM, Mohror, Kathryn wrote: >>>>>> >>>>>> >>>>>> >>>>>>> I have some concerns over this. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> 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. >>>>>>>> >>>>>>>> >>>>>>> If we are going to treat MPI_T error codes the same way they are in the rest >>>> of >>>>>>> >>>>>>> >>>>>> the standard, does it make sense to say that "only classes are returned" by >>>>>> MPI_T calls? I think that MPI calls return codes and the codes are translated >>>> to >>>>>> classes by the MPI_ERROR_CLASS function. >>>>>> >>>>>> >>>>>>> If MPI_ERROR_CLASS and MPI_ERROR_STRING are not available before >>>>>>> >>>>>>> >>>>>> MPI_Init, then this may be a hardship on tools. I imagine many tools doing a >>>>>> significant amount of set up before MPI_Init to avoid overhead. However, if >>>>>> there is no information about what the return codes mean, then tools may >>>> have >>>>>> difficulty. >>>>>> >>>>>> >>>>>>> Possibly it makes more sense to treat MPI_T return values differently than >>>>>>> >>>>>>> >>>>>> MPI calls? Could the MPI_T return values be a set of defined codes instead? >>>>>> >>>>>> >>>>>>> Does anyone have different insight on error codes vs classes? >>>>>>> >>>>>>> Kathryn >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:mpi-forum- >>>>>>>> bounces(a)lists.mpi-forum.org] On Behalf Of Bronis R. de Supinski >>>>>>>> Sent: Monday, July 23, 2012 10:37 AM >>>>>>>> To: Main MPI Forum mailing list >>>>>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE >>>>>>>> >>>>>>>> >>>>>>>> OK by me. >>>>>>>> >>>>>>>> On Mon, 23 Jul 2012, Dave Goodell wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> I agree, we should make these changes. >>>>>>>>> >>>>>>>>> -Dave >>>>>>>>> >>>>>>>>> On Jul 23, 2012, at 8:55 AM CDT, Schulz, Martin wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hi Rolf, all, >>>>>>>>>> >>>>>>>>>> I agree with your suggestions and I am in favor of making these >>>> changes. >>>>>>>>>> >>>>>>>>>> >>>>>>>> Bronis (as well as Kathryn and Dave as the remaining members in the >>>>>>>> >>>>>>>> >>>>>> chapter >>>>>> >>>>>> >>>>>>>> committee for tools) should concur, though. >>>>>>>> >>>>>>>> >>>>>>>>>> Anybody else have any concerns over these changes? >>>>>>>>>> >>>>>>>>>> As for the callability of the error functions, I also agree - let's target >>>> those >>>>>>>>>> >>>>>>>>>> >>>>>> in >>>>>> >>>>>> >>>>>>>> 3.1. This change is not vital and bit too big for final edits. >>>>>>>> >>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Martin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Jul 23, 2012, at 4:00 AM, Rolf Rabenseifner wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> 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) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> ____________________________________________________________________ >>>> __ >>>>>> >>>>>> >>>>>>>> __ >>>>>>>> >>>>>>>> >>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> ________________________________________________________________________ >> 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 >> ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

← Newer
1
2
3
4
5
6
7
8
...
24
Older →

Jump to page: