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