[Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE

Tue Jul 24 10:49:45 CDT 2012

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 at lists.mpi-forum.org [mailto:mpi-forum-
> bounces at 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 at lists.mpi-forum.org [mailto:mpi-forum-
> >> bounces at 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 at llnl.gov>
> >>>>>> To: "Main MPI Forum mailing list" <mpi-forum at 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 at llnl.gov>
> >>>>>>>> To: "Main MPI Forum mailing list" <mpi-forum at lists.mpi-
> forum.org>
> >>>>>>>> Cc: "Rolf Rabenseifner" <rabenseifner at 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 at 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 at lists.mpi-forum.org
> >>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> >>>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email
> >>>>>>> rabenseifner at 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 at lists.mpi-forum.org
> >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> >>>>>>
> >>>>>>
> >>
> ______________________________________________________________________
> >> __
> >>>>>> Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
> >>>>>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> mpi-forum mailing list
> >>>>>> mpi-forum at lists.mpi-forum.org
> >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> >>>>>
> >>>>> --
> >>>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at 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 at llnl.gov, http://people.llnl.gov/schulzm
> >>>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> mpi-forum mailing list
> >>>> mpi-forum at lists.mpi-forum.org
> >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> >>>
> >>>
> >>> _______________________________________________
> >>> mpi-forum mailing list
> >>> mpi-forum at lists.mpi-forum.org
> >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> >>>
> >> _______________________________________________
> >> mpi-forum mailing list
> >> mpi-forum at lists.mpi-forum.org
> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> >
> > _______________________________________________
> > mpi-forum mailing list
> > mpi-forum at lists.mpi-forum.org
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>
>
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum