The latest text is fine with me.

Kathryn

On 7/25/2012 6:10 AM, Rolf Rabenseifner wrote:
> 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" <[email protected]>
>> To: "Rolf Rabenseifner" <[email protected]>
>> Cc: "Martin Schulz" <[email protected]>, "Kathryn Mohror" <[email protected]>, "Dave Goodell" <[email protected]>,
>> "Adam T. Moody" <[email protected]>, "Main MPI Forum mailing list" <[email protected]>
>> 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" <[email protected]>
>>>> To: "Rolf Rabenseifner" <[email protected]>
>>>> Cc: "Martin Schulz" <[email protected]>, "Kathryn Mohror"
>>>> <[email protected]>, "Dave Goodell" <[email protected]>,
>>>> "Adam T. Moody" <[email protected]>, "Main MPI Forum mailing list"
>>>> <[email protected]>
>>>> 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" <[email protected]>
>>>>>> To: "Martin Schulz" <[email protected]>
>>>>>> Cc: "Main MPI Forum mailing list" <[email protected]>
>>>>>> 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: [email protected]
>>>>>>>>>>> [mailto:mpi-forum-
>>>>>>>>>>> [email protected]] 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: [email protected]
>>>>>>>>>>>>> [mailto:mpi-forum-
>>>>>>>>>>>>> [email protected]] 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: [email protected]
>>>>>>>>>>>>>>> [mailto:mpi-forum-
>>>>>>>>>>>>>>> [email protected]] 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" <[email protected]>
>>>>>>>>>>>>>>>>>>> To: "Main MPI Forum mailing list"
>>>>>>>>>>>>>>>>>>> <[email protected]>
>>>>>>>>>>>>>>>>>>> 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" <[email protected]>
>>>>>>>>>>>>>>>>>>>>> To: "Main MPI Forum mailing list"
>>>>>>>>>>>>>>>>>>>>> <[email protected]
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> forum.org>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Cc: "Rolf Rabenseifner" <[email protected]>
>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>> [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
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> ____________________________________________________________________
>>>>>>>>>>> __
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> __
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Martin Schulz, [email protected],
>>>>>>>>>>>>>>>>>>> http://people.llnl.gov/schulzm
>>>>>>>>>>>>>>>>>>> CASC @ Lawrence Livermore National Laboratory,
>>>>>>>>>>>>>>>>>>> Livermore, USA
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>> mpi-forum mailing list
>>>>>>>>>>>>>>>>>>> [email protected]
>>>>>>>>>>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> 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)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> ____________________________________________________________________
>>>>>>>>>>> __
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> __
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Martin Schulz, [email protected],
>>>>>>>>>>>>>>>>> http://people.llnl.gov/schulzm
>>>>>>>>>>>>>>>>> CASC @ Lawrence Livermore National Laboratory,
>>>>>>>>>>>>>>>>> Livermore,
>>>>>>>>>>>>>>>>> USA
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>> mpi-forum mailing list
>>>>>>>>>>>>>>>>> [email protected]
>>>>>>>>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> mpi-forum mailing list
>>>>>>>>>>>>>>>> [email protected]
>>>>>>>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> mpi-forum mailing list
>>>>>>>>>>>>>>> [email protected]
>>>>>>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> mpi-forum mailing list
>>>>>>>>>>>>>> [email protected]
>>>>>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> mpi-forum mailing list
>>>>>>>>>>>>> [email protected]
>>>>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> mpi-forum mailing list
>>>>>>>>>>>> [email protected]
>>>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> mpi-forum mailing list
>>>>>>>>>>> [email protected]
>>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> mpi-forum mailing list
>>>>>>>>>> [email protected]
>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>>>>>>>>>
>>>>>>>>> ________________________________________________________________________
>>>>>>>>> Martin Schulz, [email protected],
>>>>>>>>> http://people.llnl.gov/schulzm
>>>>>>>>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> mpi-forum mailing list
>>>>>>>>> [email protected]
>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>>>>>>>>>
>>>>>>>
>>>>>>> ________________________________________________________________________
>>>>>>> Martin Schulz, [email protected], http://people.llnl.gov/schulzm
>>>>>>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> mpi-forum mailing list
>>>>>> [email protected]
>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>>>>>
>>>>> --
>>>>> 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)
>>>>>
>>>
>>> --
>>> 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)
>>>
>
> --
> 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)
>

_____________________________________________________________________
Kathryn Mohror, [email protected], http://people.llnl.gov/mohror1
CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA