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

Mon Jul 23 12:37:01 CDT 2012

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
>