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" <[email protected]> To: "Main MPI Forum mailing list" <[email protected]> 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" <[email protected]> To: "Main MPI Forum mailing list" <[email protected]> Cc: "Rolf Rabenseifner" <[email protected]> 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 [email protected] 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 [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] 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 [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
________________________________________________________________________ Martin Schulz, [email protected], http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA
_______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] 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, [email protected], http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA
_______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
_______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
participants (1)
-
Bronis R. de Supinski