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

Rolf Rabenseifner rabenseifner at hlrs.de
Wed Jul 25 08:10:17 CDT 2012


Bronis, 
    you're right. Latest text is okay with me.
Martin, Adam, Kathryn, Dave, p
    lease can you also confirm 
    if okay for you.

Best regards
Rolf 

----- Original Message -----
> From: "Bronis R. de Supinski" <bronis at llnl.gov>
> To: "Rolf Rabenseifner" <rabenseifner at hlrs.de>
> Cc: "Martin Schulz" <schulzm at llnl.gov>, "Kathryn Mohror" <mohror1 at llnl.gov>, "Dave Goodell" <goodell at mcs.anl.gov>,
> "Adam T. Moody" <moody20 at llnl.gov>, "Main MPI Forum mailing list" <mpi-forum at lists.mpi-forum.org>
> Sent: Wednesday, July 25, 2012 2:54:46 PM
> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE
> Rolf:
> 
> Um, not quite. The first paragraph should read "error
> codes", not "error classes". The routines return error
> codes, all of which happen to be error classes.
> 
> I have modified below.
> 
> Bronis
> 
> 
> On Wed, 25 Jul 2012, Rolf Rabenseifner wrote:
> 
> > Bronis, Martin, Adam, Kathryn, Dave, and all,
> >
> > Okay, now I understand - I thought Martin's arguments were okay
> > for shortening the text - but the original long form is more
> > consistent.
> >
> > Can we therefore agree on the text below.
> > It is the text from Bronis plus Adams rationale plus the other
> > changes from the original mail.
> >
> > I would like to have enough okays.
> >
> > ------------------------------
> > | Changed and new text is marked with a bar.
> > -------------------------
> > 1) Sect 14.3.9 "Return Codes for the MPI tool information interface"
> > reads
> >
> >   All functions defined as part of the MPI tool information
> >   interface
> >   return an integer return code (see Table 14.5) to indicate whether
> >   the function was completed successfully or was aborted. In the
> >   latter case the return code indicates the reason for not
> >   completing
> >   the routine. None of the return codes returned by an routine
> >   impact the execution of the MPI process and do not invoke MPI
> >   error
> >   handlers. The execution of the MPI process continues as if the
> >   call would have completed. However, the MPI implementation
> >   is not required to check all user provided parameters; if a user
> >   passes invalid parameter values to any routine the behavior of
> >   the implementation is undefined.
> >
> >   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 functions defined as part of the MPI tool information interface
> return an integer error code (see Table 14.5) to indicate whether
> the function was completed successfully or was aborted. In the
> latter case the error code indicates the reason for not completing
> the routine. None of the error codes returned by an routine
> impact the execution of the MPI process and do not invoke MPI error
> handlers. The execution of the MPI process continues as if the
> call would have completed. However, the MPI implementation
> is not required to check all user provided parameters; if a user
> passes invalid parameter values to any routine the behavior of
> the implementation is undefined.
> 
> All return codes with the prefix MPI_T_ are error codes. They must be
> unique values and cannot overlap with any other error codes or 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. In particular, they must satisfy:
> 
> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE.
> 
> Rationale:
> All MPI tool information interface functions must return error
> classes,
> because applications cannot portably call MPI_ERROR_CLASS before
> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to an error
> class. End of rationale.
> 
> 
> 
> >
> > 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.
> > ------------------------------
> >
> > Best regards
> > Rolf
> >
> > ----- Original Message -----
> >> From: "Bronis R. de Supinski" <bronis at llnl.gov>
> >> To: "Rolf Rabenseifner" <rabenseifner at hlrs.de>
> >> Cc: "Martin Schulz" <schulzm at llnl.gov>, "Kathryn Mohror"
> >> <mohror1 at llnl.gov>, "Dave Goodell" <goodell at mcs.anl.gov>,
> >> "Adam T. Moody" <moody20 at llnl.gov>, "Main MPI Forum mailing list"
> >> <mpi-forum at lists.mpi-forum.org>
> >> Sent: Wednesday, July 25, 2012 12:07:55 PM
> >> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE
> >> Rolf:
> >>
> >> Hmm. Aoparently you did not follow. I do not agree to
> >> Martin's change to my suggested wording. I think
> >> stating that they return error classes is confusing
> >> and not consistent with Section 8.4. That section states:
> >>
> >> ------------------
> >>
> >> The error codes returned by MPI are left entirely to the
> >> implementation
> >> (with the exception of MPI_SUCCESS). This is done to allow an
> >> implementation
> >> to provide as much information as possible in the error code (for
> >> use
> >> with
> >> MPI_ERROR_STRING).
> >>
> >> To make it possible for an application to interpret an error code,
> >> the
> >> routine MPI_ERROR_CLASS converts any error code into one of a small
> >> set of
> >> standard error codes, called error classes. Valid error classes are
> >> shown
> >> in Table 8.1 and Table 8.2.
> >>
> >> ------------------
> >>
> >> This passage clearly states that all MPI routines return error
> >> codes
> >> (as
> >> is consistent with correct design). To obtain an error code, one
> >> MUST
> >> use MPI_ERROR_CLASS. Martin's change incorrectly makes MPI_T
> >> functions
> >> return error classes. My wording instead has them return error
> >> codes,
> >> consistent with existing practice. My wording merely states that
> >> they
> >> are ALSO error classes.
> >>
> >> As stated previously, I object to Martin's incorrect
> >> simplification,
> >> which was the cause of the confusion that generated significant
> >> discussion on this topic. We should not codify it.
> >>
> >> Bronis
> >>
> >>
> >>
> >>
> >> On Wed, 25 Jul 2012, Rolf Rabenseifner wrote:
> >>
> >>> Martin, Kathryn, Bronis, Dave, Adam, and all,
> >>>
> >>> I try to sum up the current proposed text change.
> >>> I hope I caught all your proposed text changes.
> >>>
> >>> If I understand correctly,
> >>> then there is no further objection and the whole
> >>> tools chapter committee is in favor to do this change.
> >>>
> >>> My review: I is now fully consistent with the existing
> >>>           MPI error handling and fulfills all needs of
> >>>           the MPI_T_ routines.
> >>>
> >>> Please give your okay as soon as possible.
> >>>
> >>> As soon as I get the final okay from you all,
> >>> I'll execute the change in one consistent svn step in tools and
> >>> appLang.
> >>>
> >>> -------------------------
> >>> | Changed and new text is marked with a bar.
> >>> -------------------------
> >>> 1) Sect 14.3.9 "Return Codes for the MPI tool information
> >>> interface"
> >>> reads
> >>>
> >>>   All functions defined as part of the MPI tool information
> >>>   interface
> >>>   return an integer return code (see Table 14.5) to indicate
> >>>   whether
> >>>   the function was completed successfully or was aborted. In the
> >>>   latter case the return code indicates the reason for not
> >>>   completing
> >>>   the routine. None of the return codes returned by an routine
> >>>   impact the execution of the MPI process and do not invoke MPI
> >>>   error
> >>>   handlers. The execution of the MPI process continues as if the
> >>>   call would have completed. However, the MPI implementation
> >>>   is not required to check all user provided parameters; if a user
> >>>   passes invalid parameter values to any routine the behavior of
> >>>   the implementation is undefined.
> >>>
> >>>   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 functions defined as part of the MPI tool information
> >>>   interface
> >>> |  return an MPI error class, as defined in Table 14.5, to
> >>> |  indicate
> >>> |  whether
> >>>   the function was completed successfully or was aborted. In the
> >>>   latter case the error class indicates the reason for not
> >>>   completing
> >>>   the routine. None of the error classes returned by an routine
> >>>   impact the execution of the MPI process and do not invoke MPI
> >>>   error
> >>>   handlers. The execution of the MPI process continues as if the
> >>>   call would have completed. However, the MPI implementation
> >>>   is not required to check all user provided parameters; if a user
> >>>   passes invalid parameter values to any routine the behavior of
> >>>   the implementation is undefined.
> >>>
> >>> |  All MPI error classes with the prefix MPI\_T\_ must be unique
> >>> |  values
> >>> |  and cannot overlap with any other error codes or error
> >>> |  classes returned by the MPI implementation and must follow
> >>> |  the same rules and restrictions laid out in Chapter 8.4. In
> >>> |  particular,
> >>> |  they must satisfy:
> >>> |
> >>> |    0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE.
> >>> |
> >>> |  Rationale:
> >>> |  All MPI tool information interface functions must return error
> >>> |  classes,
> >>> |  because applications cannot portably call MPI_ERROR_CLASS
> >>> |  before
> >>> |  MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to
> >>> |  an
> >>> |  error
> >>> |  class. End of rationale.
> >>>
> >>> 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.
> >>> --------------------
> >>>
> >>> Best regards
> >>> Rolf
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bronis R. de Supinski" <bronis at llnl.gov>
> >>>> To: "Martin Schulz" <schulzm at llnl.gov>
> >>>> Cc: "Main MPI Forum mailing list" <mpi-forum at lists.mpi-forum.org>
> >>>> Sent: Wednesday, July 25, 2012 7:15:59 AM
> >>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and
> >>>> MPI_ERR_LASTCODE
> >>>> Martin:
> >>>>
> >>>> Because using the error classes wording is what caused
> >>>> the original confusion. Further, your wording precludes
> >>>> ever allowing an implementation to extend the return codes.
> >>>>
> >>>> Frankly, your opinion is that calling them error classes
> >>>> is less confusing but we have already seen that experts
> >>>> are confused by that.
> >>>>
> >>>> As to your second suggestion, it would be simpler if you
> >>>> showed just the change to make it clearer that it is just
> >>>> a ticket 0 change instead of asking people to wade through
> >>>> the comparison of two lengthy passages.
> >>>>
> >>>> Bronis
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Tue, 24 Jul 2012, Schulz, Martin wrote:
> >>>>
> >>>>> Hi Bronis,
> >>>>>
> >>>>> On Jul 25, 2012, at 12:19 AM, Bronis R. de Supinski wrote:
> >>>>>
> >>>>>>
> >>>>>> Martin:
> >>>>>>
> >>>>>> You are incorrect. The text in 8.4 explicitly states that
> >>>>>> all error classes are error codes. My text was straightforward
> >>>>>
> >>>>> Yes, that's what I said as well. Error classes are a subset of
> >>>>> error
> >>>>> codes.
> >>>>>
> >>>>>> and not as long and awkward as your suggestion that attempts
> >>>>>
> >>>>> In the first suggestion I just replaced one word and then cut
> >>>>> duplicate text (the new version is shorter) - your text said
> >>>>> that
> >>>>> all return codes are error codes and I still think this is not
> >>>>> quite
> >>>>> correct or at least ambiguous. We are defining their values with
> >>>>> constants in the Table, something that we can't do for error
> >>>>> codes
> >>>>> that are not classes. Hence, I just suggested to replace "All
> >>>>> return
> >>>>> codes with the prefix MPI_T_ are error codes." with "All return
> >>>>> codes with the prefix MPI_T_ are error classes.". Otherwise we
> >>>>> are
> >>>>> first saying that return codes can be (arbitrary) error codes,
> >>>>> but
> >>>>> then we state they should behave as classes. Why not say they
> >>>>> are
> >>>>> classes from the beginning?
> >>>>>
> >>>>>> to make a non-existent distinction. I vote for Adam's suggested
> >>>>>> rationale that extended my wording.
> >>>>>
> >>>>> In the second suggestion, I was actually trying to get rid of
> >>>>> the
> >>>>> term MPI_T return codes, since this has caused the confusion. I
> >>>>> think this is cleaner (and the text overall is actually shorter
> >>>>> -
> >>>>> I
> >>>>> just quoted the whole subsection 14.3.9 for context). The text
> >>>>> is
> >>>>> itself is virtually unchanged from the approved ticket. However,
> >>>>> I
> >>>>> have said that I am fine with either version.
> >>>>>
> >>>>> Martin
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> Bronis
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Tue, 24 Jul 2012, Schulz, Martin wrote:
> >>>>>>
> >>>>>>> I agree with Adam's rational - that is a good addition.
> >>>>>>>
> >>>>>>> However, I don't think the last proposal (which was, I believe
> >>>>>>> in
> >>>>>>> Bronis's email)
> >>>>>>>
> >>>>>>>>   All return codes with the prefix MPI_T_ are error codes.
> >>>>>>>>   They
> >>>>>>>>   must be
> >>>>>>>>   unique values and cannot overlap with any other error codes
> >>>>>>>>   or
> >>>>>>>>   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. In particular, they must
> >>>>>>>>   satisfy:
> >>>>>>>>
> >>>>>>>>      0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE.
> >>>>>>>
> >>>>>>>
> >>>>>>> is consistent with 8.4 (although that chapter is not quite
> >>>>>>> consistent in itself, but that's a different issue). If we
> >>>>>>> want
> >>>>>>> to
> >>>>>>> fully embed the MPI_T return codes into the MPI error
> >>>>>>> class/code
> >>>>>>> terminology (which I agree with), then MPI_T return codes are
> >>>>>>> not
> >>>>>>> error codes, but classes, since we are defining their values.
> >>>>>>> Codes that are not classes are left to the implementation. 8.4
> >>>>>>> also states that MPI routines can return classes and that
> >>>>>>> classes
> >>>>>>> are a subset of codes. Hence, I think the following is
> >>>>>>> correct:
> >>>>>>>
> >>>>>>>> All return codes with the prefix MPI_T_ are error classes.
> >>>>>>>> They
> >>>>>>>> must be
> >>>>>>>> unique values and cannot overlap with any other error codes
> >>>>>>>> or
> >>>>>>>> error
> >>>>>>>> classes returned by the MPI implementation. Further, they
> >>>>>>>> shall
> >>>>>>>> follow
> >>>>>>>> the same rules and restrictions as defined in Chapter 8.4. In
> >>>>>>>> particular,
> >>>>>>>> they must satisfy:
> >>>>>>>>
> >>>>>>>>      0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE.
> >>>>>>>
> >>>>>>> However, this is starting to get awkward and repetitive.
> >>>>>>> Hence,
> >>>>>>> we
> >>>>>>> may want to rewrite 14.3.9 as follows:
> >>>>>>>
> >>>>>>> Old text (currently in approved for 14.3.9):
> >>>>>>>
> >>>>>>>> All functions defined as part of the MPI tool information
> >>>>>>>> interface
> >>>>>>>> return an integer return code (see Table 14.5) to indicate
> >>>>>>>> whether
> >>>>>>>> the function was completed successfully or was aborted. In
> >>>>>>>> the
> >>>>>>>> latter case the return code indicates the reason for not
> >>>>>>>> completing
> >>>>>>>> the routine. None of the return codes returned by an routine
> >>>>>>>> impact the execution of the MPI process and do not invoke MPI
> >>>>>>>> error
> >>>>>>>> handlers. The execution of the MPI process continues as if
> >>>>>>>> the
> >>>>>>>> call would have completed. However, the \MPI/ implementation
> >>>>>>>> is not required to check all user provided parameters; if a
> >>>>>>>> user
> >>>>>>>> passes invalid parameter values to any routine the behavior
> >>>>>>>> of
> >>>>>>>> the implementation is undefined.
> >>>>>>>>
> >>>>>>>> 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.
> >>>>>>>
> >>>>>>> New suggested text:
> >>>>>>>
> >>>>>>>> All functions defined as part of the MPI tool information
> >>>>>>>> interface
> >>>>>>>> return an MPI error class, as defined in Table 14.5, to
> >>>>>>>> indicate
> >>>>>>>> whether
> >>>>>>>> the function was completed successfully or was aborted. In
> >>>>>>>> the
> >>>>>>>> latter case the error class indicates the reason for not
> >>>>>>>> completing
> >>>>>>>> the routine. None of the error classes returned by an routine
> >>>>>>>> impact the execution of the MPI process and do not invoke MPI
> >>>>>>>> error
> >>>>>>>> handlers. The execution of the MPI process continues as if
> >>>>>>>> the
> >>>>>>>> call would have completed. However, the MPI implementation
> >>>>>>>> is not required to check all user provided parameters; if a
> >>>>>>>> user
> >>>>>>>> passes invalid parameter values to any routine the behavior
> >>>>>>>> of
> >>>>>>>> the implementation is undefined.
> >>>>>>>>
> >>>>>>>> All MPI error classes with the prefix MPI\_T\_ must be unique
> >>>>>>>> values
> >>>>>>>> and cannot overlap with any other error codes or error
> >>>>>>>> classes returned by the MPI implementation and must follow
> >>>>>>>> the same rules and restrictions laid out in Chapter 8.4. In
> >>>>>>>> particular,
> >>>>>>>> they must satisfy:
> >>>>>>>>
> >>>>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE.
> >>>>>>>>
> >>>>>>>> Rationale:
> >>>>>>>> All MPI tool information interface functions must return
> >>>>>>>> error
> >>>>>>>> classes,
> >>>>>>>> because applications cannot portably call MPI_ERROR_CLASS
> >>>>>>>> before
> >>>>>>>> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to
> >>>>>>>> an
> >>>>>>>> error
> >>>>>>>> class.
> >>>>>>>
> >>>>>>> I can go either way (just making the minor change mention
> >>>>>>> above
> >>>>>>> and adding Adam's rational) or with the larger adjustment. I
> >>>>>>> believe those two are semantically equivalent.
> >>>>>>>
> >>>>>>> Martin
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Jul 24, 2012, at 2:31 PM, Mohror, Kathryn wrote:
> >>>>>>>
> >>>>>>>> I am in favor of adding Adam's rationale.
> >>>>>>>>
> >>>>>>>>> Rationale:
> >>>>>>>>> All MPI tool information interface functions must return
> >>>>>>>>> error
> >>>>>>>>> classes,
> >>>>>>>>> because applications cannot portably call MPI_ERROR_CLASS
> >>>>>>>>> before
> >>>>>>>>> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code
> >>>>>>>>> to
> >>>>>>>>> an
> >>>>>>>>> error
> >>>>>>>>> class.
> >>>>>>>>
> >>>>>>>> Kathryn
> >>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: mpi-forum-bounces at lists.mpi-forum.org
> >>>>>>>>> [mailto:mpi-forum-
> >>>>>>>>> bounces at lists.mpi-forum.org] On Behalf Of Adam T. Moody
> >>>>>>>>> Sent: Tuesday, July 24, 2012 11:23 AM
> >>>>>>>>> To: Main MPI Forum mailing list
> >>>>>>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and
> >>>>>>>>> MPI_ERR_LASTCODE
> >>>>>>>>>
> >>>>>>>>> I think we are all converging, but there is one point that I
> >>>>>>>>> wanted to
> >>>>>>>>> bring up:
> >>>>>>>>>
> >>>>>>>>>   Can one call ERROR_CLASS/STRING before MPI_INIT?
> >>>>>>>>>
> >>>>>>>>> The current standard doesn't allow this, since
> >>>>>>>>> ERROR_CLASS/STRING are
> >>>>>>>>> not in the list of functions that one can call before INIT.
> >>>>>>>>> However,
> >>>>>>>>> Rolf pointed out that the previous standard didn't need to
> >>>>>>>>> allow
> >>>>>>>>> this,
> >>>>>>>>> because there is no way to replace the default error handler
> >>>>>>>>> (which is
> >>>>>>>>> that errors are fatal) until after INIT. Thus, if one of
> >>>>>>>>> these
> >>>>>>>>> functions throws an error before INIT, it triggers the
> >>>>>>>>> ERRORS_ARE_FATAL
> >>>>>>>>> handler and never returns.
> >>>>>>>>>
> >>>>>>>>> However, since MPI_T_ errors do not kick off the error
> >>>>>>>>> handlers,
> >>>>>>>>> now we
> >>>>>>>>> have the case where error codes can be returned before
> >>>>>>>>> MPI_INIT.
> >>>>>>>>> However, again, since ERROR_CLASS/STRING are not in the list
> >>>>>>>>> of
> >>>>>>>>> functions that one can call before INIT, it is implied that
> >>>>>>>>> users cannot
> >>>>>>>>> call these functions until after MPI_INIT. It would be nice
> >>>>>>>>> to
> >>>>>>>>> add a
> >>>>>>>>> rationale statement along these lines to the latest proposed
> >>>>>>>>> text, e.g.:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> All return codes with the prefix MPI_T_ are error codes.
> >>>>>>>>> They
> >>>>>>>>> must be
> >>>>>>>>> unique values and cannot overlap with any other error codes
> >>>>>>>>> or
> >>>>>>>>> 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. In particular, they must
> >>>>>>>>> satisfy:
> >>>>>>>>>
> >>>>>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE.
> >>>>>>>>>
> >>>>>>>>> Rationale:
> >>>>>>>>> All MPI tool information interface functions must return
> >>>>>>>>> error
> >>>>>>>>> classes,
> >>>>>>>>> because applications cannot portably call MPI_ERROR_CLASS
> >>>>>>>>> before
> >>>>>>>>> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code
> >>>>>>>>> to
> >>>>>>>>> an
> >>>>>>>>> error
> >>>>>>>>> class.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Note the above is more restrictive than it needs to be,
> >>>>>>>>> since
> >>>>>>>>> it
> >>>>>>>>> seems
> >>>>>>>>> that we could allow MPI_T to return arbitrary error codes
> >>>>>>>>> *after*
> >>>>>>>>> MPI_INIT. However, it seems we're already imposing the
> >>>>>>>>> restriction that
> >>>>>>>>> they always return error classes.
> >>>>>>>>> -Adam
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Mohror, Kathryn wrote:
> >>>>>>>>>
> >>>>>>>>>> I see the meaning of classes and codes now. I was a bit
> >>>>>>>>>> confused by the
> >>>>>>>>> wording in 8.4. I still think it's a bit weird that
> >>>>>>>>> everywhere
> >>>>>>>>> else in the standard,
> >>>>>>>>> the codes returned need to be converted to classes to get a
> >>>>>>>>> portable
> >>>>>>>>> understanding of the error, but in MPI_T we will return
> >>>>>>>>> classes,
> >>>>>>>>> so the meaning
> >>>>>>>>> is already known without conversion.
> >>>>>>>>>>
> >>>>>>>>>> However, that said, Bronis' wording of Rolf's suggested
> >>>>>>>>>> change
> >>>>>>>>>> seems to
> >>>>>>>>> make that distinction clearer. I am okay with Bronis' text:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> All return codes with the prefix MPI_T_ are error codes.
> >>>>>>>>>>> They
> >>>>>>>>>>> must be
> >>>>>>>>>>>  unique values and cannot overlap with any other error
> >>>>>>>>>>>  codes
> >>>>>>>>>>>  or 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. In particular, they must
> >>>>>>>>>>>  satisfy:
> >>>>>>>>>>>
> >>>>>>>>>>>     0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Kathryn
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>> From: mpi-forum-bounces at lists.mpi-forum.org
> >>>>>>>>>>> [mailto:mpi-forum-
> >>>>>>>>>>> bounces at lists.mpi-forum.org] On Behalf Of William Gropp
> >>>>>>>>>>> Sent: Tuesday, July 24, 2012 8:31 AM
> >>>>>>>>>>> To: Main MPI Forum mailing list
> >>>>>>>>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and
> >>>>>>>>>>> MPI_ERR_LASTCODE
> >>>>>>>>>>>
> >>>>>>>>>>> MPI error codes, combined with MPI_Error_string, permit an
> >>>>>>>>>>> MPI
> >>>>>>>>>>> implementation to return a instance-specific and detailed
> >>>>>>>>>>> error message.
> >>>>>>>>> Error
> >>>>>>>>>>> classes, like Unix error codes, have only slightly more
> >>>>>>>>>>> information that
> >>>>>>>>>>> "something went wrong".
> >>>>>>>>>>>
> >>>>>>>>>>> Because MPI error classes are error codes, its possible to
> >>>>>>>>>>> return the error
> >>>>>>>>> class;
> >>>>>>>>>>> this can be used before Init and after Finalize now. But
> >>>>>>>>>>> between Init and
> >>>>>>>>>>> Finalize, codes permit but do not require an
> >>>>>>>>>>> implementation
> >>>>>>>>>>> to
> >>>>>>>>>>> return more
> >>>>>>>>>>> helpful information. I see no reason to require the MPI_T
> >>>>>>>>>>> interface to be
> >>>>>>>>> less
> >>>>>>>>>>> user-friendly than the rest of the MPI interface. However,
> >>>>>>>>>>> leaving this for
> >>>>>>>>> 3.1
> >>>>>>>>>>> might make sense.
> >>>>>>>>>>>
> >>>>>>>>>>> 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 23, 2012, at 3:05 PM, Mohror, Kathryn wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> I have some concerns over this.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> 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.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>> If we are going to treat MPI_T error codes the same way
> >>>>>>>>>>>> they
> >>>>>>>>>>>> are in the rest
> >>>>>>>>> of
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>> the standard, does it make sense to say that "only classes
> >>>>>>>>>>> are
> >>>>>>>>>>> returned" by
> >>>>>>>>>>> MPI_T calls? I think that MPI calls return codes and the
> >>>>>>>>>>> codes
> >>>>>>>>>>> are translated
> >>>>>>>>> to
> >>>>>>>>>>> classes by the MPI_ERROR_CLASS function.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> If MPI_ERROR_CLASS and MPI_ERROR_STRING are not available
> >>>>>>>>>>>> before
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>> MPI_Init, then this may be a hardship on tools. I imagine
> >>>>>>>>>>> many
> >>>>>>>>>>> tools doing a
> >>>>>>>>>>> significant amount of set up before MPI_Init to avoid
> >>>>>>>>>>> overhead. However, if
> >>>>>>>>>>> there is no information about what the return codes mean,
> >>>>>>>>>>> then
> >>>>>>>>>>> tools may
> >>>>>>>>> have
> >>>>>>>>>>> difficulty.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> Possibly it makes more sense to treat MPI_T return values
> >>>>>>>>>>>> differently than
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>> MPI calls? Could the MPI_T return values be a set of
> >>>>>>>>>>> defined
> >>>>>>>>>>> codes instead?
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> Does anyone have different insight on error codes vs
> >>>>>>>>>>>> classes?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Kathryn
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>> From: mpi-forum-bounces at lists.mpi-forum.org
> >>>>>>>>>>>>> [mailto:mpi-forum-
> >>>>>>>>>>>>> bounces at lists.mpi-forum.org] On Behalf Of Bronis R. de
> >>>>>>>>>>>>> Supinski
> >>>>>>>>>>>>> Sent: Monday, July 23, 2012 10:37 AM
> >>>>>>>>>>>>> To: Main MPI Forum mailing list
> >>>>>>>>>>>>> Subject: 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" <schulzm at llnl.gov>
> >>>>>>>>>>>>>>>>> To: "Main MPI Forum mailing list"
> >>>>>>>>>>>>>>>>> <mpi-forum at lists.mpi-forum.org>
> >>>>>>>>>>>>>>>>> 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" <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)
> >>>>>>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>>>>>> mpi-forum mailing list
> >>>>>>>>>>>>>>>>>> mpi-forum at lists.mpi-forum.org
> >>>>>>>>>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>> ____________________________________________________________________
> >>>>>>>>> __
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>> __
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Martin Schulz, schulzm at llnl.gov,
> >>>>>>>>>>>>>>>>> http://people.llnl.gov/schulzm
> >>>>>>>>>>>>>>>>> CASC @ Lawrence Livermore National Laboratory,
> >>>>>>>>>>>>>>>>> Livermore, USA
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>>>>> 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)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>> ____________________________________________________________________
> >>>>>>>>> __
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>> __
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Martin Schulz, schulzm at llnl.gov,
> >>>>>>>>>>>>>>> http://people.llnl.gov/schulzm
> >>>>>>>>>>>>>>> CASC @ Lawrence Livermore National Laboratory,
> >>>>>>>>>>>>>>> Livermore,
> >>>>>>>>>>>>>>> USA
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>>> mpi-forum mailing list
> >>>>>>>>>>>>>>> mpi-forum at lists.mpi-forum.org
> >>>>>>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>> mpi-forum mailing list
> >>>>>>>>>>>>>> mpi-forum at lists.mpi-forum.org
> >>>>>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>> mpi-forum mailing list
> >>>>>>>>>>>>> mpi-forum at lists.mpi-forum.org
> >>>>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>> mpi-forum mailing list
> >>>>>>>>>>>> mpi-forum at lists.mpi-forum.org
> >>>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> mpi-forum mailing list
> >>>>>>>>>>> mpi-forum at lists.mpi-forum.org
> >>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> mpi-forum mailing list
> >>>>>>>>>> mpi-forum at lists.mpi-forum.org
> >>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> mpi-forum mailing list
> >>>>>>>>> mpi-forum at lists.mpi-forum.org
> >>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> mpi-forum mailing list
> >>>>>>>> mpi-forum at lists.mpi-forum.org
> >>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> >>>>>>>
> >>>>>>> ________________________________________________________________________
> >>>>>>> Martin Schulz, schulzm at llnl.gov,
> >>>>>>> http://people.llnl.gov/schulzm
> >>>>>>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> mpi-forum mailing list
> >>>>>>> mpi-forum at lists.mpi-forum.org
> >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> >>>>>>>
> >>>>>
> >>>>> ________________________________________________________________________
> >>>>> Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
> >>>>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> _______________________________________________
> >>>> 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)
> >>>
> >
> > --
> > 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)
> >

-- 
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