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

Rolf Rabenseifner rabenseifner at hlrs.de
Sun Jul 22 15:46:09 CDT 2012


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)



More information about the mpi-forum mailing list