Also with me.

-Dave

On Jul 25, 2012, at 10:28 AM CDT, Kathryn Mohror wrote:

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