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

William Gropp wgropp at illinois.edu
Sun Jul 22 06:39:23 CDT 2012


Are these MPI_T_ERR_xxx codes or are they classes?  The MPI_ERR_xx list is of classes, not codes (classes may be used as codes but codes may or may not be a class).

Bill

William Gropp
Director, Parallel Computing Institute
Deputy Director for Research
Institute for Advanced Computing Applications and Technologies
Paul and Cynthia Saylor Professor of Computer Science
University of Illinois Urbana-Champaign



On Jul 22, 2012, at 4:54 AM, 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





More information about the mpi-forum mailing list