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

Dave Goodell goodell at mcs.anl.gov
Mon Jul 23 12:32:08 CDT 2012 

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

More information about the mpi-forum mailing list