[Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE
Bronis R. de Supinski
bronis at llnl.gov
Sun Jul 22 04:54:45 CDT 2012
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)
>
More information about the mpi-forum
mailing list