[Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE
Dave Goodell
goodell at mcs.anl.gov
Wed Jul 25 12:54:38 CDT 2012
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" <bronis at llnl.gov>
>>> To: "Rolf Rabenseifner" <rabenseifner at hlrs.de>
>>> Cc: "Martin Schulz" <schulzm at llnl.gov>, "Kathryn Mohror" <mohror1 at llnl.gov>, "Dave Goodell" <goodell at mcs.anl.gov>,
>>> "Adam T. Moody" <moody20 at llnl.gov>, "Main MPI Forum mailing list" <mpi-forum at lists.mpi-forum.org>
>>> Sent: Wednesday, July 25, 2012 2:54:46 PM
>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE
>>> Rolf:
>>>
>>> Um, not quite. The first paragraph should read "error
>>> codes", not "error classes". The routines return error
>>> codes, all of which happen to be error classes.
>>>
>>> I have modified below.
>>>
>>> Bronis
>>>
>>>
>>> On Wed, 25 Jul 2012, Rolf Rabenseifner wrote:
>>>
>>>> Bronis, Martin, Adam, Kathryn, Dave, and all,
>>>>
>>>> Okay, now I understand - I thought Martin's arguments were okay
>>>> for shortening the text - but the original long form is more
>>>> consistent.
>>>>
>>>> Can we therefore agree on the text below.
>>>> It is the text from Bronis plus Adams rationale plus the other
>>>> changes from the original mail.
>>>>
>>>> I would like to have enough okays.
>>>>
>>>> ------------------------------
>>>> | Changed and new text is marked with a bar.
>>>> -------------------------
>>>> 1) Sect 14.3.9 "Return Codes for the MPI tool information interface"
>>>> reads
>>>>
>>>> All functions defined as part of the MPI tool information
>>>> interface
>>>> return an integer return code (see Table 14.5) to indicate whether
>>>> the function was completed successfully or was aborted. In the
>>>> latter case the return code indicates the reason for not
>>>> completing
>>>> the routine. None of the return codes returned by an routine
>>>> impact the execution of the MPI process and do not invoke MPI
>>>> error
>>>> handlers. The execution of the MPI process continues as if the
>>>> call would have completed. However, the MPI implementation
>>>> is not required to check all user provided parameters; if a user
>>>> passes invalid parameter values to any routine the behavior of
>>>> the implementation is undefined.
>>>>
>>>> All return codes with the prefix MPI_T_ must be unique values and
>>>> cannot overlap with any other return values returned by the MPI
>>>> implementation.
>>>>
>>>> but should read
>>>>
>>> All functions defined as part of the MPI tool information interface
>>> return an integer error code (see Table 14.5) to indicate whether
>>> the function was completed successfully or was aborted. In the
>>> latter case the error code indicates the reason for not completing
>>> the routine. None of the error codes returned by an routine
>>> impact the execution of the MPI process and do not invoke MPI error
>>> handlers. The execution of the MPI process continues as if the
>>> call would have completed. However, the MPI implementation
>>> is not required to check all user provided parameters; if a user
>>> passes invalid parameter values to any routine the behavior of
>>> the implementation is undefined.
>>>
>>> All return codes with the prefix MPI_T_ are error codes. They must be
>>> unique values and cannot overlap with any other error codes or error
>>> classes returned by the MPI implementation. Further, they shall be
>>> treated as MPI error classes as defined in Chapter 8.4 and follow
>>> the same rules and restrictions. In particular, they must satisfy:
>>>
>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE.
>>>
>>> Rationale:
>>> All MPI tool information interface functions must return error
>>> classes,
>>> because applications cannot portably call MPI_ERROR_CLASS before
>>> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to an error
>>> class. End of rationale.
>>>
>>>
>>>
>>>>
>>>> 2) A.1.1 the first three tables are headed by
>>>>
>>>> Error classes
>>>> Error classes (continued)
>>>> Return Codes for the MPI tool information interface
>>>>
>>>> and these lines should read
>>>>
>>>> Error classes
>>>> Error classes (continued)
>>>> | Error classes (continued)
>>>>
>>>> 3) The last line of A.1.1, 2nd table
>>>>
>>>> MPI_ERR_LASTCODE
>>>>
>>>> should move after the last MPI_T_ERR_... code in the 3rd table.
>>>> ------------------------------
>>>>
>>>> Best regards
>>>> Rolf
>>>>
>>>> ----- Original Message -----
>>>>> From: "Bronis R. de Supinski" <bronis at llnl.gov>
>>>>> To: "Rolf Rabenseifner" <rabenseifner at hlrs.de>
>>>>> Cc: "Martin Schulz" <schulzm at llnl.gov>, "Kathryn Mohror"
>>>>> <mohror1 at llnl.gov>, "Dave Goodell" <goodell at mcs.anl.gov>,
>>>>> "Adam T. Moody" <moody20 at llnl.gov>, "Main MPI Forum mailing list"
>>>>> <mpi-forum at lists.mpi-forum.org>
>>>>> Sent: Wednesday, July 25, 2012 12:07:55 PM
>>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE
>>>>> Rolf:
>>>>>
>>>>> Hmm. Aoparently you did not follow. I do not agree to
>>>>> Martin's change to my suggested wording. I think
>>>>> stating that they return error classes is confusing
>>>>> and not consistent with Section 8.4. That section states:
>>>>>
>>>>> ------------------
>>>>>
>>>>> The error codes returned by MPI are left entirely to the
>>>>> implementation
>>>>> (with the exception of MPI_SUCCESS). This is done to allow an
>>>>> implementation
>>>>> to provide as much information as possible in the error code (for
>>>>> use
>>>>> with
>>>>> MPI_ERROR_STRING).
>>>>>
>>>>> To make it possible for an application to interpret an error code,
>>>>> the
>>>>> routine MPI_ERROR_CLASS converts any error code into one of a small
>>>>> set of
>>>>> standard error codes, called error classes. Valid error classes are
>>>>> shown
>>>>> in Table 8.1 and Table 8.2.
>>>>>
>>>>> ------------------
>>>>>
>>>>> This passage clearly states that all MPI routines return error
>>>>> codes
>>>>> (as
>>>>> is consistent with correct design). To obtain an error code, one
>>>>> MUST
>>>>> use MPI_ERROR_CLASS. Martin's change incorrectly makes MPI_T
>>>>> functions
>>>>> return error classes. My wording instead has them return error
>>>>> codes,
>>>>> consistent with existing practice. My wording merely states that
>>>>> they
>>>>> are ALSO error classes.
>>>>>
>>>>> As stated previously, I object to Martin's incorrect
>>>>> simplification,
>>>>> which was the cause of the confusion that generated significant
>>>>> discussion on this topic. We should not codify it.
>>>>>
>>>>> Bronis
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, 25 Jul 2012, Rolf Rabenseifner wrote:
>>>>>
>>>>>> Martin, Kathryn, Bronis, Dave, Adam, and all,
>>>>>>
>>>>>> I try to sum up the current proposed text change.
>>>>>> I hope I caught all your proposed text changes.
>>>>>>
>>>>>> If I understand correctly,
>>>>>> then there is no further objection and the whole
>>>>>> tools chapter committee is in favor to do this change.
>>>>>>
>>>>>> My review: I is now fully consistent with the existing
>>>>>> MPI error handling and fulfills all needs of
>>>>>> the MPI_T_ routines.
>>>>>>
>>>>>> Please give your okay as soon as possible.
>>>>>>
>>>>>> As soon as I get the final okay from you all,
>>>>>> I'll execute the change in one consistent svn step in tools and
>>>>>> appLang.
>>>>>>
>>>>>> -------------------------
>>>>>> | Changed and new text is marked with a bar.
>>>>>> -------------------------
>>>>>> 1) Sect 14.3.9 "Return Codes for the MPI tool information
>>>>>> interface"
>>>>>> reads
>>>>>>
>>>>>> All functions defined as part of the MPI tool information
>>>>>> interface
>>>>>> return an integer return code (see Table 14.5) to indicate
>>>>>> whether
>>>>>> the function was completed successfully or was aborted. In the
>>>>>> latter case the return code indicates the reason for not
>>>>>> completing
>>>>>> the routine. None of the return codes returned by an routine
>>>>>> impact the execution of the MPI process and do not invoke MPI
>>>>>> error
>>>>>> handlers. The execution of the MPI process continues as if the
>>>>>> call would have completed. However, the MPI implementation
>>>>>> is not required to check all user provided parameters; if a user
>>>>>> passes invalid parameter values to any routine the behavior of
>>>>>> the implementation is undefined.
>>>>>>
>>>>>> All return codes with the prefix MPI_T_ must be unique values
>>>>>> and
>>>>>> cannot overlap with any other return values returned by the MPI
>>>>>> implementation.
>>>>>>
>>>>>> but should read
>>>>>>
>>>>>> All functions defined as part of the MPI tool information
>>>>>> interface
>>>>>> | return an MPI error class, as defined in Table 14.5, to
>>>>>> | indicate
>>>>>> | whether
>>>>>> the function was completed successfully or was aborted. In the
>>>>>> latter case the error class indicates the reason for not
>>>>>> completing
>>>>>> the routine. None of the error classes returned by an routine
>>>>>> impact the execution of the MPI process and do not invoke MPI
>>>>>> error
>>>>>> handlers. The execution of the MPI process continues as if the
>>>>>> call would have completed. However, the MPI implementation
>>>>>> is not required to check all user provided parameters; if a user
>>>>>> passes invalid parameter values to any routine the behavior of
>>>>>> the implementation is undefined.
>>>>>>
>>>>>> | All MPI error classes with the prefix MPI\_T\_ must be unique
>>>>>> | values
>>>>>> | and cannot overlap with any other error codes or error
>>>>>> | classes returned by the MPI implementation and must follow
>>>>>> | the same rules and restrictions laid out in Chapter 8.4. In
>>>>>> | particular,
>>>>>> | they must satisfy:
>>>>>> |
>>>>>> | 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE.
>>>>>> |
>>>>>> | Rationale:
>>>>>> | All MPI tool information interface functions must return error
>>>>>> | classes,
>>>>>> | because applications cannot portably call MPI_ERROR_CLASS
>>>>>> | before
>>>>>> | MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to
>>>>>> | an
>>>>>> | error
>>>>>> | class. End of rationale.
>>>>>>
>>>>>> 2) A.1.1 the first three tables are headed by
>>>>>>
>>>>>> Error classes
>>>>>> Error classes (continued)
>>>>>> Return Codes for the MPI tool information interface
>>>>>>
>>>>>> and these lines should read
>>>>>>
>>>>>> Error classes
>>>>>> Error classes (continued)
>>>>>> | Error classes (continued)
>>>>>>
>>>>>> 3) The last line of A.1.1, 2nd table
>>>>>>
>>>>>> MPI_ERR_LASTCODE
>>>>>>
>>>>>> should move after the last MPI_T_ERR_... code in the 3rd table.
>>>>>> --------------------
>>>>>>
>>>>>> Best regards
>>>>>> Rolf
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Bronis R. de Supinski" <bronis at llnl.gov>
>>>>>>> To: "Martin Schulz" <schulzm at llnl.gov>
>>>>>>> Cc: "Main MPI Forum mailing list" <mpi-forum at lists.mpi-forum.org>
>>>>>>> Sent: Wednesday, July 25, 2012 7:15:59 AM
>>>>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and
>>>>>>> MPI_ERR_LASTCODE
>>>>>>> Martin:
>>>>>>>
>>>>>>> Because using the error classes wording is what caused
>>>>>>> the original confusion. Further, your wording precludes
>>>>>>> ever allowing an implementation to extend the return codes.
>>>>>>>
>>>>>>> Frankly, your opinion is that calling them error classes
>>>>>>> is less confusing but we have already seen that experts
>>>>>>> are confused by that.
>>>>>>>
>>>>>>> As to your second suggestion, it would be simpler if you
>>>>>>> showed just the change to make it clearer that it is just
>>>>>>> a ticket 0 change instead of asking people to wade through
>>>>>>> the comparison of two lengthy passages.
>>>>>>>
>>>>>>> Bronis
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, 24 Jul 2012, Schulz, Martin wrote:
>>>>>>>
>>>>>>>> Hi Bronis,
>>>>>>>>
>>>>>>>> On Jul 25, 2012, at 12:19 AM, Bronis R. de Supinski wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Martin:
>>>>>>>>>
>>>>>>>>> You are incorrect. The text in 8.4 explicitly states that
>>>>>>>>> all error classes are error codes. My text was straightforward
>>>>>>>>
>>>>>>>> Yes, that's what I said as well. Error classes are a subset of
>>>>>>>> error
>>>>>>>> codes.
>>>>>>>>
>>>>>>>>> and not as long and awkward as your suggestion that attempts
>>>>>>>>
>>>>>>>> In the first suggestion I just replaced one word and then cut
>>>>>>>> duplicate text (the new version is shorter) - your text said
>>>>>>>> that
>>>>>>>> all return codes are error codes and I still think this is not
>>>>>>>> quite
>>>>>>>> correct or at least ambiguous. We are defining their values with
>>>>>>>> constants in the Table, something that we can't do for error
>>>>>>>> codes
>>>>>>>> that are not classes. Hence, I just suggested to replace "All
>>>>>>>> return
>>>>>>>> codes with the prefix MPI_T_ are error codes." with "All return
>>>>>>>> codes with the prefix MPI_T_ are error classes.". Otherwise we
>>>>>>>> are
>>>>>>>> first saying that return codes can be (arbitrary) error codes,
>>>>>>>> but
>>>>>>>> then we state they should behave as classes. Why not say they
>>>>>>>> are
>>>>>>>> classes from the beginning?
>>>>>>>>
>>>>>>>>> to make a non-existent distinction. I vote for Adam's suggested
>>>>>>>>> rationale that extended my wording.
>>>>>>>>
>>>>>>>> In the second suggestion, I was actually trying to get rid of
>>>>>>>> the
>>>>>>>> term MPI_T return codes, since this has caused the confusion. I
>>>>>>>> think this is cleaner (and the text overall is actually shorter
>>>>>>>> -
>>>>>>>> I
>>>>>>>> just quoted the whole subsection 14.3.9 for context). The text
>>>>>>>> is
>>>>>>>> itself is virtually unchanged from the approved ticket. However,
>>>>>>>> I
>>>>>>>> have said that I am fine with either version.
>>>>>>>>
>>>>>>>> Martin
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Bronis
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, 24 Jul 2012, Schulz, Martin wrote:
>>>>>>>>>
>>>>>>>>>> I agree with Adam's rational - that is a good addition.
>>>>>>>>>>
>>>>>>>>>> However, I don't think the last proposal (which was, I believe
>>>>>>>>>> in
>>>>>>>>>> Bronis's email)
>>>>>>>>>>
>>>>>>>>>>> All return codes with the prefix MPI_T_ are error codes.
>>>>>>>>>>> They
>>>>>>>>>>> must be
>>>>>>>>>>> unique values and cannot overlap with any other error codes
>>>>>>>>>>> or
>>>>>>>>>>> error
>>>>>>>>>>> classes returned by the MPI implementation. Further, they
>>>>>>>>>>> shall
>>>>>>>>>>> be
>>>>>>>>>>> treated as MPI error classes as defined in Chapter 8.4 and
>>>>>>>>>>> follow
>>>>>>>>>>> the same rules and restrictions. In particular, they must
>>>>>>>>>>> satisfy:
>>>>>>>>>>>
>>>>>>>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> is consistent with 8.4 (although that chapter is not quite
>>>>>>>>>> consistent in itself, but that's a different issue). If we
>>>>>>>>>> want
>>>>>>>>>> to
>>>>>>>>>> fully embed the MPI_T return codes into the MPI error
>>>>>>>>>> class/code
>>>>>>>>>> terminology (which I agree with), then MPI_T return codes are
>>>>>>>>>> not
>>>>>>>>>> error codes, but classes, since we are defining their values.
>>>>>>>>>> Codes that are not classes are left to the implementation. 8.4
>>>>>>>>>> also states that MPI routines can return classes and that
>>>>>>>>>> classes
>>>>>>>>>> are a subset of codes. Hence, I think the following is
>>>>>>>>>> correct:
>>>>>>>>>>
>>>>>>>>>>> All return codes with the prefix MPI_T_ are error classes.
>>>>>>>>>>> They
>>>>>>>>>>> must be
>>>>>>>>>>> unique values and cannot overlap with any other error codes
>>>>>>>>>>> or
>>>>>>>>>>> error
>>>>>>>>>>> classes returned by the MPI implementation. Further, they
>>>>>>>>>>> shall
>>>>>>>>>>> follow
>>>>>>>>>>> the same rules and restrictions as defined in Chapter 8.4. In
>>>>>>>>>>> particular,
>>>>>>>>>>> they must satisfy:
>>>>>>>>>>>
>>>>>>>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE.
>>>>>>>>>>
>>>>>>>>>> However, this is starting to get awkward and repetitive.
>>>>>>>>>> Hence,
>>>>>>>>>> we
>>>>>>>>>> may want to rewrite 14.3.9 as follows:
>>>>>>>>>>
>>>>>>>>>> Old text (currently in approved for 14.3.9):
>>>>>>>>>>
>>>>>>>>>>> All functions defined as part of the MPI tool information
>>>>>>>>>>> interface
>>>>>>>>>>> return an integer return code (see Table 14.5) to indicate
>>>>>>>>>>> whether
>>>>>>>>>>> the function was completed successfully or was aborted. In
>>>>>>>>>>> the
>>>>>>>>>>> latter case the return code indicates the reason for not
>>>>>>>>>>> completing
>>>>>>>>>>> the routine. None of the return codes returned by an routine
>>>>>>>>>>> impact the execution of the MPI process and do not invoke MPI
>>>>>>>>>>> error
>>>>>>>>>>> handlers. The execution of the MPI process continues as if
>>>>>>>>>>> the
>>>>>>>>>>> call would have completed. However, the \MPI/ implementation
>>>>>>>>>>> is not required to check all user provided parameters; if a
>>>>>>>>>>> user
>>>>>>>>>>> passes invalid parameter values to any routine the behavior
>>>>>>>>>>> of
>>>>>>>>>>> the implementation is undefined.
>>>>>>>>>>>
>>>>>>>>>>> All return codes with the prefix MPI\_T\_ must be unique
>>>>>>>>>>> values
>>>>>>>>>>> and cannot overlap with any other return values returned by
>>>>>>>>>>> the \MPI/ implementation.
>>>>>>>>>>
>>>>>>>>>> New suggested text:
>>>>>>>>>>
>>>>>>>>>>> All functions defined as part of the MPI tool information
>>>>>>>>>>> interface
>>>>>>>>>>> return an MPI error class, as defined in Table 14.5, to
>>>>>>>>>>> indicate
>>>>>>>>>>> whether
>>>>>>>>>>> the function was completed successfully or was aborted. In
>>>>>>>>>>> the
>>>>>>>>>>> latter case the error class indicates the reason for not
>>>>>>>>>>> completing
>>>>>>>>>>> the routine. None of the error classes returned by an routine
>>>>>>>>>>> impact the execution of the MPI process and do not invoke MPI
>>>>>>>>>>> error
>>>>>>>>>>> handlers. The execution of the MPI process continues as if
>>>>>>>>>>> the
>>>>>>>>>>> call would have completed. However, the MPI implementation
>>>>>>>>>>> is not required to check all user provided parameters; if a
>>>>>>>>>>> user
>>>>>>>>>>> passes invalid parameter values to any routine the behavior
>>>>>>>>>>> of
>>>>>>>>>>> the implementation is undefined.
>>>>>>>>>>>
>>>>>>>>>>> All MPI error classes with the prefix MPI\_T\_ must be unique
>>>>>>>>>>> values
>>>>>>>>>>> and cannot overlap with any other error codes or error
>>>>>>>>>>> classes returned by the MPI implementation and must follow
>>>>>>>>>>> the same rules and restrictions laid out in Chapter 8.4. In
>>>>>>>>>>> particular,
>>>>>>>>>>> they must satisfy:
>>>>>>>>>>>
>>>>>>>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE.
>>>>>>>>>>>
>>>>>>>>>>> Rationale:
>>>>>>>>>>> All MPI tool information interface functions must return
>>>>>>>>>>> error
>>>>>>>>>>> classes,
>>>>>>>>>>> because applications cannot portably call MPI_ERROR_CLASS
>>>>>>>>>>> before
>>>>>>>>>>> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code to
>>>>>>>>>>> an
>>>>>>>>>>> error
>>>>>>>>>>> class.
>>>>>>>>>>
>>>>>>>>>> I can go either way (just making the minor change mention
>>>>>>>>>> above
>>>>>>>>>> and adding Adam's rational) or with the larger adjustment. I
>>>>>>>>>> believe those two are semantically equivalent.
>>>>>>>>>>
>>>>>>>>>> Martin
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Jul 24, 2012, at 2:31 PM, Mohror, Kathryn wrote:
>>>>>>>>>>
>>>>>>>>>>> I am in favor of adding Adam's rationale.
>>>>>>>>>>>
>>>>>>>>>>>> Rationale:
>>>>>>>>>>>> All MPI tool information interface functions must return
>>>>>>>>>>>> error
>>>>>>>>>>>> classes,
>>>>>>>>>>>> because applications cannot portably call MPI_ERROR_CLASS
>>>>>>>>>>>> before
>>>>>>>>>>>> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code
>>>>>>>>>>>> to
>>>>>>>>>>>> an
>>>>>>>>>>>> error
>>>>>>>>>>>> class.
>>>>>>>>>>>
>>>>>>>>>>> Kathryn
>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: mpi-forum-bounces at lists.mpi-forum.org
>>>>>>>>>>>> [mailto:mpi-forum-
>>>>>>>>>>>> bounces at lists.mpi-forum.org] On Behalf Of Adam T. Moody
>>>>>>>>>>>> Sent: Tuesday, July 24, 2012 11:23 AM
>>>>>>>>>>>> To: Main MPI Forum mailing list
>>>>>>>>>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and
>>>>>>>>>>>> MPI_ERR_LASTCODE
>>>>>>>>>>>>
>>>>>>>>>>>> I think we are all converging, but there is one point that I
>>>>>>>>>>>> wanted to
>>>>>>>>>>>> bring up:
>>>>>>>>>>>>
>>>>>>>>>>>> Can one call ERROR_CLASS/STRING before MPI_INIT?
>>>>>>>>>>>>
>>>>>>>>>>>> The current standard doesn't allow this, since
>>>>>>>>>>>> ERROR_CLASS/STRING are
>>>>>>>>>>>> not in the list of functions that one can call before INIT.
>>>>>>>>>>>> However,
>>>>>>>>>>>> Rolf pointed out that the previous standard didn't need to
>>>>>>>>>>>> allow
>>>>>>>>>>>> this,
>>>>>>>>>>>> because there is no way to replace the default error handler
>>>>>>>>>>>> (which is
>>>>>>>>>>>> that errors are fatal) until after INIT. Thus, if one of
>>>>>>>>>>>> these
>>>>>>>>>>>> functions throws an error before INIT, it triggers the
>>>>>>>>>>>> ERRORS_ARE_FATAL
>>>>>>>>>>>> handler and never returns.
>>>>>>>>>>>>
>>>>>>>>>>>> However, since MPI_T_ errors do not kick off the error
>>>>>>>>>>>> handlers,
>>>>>>>>>>>> now we
>>>>>>>>>>>> have the case where error codes can be returned before
>>>>>>>>>>>> MPI_INIT.
>>>>>>>>>>>> However, again, since ERROR_CLASS/STRING are not in the list
>>>>>>>>>>>> of
>>>>>>>>>>>> functions that one can call before INIT, it is implied that
>>>>>>>>>>>> users cannot
>>>>>>>>>>>> call these functions until after MPI_INIT. It would be nice
>>>>>>>>>>>> to
>>>>>>>>>>>> add a
>>>>>>>>>>>> rationale statement along these lines to the latest proposed
>>>>>>>>>>>> text, e.g.:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> All return codes with the prefix MPI_T_ are error codes.
>>>>>>>>>>>> They
>>>>>>>>>>>> must be
>>>>>>>>>>>> unique values and cannot overlap with any other error codes
>>>>>>>>>>>> or
>>>>>>>>>>>> error
>>>>>>>>>>>> classes returned by the MPI implementation. Further, they
>>>>>>>>>>>> shall
>>>>>>>>>>>> be
>>>>>>>>>>>> treated as MPI error classes as defined in Chapter 8.4 and
>>>>>>>>>>>> follow
>>>>>>>>>>>> the same rules and restrictions. In particular, they must
>>>>>>>>>>>> satisfy:
>>>>>>>>>>>>
>>>>>>>>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE.
>>>>>>>>>>>>
>>>>>>>>>>>> Rationale:
>>>>>>>>>>>> All MPI tool information interface functions must return
>>>>>>>>>>>> error
>>>>>>>>>>>> classes,
>>>>>>>>>>>> because applications cannot portably call MPI_ERROR_CLASS
>>>>>>>>>>>> before
>>>>>>>>>>>> MPI_INIT or MPI_INIT_THREAD to map an arbitrary error code
>>>>>>>>>>>> to
>>>>>>>>>>>> an
>>>>>>>>>>>> error
>>>>>>>>>>>> class.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Note the above is more restrictive than it needs to be,
>>>>>>>>>>>> since
>>>>>>>>>>>> it
>>>>>>>>>>>> seems
>>>>>>>>>>>> that we could allow MPI_T to return arbitrary error codes
>>>>>>>>>>>> *after*
>>>>>>>>>>>> MPI_INIT. However, it seems we're already imposing the
>>>>>>>>>>>> restriction that
>>>>>>>>>>>> they always return error classes.
>>>>>>>>>>>> -Adam
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Mohror, Kathryn wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I see the meaning of classes and codes now. I was a bit
>>>>>>>>>>>>> confused by the
>>>>>>>>>>>> wording in 8.4. I still think it's a bit weird that
>>>>>>>>>>>> everywhere
>>>>>>>>>>>> else in the standard,
>>>>>>>>>>>> the codes returned need to be converted to classes to get a
>>>>>>>>>>>> portable
>>>>>>>>>>>> understanding of the error, but in MPI_T we will return
>>>>>>>>>>>> classes,
>>>>>>>>>>>> so the meaning
>>>>>>>>>>>> is already known without conversion.
>>>>>>>>>>>>>
>>>>>>>>>>>>> However, that said, Bronis' wording of Rolf's suggested
>>>>>>>>>>>>> change
>>>>>>>>>>>>> seems to
>>>>>>>>>>>> make that distinction clearer. I am okay with Bronis' text:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> All return codes with the prefix MPI_T_ are error codes.
>>>>>>>>>>>>>> They
>>>>>>>>>>>>>> must be
>>>>>>>>>>>>>> unique values and cannot overlap with any other error
>>>>>>>>>>>>>> codes
>>>>>>>>>>>>>> or error
>>>>>>>>>>>>>> classes returned by the MPI implementation. Further, they
>>>>>>>>>>>>>> shall be
>>>>>>>>>>>>>> treated as MPI error classes as defined in Chapter 8.4
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> follow
>>>>>>>>>>>>>> the same rules and restrictions. In particular, they must
>>>>>>>>>>>>>> satisfy:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq MPI_ERR_LASTCODE.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Kathryn
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: mpi-forum-bounces at lists.mpi-forum.org
>>>>>>>>>>>>>> [mailto:mpi-forum-
>>>>>>>>>>>>>> bounces at lists.mpi-forum.org] On Behalf Of William Gropp
>>>>>>>>>>>>>> Sent: Tuesday, July 24, 2012 8:31 AM
>>>>>>>>>>>>>> To: Main MPI Forum mailing list
>>>>>>>>>>>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and
>>>>>>>>>>>>>> MPI_ERR_LASTCODE
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> MPI error codes, combined with MPI_Error_string, permit an
>>>>>>>>>>>>>> MPI
>>>>>>>>>>>>>> implementation to return a instance-specific and detailed
>>>>>>>>>>>>>> error message.
>>>>>>>>>>>> Error
>>>>>>>>>>>>>> classes, like Unix error codes, have only slightly more
>>>>>>>>>>>>>> information that
>>>>>>>>>>>>>> "something went wrong".
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Because MPI error classes are error codes, its possible to
>>>>>>>>>>>>>> return the error
>>>>>>>>>>>> class;
>>>>>>>>>>>>>> this can be used before Init and after Finalize now. But
>>>>>>>>>>>>>> between Init and
>>>>>>>>>>>>>> Finalize, codes permit but do not require an
>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> return more
>>>>>>>>>>>>>> helpful information. I see no reason to require the MPI_T
>>>>>>>>>>>>>> interface to be
>>>>>>>>>>>> less
>>>>>>>>>>>>>> user-friendly than the rest of the MPI interface. However,
>>>>>>>>>>>>>> leaving this for
>>>>>>>>>>>> 3.1
>>>>>>>>>>>>>> might make sense.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Bill
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> William Gropp
>>>>>>>>>>>>>> Director, Parallel Computing Institute
>>>>>>>>>>>>>> Deputy Director for Research
>>>>>>>>>>>>>> Institute for Advanced Computing Applications and
>>>>>>>>>>>>>> Technologies
>>>>>>>>>>>>>> Paul and Cynthia Saylor Professor of Computer Science
>>>>>>>>>>>>>> University of Illinois Urbana-Champaign
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Jul 23, 2012, at 3:05 PM, Mohror, Kathryn wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have some concerns over this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The topic about user-callability of MPI_ERROR_CLASS and
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> MPI_ERROR_STRING
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> outside of the initialized MPI should be revisited in
>>>>>>>>>>>>>>>> MPI-3.1.
>>>>>>>>>>>>>>>> This is not evident for the tools' developers because
>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>> know
>>>>>>>>>>>>>>>> the meaning of their MPI_T_ERR... classes and only
>>>>>>>>>>>>>>>> classes
>>>>>>>>>>>>>>>> are returned.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If we are going to treat MPI_T error codes the same way
>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>> are in the rest
>>>>>>>>>>>> of
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> the standard, does it make sense to say that "only classes
>>>>>>>>>>>>>> are
>>>>>>>>>>>>>> returned" by
>>>>>>>>>>>>>> MPI_T calls? I think that MPI calls return codes and the
>>>>>>>>>>>>>> codes
>>>>>>>>>>>>>> are translated
>>>>>>>>>>>> to
>>>>>>>>>>>>>> classes by the MPI_ERROR_CLASS function.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If MPI_ERROR_CLASS and MPI_ERROR_STRING are not available
>>>>>>>>>>>>>>> before
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> MPI_Init, then this may be a hardship on tools. I imagine
>>>>>>>>>>>>>> many
>>>>>>>>>>>>>> tools doing a
>>>>>>>>>>>>>> significant amount of set up before MPI_Init to avoid
>>>>>>>>>>>>>> overhead. However, if
>>>>>>>>>>>>>> there is no information about what the return codes mean,
>>>>>>>>>>>>>> then
>>>>>>>>>>>>>> tools may
>>>>>>>>>>>> have
>>>>>>>>>>>>>> difficulty.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Possibly it makes more sense to treat MPI_T return values
>>>>>>>>>>>>>>> differently than
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> MPI calls? Could the MPI_T return values be a set of
>>>>>>>>>>>>>> defined
>>>>>>>>>>>>>> codes instead?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Does anyone have different insight on error codes vs
>>>>>>>>>>>>>>> classes?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Kathryn
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>> From: mpi-forum-bounces at lists.mpi-forum.org
>>>>>>>>>>>>>>>> [mailto:mpi-forum-
>>>>>>>>>>>>>>>> bounces at lists.mpi-forum.org] On Behalf Of Bronis R. de
>>>>>>>>>>>>>>>> Supinski
>>>>>>>>>>>>>>>> Sent: Monday, July 23, 2012 10:37 AM
>>>>>>>>>>>>>>>> To: Main MPI Forum mailing list
>>>>>>>>>>>>>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and
>>>>>>>>>>>>>>>> MPI_ERR_LASTCODE
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> OK by me.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Mon, 23 Jul 2012, Dave Goodell wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I agree, we should make these changes.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -Dave
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Jul 23, 2012, at 8:55 AM CDT, Schulz, Martin wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi Rolf, all,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I agree with your suggestions and I am in favor of
>>>>>>>>>>>>>>>>>> making
>>>>>>>>>>>>>>>>>> these
>>>>>>>>>>>> changes.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Bronis (as well as Kathryn and Dave as the remaining
>>>>>>>>>>>>>>>> members
>>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> chapter
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> committee for tools) should concur, though.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Anybody else have any concerns over these changes?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> As for the callability of the error functions, I also
>>>>>>>>>>>>>>>>>> agree - let's target
>>>>>>>>>>>> those
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 3.1. This change is not vital and bit too big for final
>>>>>>>>>>>>>>>> edits.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Martin
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Jul 23, 2012, at 4:00 AM, Rolf Rabenseifner wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Martin et al.,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Consistently with your proposal, I would recommend:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 1) Sect 14.3.9 "Return Codes for the MPI tool
>>>>>>>>>>>>>>>>>>> information
>>>>>>>>>>>>>>>>>>> interface"
>>>>>>>>>>>>>>>>>>> last sentence reads
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> All return codes with the prefix MPI_T_ must be
>>>>>>>>>>>>>>>>>>> unique
>>>>>>>>>>>>>>>>>>> values and
>>>>>>>>>>>>>>>>>>> cannot overlap with any other return values returned
>>>>>>>>>>>>>>>>>>> by
>>>>>>>>>>>>>>>>>>> the MPI
>>>>>>>>>>>>>>>>>>> implementation.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> but should read
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> All return codes with the prefix MPI_T_ must be
>>>>>>>>>>>>>>>>>>>> unique
>>>>>>>>>>>>>>>>>>>> values and
>>>>>>>>>>>>>>>>>>>> cannot overlap with any other
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> error codes and error classes
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> returned by the MPI
>>>>>>>>>>>>>>>>>>>> implementation. Further, they shall be treated as
>>>>>>>>>>>>>>>>>>>> MPI
>>>>>>>>>>>>>>>>>>>> error classes
>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>>>>> defined in Chapter 8.4 and follow the same rules and
>>>>>>>>>>>>>>>>>>>> restrictions,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> especially they must satisfy
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... \leq
>>>>>>>>>>>>>>>>>>>>>>>> MPI_ERR_LASTCODE.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2) A.1.1 the first three tables are headed by
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Error classes
>>>>>>>>>>>>>>>>>>> Error classes (continued)
>>>>>>>>>>>>>>>>>>> Return Codes for the MPI tool information interface
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> and these lines should read
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Error classes
>>>>>>>>>>>>>>>>>>> Error classes (continued)
>>>>>>>>>>>>>>>>>>> Error classes (continued)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 3) The last line of A.1.1, 2nd table
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> MPI_ERR_LASTCODE
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> should move after the last MPI_T_ERR_... code in the
>>>>>>>>>>>>>>>>>>> 3rd
>>>>>>>>>>>>>>>>>>> table.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Okay?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The topic about user-callability of MPI_ERROR_CLASS
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> MPI_ERROR_STRING
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> outside of the initialized MPI should be revisited in
>>>>>>>>>>>>>>>>>>> MPI-3.1.
>>>>>>>>>>>>>>>>>>> This is not evident for the tools' developers because
>>>>>>>>>>>>>>>>>>> they know
>>>>>>>>>>>>>>>>>>> the meaning of their MPI_T_ERR... classes and only
>>>>>>>>>>>>>>>>>>> classes are
>>>>>>>>>>>> returned.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I would like to have a final "okay" before I execute
>>>>>>>>>>>>>>>>>>> the changes in chap-appLang.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Best regards
>>>>>>>>>>>>>>>>>>> Rolf
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> From: "Martin Schulz" <schulzm at llnl.gov>
>>>>>>>>>>>>>>>>>>>> To: "Main MPI Forum mailing list"
>>>>>>>>>>>>>>>>>>>> <mpi-forum at lists.mpi-forum.org>
>>>>>>>>>>>>>>>>>>>> Sent: Monday, July 23, 2012 1:23:40 AM
>>>>>>>>>>>>>>>>>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> MPI_ERR_LASTCODE
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Hi Rolf, all,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I thought we had discussed the error semantics of
>>>>>>>>>>>>>>>>>>>> MPI_T
>>>>>>>>>>>>>>>>>>>> in several
>>>>>>>>>>>>>>>>>>>> meetings/readings and nobody objected, but I
>>>>>>>>>>>>>>>>>>>> generally
>>>>>>>>>>>>>>>>>>>> agree with
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> your
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> comments below. However, they are not really error
>>>>>>>>>>>>>>>>>>>> classes (at least
>>>>>>>>>>>>>>>>>>>> in the tools group we/I never thought about them
>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>> way), but just
>>>>>>>>>>>>>>>>>>>> well defined return codes. Nevertheless, they fit
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> model and
>>>>>>>>>>>>>>>>>>>> semantics of classes and hence should integrated
>>>>>>>>>>>>>>>>>>>> into
>>>>>>>>>>>>>>>>>>>> the same rules
>>>>>>>>>>>>>>>>>>>> for consistency. I also agree with Bronis, though,
>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>> larger
>>>>>>>>>>>>>>>>>>>> feedback on this would be good to avoid errors
>>>>>>>>>>>>>>>>>>>> because
>>>>>>>>>>>>>>>>>>>> of rushing it.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> To keep changes minimal, I would suggest that we
>>>>>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>>>>> change the
>>>>>>>>>>>>>>>>>>>> following sentence, which IMHO is sufficient (and
>>>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>>> essentially
>>>>>>>>>>>>>>>>>>>> follow option b):
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> All return codes with the prefix MPI_T_ must be
>>>>>>>>>>>>>>>>>>>> unique
>>>>>>>>>>>>>>>>>>>> values and
>>>>>>>>>>>>>>>>>>>> cannot overlap with any other return values returned
>>>>>>>>>>>>>>>>>>>> by
>>>>>>>>>>>>>>>>>>>> the MPI
>>>>>>>>>>>>>>>>>>>> implementation. Further, they shall be treated as
>>>>>>>>>>>>>>>>>>>> MPI
>>>>>>>>>>>>>>>>>>>> error classes
>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>>>>> defined in Chapter 8.4 and follow the same rules and
>>>>>>>>>>>>>>>>>>>> restrictions.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> This would also make changes in the appendix
>>>>>>>>>>>>>>>>>>>> unnecessary.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> As for making MPI_ERROR_CLASS and MPI_ERROR_STRING
>>>>>>>>>>>> callable
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> before
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Init (and then also after finalize), yes that would
>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>> very useful,
>>>>>>>>>>>>>>>>>>>> but is a general issue not only related to MPI_T. If
>>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>> decide this is
>>>>>>>>>>>>>>>>>>>> too invasive at this point, I would like to see this
>>>>>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>>>>>> least in 3.1.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Martin
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Jul 22, 2012, at 1:46 PM, Rolf Rabenseifner
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> About 1. question:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I changed the headers of the three error code
>>>>>>>>>>>>>>>>>>>>> tables
>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>> the Annex
>>>>>>>>>>>>>>>>>>>>> according to Tables 8.1 and 8.2 from "Return codes"
>>>>>>>>>>>>>>>>>>>>> into "Error classes".
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> svn r1505: I used also "Error classes" for the
>>>>>>>>>>>>>>>>>>>>> tools
>>>>>>>>>>>>>>>>>>>>> table
>>>>>>>>>>>>>>>>>>>>> svn r1507: I went back to the official ticket 266
>>>>>>>>>>>>>>>>>>>>> text
>>>>>>>>>>>>>>>>>>>>> "Return
>>>>>>>>>>>>>>>>>>>>> codes"
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The Tools group should decide whether
>>>>>>>>>>>>>>>>>>>>> a. they want to stay with special return codes that
>>>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>> part of the rule in Set. 8.4
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 0 = MPI_SUCCESS < MPI_ERR_... <= MPI_ERR_LASTCODE
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> In this case they should change "return code"
>>>>>>>>>>>>>>>>>>>>> into "error codes are returned" plus noting that
>>>>>>>>>>>>>>>>>>>>> the routine MPI_ERROR_STRING can be applied
>>>>>>>>>>>>>>>>>>>>> with the open question, whether MPI_EEROR_STRING
>>>>>>>>>>>>>>>>>>>>> can be applied before a call to MPI_INIT.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Similar problem with failed MPI_INIT and analysing
>>>>>>>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>>>>>>> returned error code:
>>>>>>>>>>>>>>>>>>>>> One needs at least MPI_ERROR_CLASS and
>>>>>>>>>>>>>>>>>>>>> MPI_ERROR_STRING
>>>>>>>>>>>>>>>>>>>>> callable before MPI_INIT.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> b. or you may use the same terminology as in Sect.
>>>>>>>>>>>>>>>>>>>>> 8.4,
>>>>>>>>>>>>>>>>>>>>> then new table 14.5 must show "Error classes".
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> In this case you should integrate the MPI_T_ERR_...
>>>>>>>>>>>>>>>>>>>>> into the MPI_ERR_LASTCODE rule.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> You need at least MPI_ERROR_CLASS and
>>>>>>>>>>>>>>>>>>>>> MPI_ERROR_STRING
>>>>>>>>>>>>>>>>>>>>> callable before MPI_INIT.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I would prefer solution b together combined with
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> minimal solution for failed MPI_INIT, i.e.,
>>>>>>>>>>>>>>>>>>>>> adding MPI_ERROR_CLASS and MPI_ERROR_STRING to
>>>>>>>>>>>>>>>>>>>>> the list of routines callable outside of MPI's
>>>>>>>>>>>>>>>>>>>>> initialization.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> About 2. question: MPI_T_ERR_CANTINIT -_>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> MPI_T_ERR_CANNOTINIT
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> svn r1506: done by Bronis in chap-tools/mpit.tex
>>>>>>>>>>>>>>>>>>>>> svn r1508: done by Rolf in
>>>>>>>>>>>>>>>>>>>>> chap-appLang/appLang-Const.tex
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Rolf
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> From: "Bronis R. de Supinski" <bronis at llnl.gov>
>>>>>>>>>>>>>>>>>>>>>> To: "Main MPI Forum mailing list"
>>>>>>>>>>>>>>>>>>>>>> <mpi-forum at lists.mpi-
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> forum.org>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Cc: "Rolf Rabenseifner" <rabenseifner at hlrs.de>
>>>>>>>>>>>>>>>>>>>>>> Sent: Sunday, July 22, 2012 10:03:44 PM
>>>>>>>>>>>>>>>>>>>>>> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> MPI_ERR_LASTCODE
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Rolf:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> OK, I am changing MPI_T_ERR_CANTINIT to
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> MPI_T_ERR_CANNOTINIT.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> As said before, we need more opinions on the first
>>>>>>>>>>>>>>>>>>>>>> question.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Bronis
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Sun, 22 Jul 2012, Bronis R. de Supinski wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Rolf:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Re:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Dear Bronis, Martin, Dave, and Kathryn,
>>>>>>>>>>>>>>>>>>>>>>>> (Profiling/Tools chapter responsibles)
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> (you may forward this to the tools list - I'm
>>>>>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>>>> that list)
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Two important questions:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 1. Alexander Supalov detected that we did it
>>>>>>>>>>>>>>>>>>>>>>>> wrong:
>>>>>>>>>>>>>>>>>>>>>>>> The MPI_T_ERR_... list must be part of the total
>>>>>>>>>>>>>>>>>>>>>>>> error
>>>>>>>>>>>>>>>>>>>>>>>> list and sorted in before MPI_ERR_LASTCODE.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I will change this in
>>>>>>>>>>>>>>>>>>>>>>>> chap-appLang/appLang-Const.tex
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Please look, if there must be some additional
>>>>>>>>>>>>>>>>>>>>>>>> wording on this.
>>>>>>>>>>>>>>>>>>>>>>>> For example, the last sentence of Section 14.3.9
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> "All return codes with the prefix MPI_T_ must be
>>>>>>>>>>>>>>>>>>>>>>>> unique values
>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>> cannot overlap with any other return values
>>>>>>>>>>>>>>>>>>>>>>>> returned
>>>>>>>>>>>>>>>>>>>>>>>> by the
>>>>>>>>>>>> MPI
>>>>>>>>>>>>>>>>>>>>>>>> implementation."
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The above wording clearly states that the return
>>>>>>>>>>>>>>>>>>>>>>> values
>>>>>>>>>>>>>>>>>>>>>>> should be consistent with MPI_ERR_* return
>>>>>>>>>>>>>>>>>>>>>>> values.
>>>>>>>>>>>>>>>>>>>>>>> So,
>>>>>>>>>>>>>>>>>>>>>>> either the above wording needs to change (I do
>>>>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>>>>>>>>> why MPI_T_* return values need to be distinct
>>>>>>>>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>>>>>>>> MPI_ERR_* return values since the user should
>>>>>>>>>>>>>>>>>>>>>>> know
>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>> they were using an MPI_T_* function) or we need
>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>> adopt
>>>>>>>>>>>>>>>>>>>>>>> something like what you suggest.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I think we need broader opinions to make the
>>>>>>>>>>>>>>>>>>>>>>> decision.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I am concerned that wrapping up the document for
>>>>>>>>>>>>>>>>>>>>>>> MPI
>>>>>>>>>>>>>>>>>>>>>>> 3.0
>>>>>>>>>>>>>>>>>>>>>>> has led to a fast and loose attitude about making
>>>>>>>>>>>>>>>>>>>>>>> broader
>>>>>>>>>>>>>>>>>>>>>>> changes "in order to get it done." This attitude
>>>>>>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>>>>>> easily lead to suboptimal solutions.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Bronis
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> may be modified into
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> "All return codes with the prefix MPI_T_ must be
>>>>>>>>>>>>>>>>>>>>>>>> unique values
>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>> cannot overlap with any other return values
>>>>>>>>>>>>>>>>>>>>>>>> returned
>>>>>>>>>>>>>>>>>>>>>>>> by the
>>>>>>>>>>>> MPI
>>>>>>>>>>>>>>>>>>>>>>>> implementation and satisfy
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 0 = MPI_SUCCESS < MPI_T_ERR_... <=
>>>>>>>>>>>>>>>>>>>>>>>> MPI_ERR_LASTCODE.
>>>>>>>>>>>>>>>>>>>>>>>> "
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>>>>>> 0 = MPI_SUCCESS < MPI_ERR_... < MPI_T_ERR_... <=
>>>>>>>>>>>>>>>>>>>>>>>> MPI_ERR_LASTCODE.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>>>>>> 0 = MPI_SUCCESS < MPI_ERR_... <=
>>>>>>>>>>>>>>>>>>>>>>>> MPI_ERR_LASTCODE
>>>>>>>>>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>> MPI_T_ERR_... <= MPI_T_ERR_LASTCODE.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> and the MPI_ERR_LASTCODE and/or
>>>>>>>>>>>>>>>>>>>>>>>> MPI_T_ERR_LASTCODE
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> be also
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> repeated
>>>>>>>>>>>>>>>>>>>>>>>> in Table 14.5 as last entry, as done for the
>>>>>>>>>>>>>>>>>>>>>>>> first
>>>>>>>>>>>>>>>>>>>>>>>> value
>>>>>>>>>>>>>>>>>>>>>>>> MPI_SUCCESS.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> This proposal is based on Section 8.4, the
>>>>>>>>>>>>>>>>>>>>>>>> sentence
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> "The error codes satisfy,
>>>>>>>>>>>>>>>>>>>>>>>> 0 = MPI_SUCCESS < MPI_ERR_... <=
>>>>>>>>>>>>>>>>>>>>>>>> MPI_ERR_LASTCODE:
>>>>>>>>>>>>>>>>>>>>>>>> "
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Please confirm, that Alexander is right,
>>>>>>>>>>>>>>>>>>>>>>>> please include me in your discussion and
>>>>>>>>>>>>>>>>>>>>>>>> please tell me your result
>>>>>>>>>>>>>>>>>>>>>>>> that I can do the correct changes in
>>>>>>>>>>>>>>>>>>>>>>>> chap-appLang
>>>>>>>>>>>>>>>>>>>>>>>> and you in chap-tools.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 2. Qeustion is less important; it is about
>>>>>>>>>>>>>>>>>>>>>>>> naming:
>>>>>>>>>>>>>>>>>>>>>>>> Alexander also noticed that your names do not
>>>>>>>>>>>>>>>>>>>>>>>> fit
>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>> the names
>>>>>>>>>>>>>>>>>>>>>>>> used in the past:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> MPI_T_ERR_CANTINIT --> MPI_T_ERR_CANNOTINIT (we
>>>>>>>>>>>>>>>>>>>>>>>> do
>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> abbrevations)
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> MPI_T_ERR_CANTINIT --> MPI_T_ERR_CANNOT_INIT (we
>>>>>>>>>>>>>>>>>>>>>>>> do
>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> abbrevations)
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> In most cases, we do not combine words without
>>>>>>>>>>>>>>>>>>>>>>>> underscore.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> As far as I see, you can do the underscores.
>>>>>>>>>>>>>>>>>>>>>>>> Be sure to stay at maximum with 30 characters.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Current longest MPI_T constants:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 123456789012345678901234567890
>>>>>>>>>>>>>>>>>>>>>>>> MPI_T_PVAR_CLASS_HIGHWATERMARK
>>>>>>>>>>>>>>>>>>>>>>>> MPI_T_PVAR_CLASS_LOWWATERMARK
>>>>>>>>>>>>>>>>>>>>>>>> MPI_T_VERBOSITY_MPIDEV_DETAIL
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Based on this, I would stay with you names based
>>>>>>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>>>> your MPI_T
>>>>>>>>>>>>>>>>>>>>>>>> rule:
>>>>>>>>>>>>>>>>>>>>>>>> MPI_T_<structual-areas-with-underscores>_<final-name-
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> without-
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> underscores>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> i.e., I would only change
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> MPI_T_ERR_CANTINIT --> MPI_T_ERR_CANNOTINIT
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Please tell me also your decision
>>>>>>>>>>>>>>>>>>>>>>>> that I can do the correct changes in
>>>>>>>>>>>>>>>>>>>>>>>> chap-appLang
>>>>>>>>>>>>>>>>>>>>>>>> and you in chap-tools.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Best regards
>>>>>>>>>>>>>>>>>>>>>>>> Rolf
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email
>>>>>>>>>>>>>>>>>>>>>>>> rabenseifner at hlrs.de
>>>>>>>>>>>>>>>>>>>>>>>> High Performance Computing Center (HLRS) . phone
>>>>>>>>>>>>>>>>>>>>>>>> ++49(0)711/685-65530
>>>>>>>>>>>>>>>>>>>>>>>> University of Stuttgart . . . . . . . . .. fax
>>>>>>>>>>>>>>>>>>>>>>>> ++49(0)711 /
>>>>>>>>>>>>>>>>>>>>>>>> 685-65832
>>>>>>>>>>>>>>>>>>>>>>>> Head of Dpmt Parallel Computing . . .
>>>>>>>>>>>>>>>>>>>>>>>> www.hlrs.de/people/rabenseifner
>>>>>>>>>>>>>>>>>>>>>>>> Nobelstr. 19, D-70550 Stuttgart, Germany .
>>>>>>>>>>>>>>>>>>>>>>>> (Office:
>>>>>>>>>>>>>>>>>>>>>>>> Allmandring
>>>>>>>>>>>>>>>>>>>>>>>> 30)
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>>> mpi-forum mailing list
>>>>>>>>>>>>>>>>>>>>>>> mpi-forum at lists.mpi-forum.org
>>>>>>>>>>>>>>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email
>>>>>>>>>>>>>>>>>>>>> rabenseifner at hlrs.de
>>>>>>>>>>>>>>>>>>>>> High Performance Computing Center (HLRS) . phone
>>>>>>>>>>>>>>>>>>>>> ++49(0)711/685-65530
>>>>>>>>>>>>>>>>>>>>> University of Stuttgart . . . . . . . . .. fax
>>>>>>>>>>>>>>>>>>>>> ++49(0)711 /
>>>>>>>>>>>>>>>>>>>>> 685-65832
>>>>>>>>>>>>>>>>>>>>> Head of Dpmt Parallel Computing . . .
>>>>>>>>>>>>>>>>>>>>> www.hlrs.de/people/rabenseifner
>>>>>>>>>>>>>>>>>>>>> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office:
>>>>>>>>>>>>>>>>>>>>> Allmandring 30)
>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>> mpi-forum mailing list
>>>>>>>>>>>>>>>>>>>>> mpi-forum at lists.mpi-forum.org
>>>>>>>>>>>>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ____________________________________________________________________
>>>>>>>>>>>> __
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> __
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Martin Schulz, schulzm at llnl.gov,
>>>>>>>>>>>>>>>>>>>> http://people.llnl.gov/schulzm
>>>>>>>>>>>>>>>>>>>> CASC @ Lawrence Livermore National Laboratory,
>>>>>>>>>>>>>>>>>>>> Livermore, USA
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>> mpi-forum mailing list
>>>>>>>>>>>>>>>>>>>> mpi-forum at lists.mpi-forum.org
>>>>>>>>>>>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email
>>>>>>>>>>>>>>>>>>> rabenseifner at hlrs.de
>>>>>>>>>>>>>>>>>>> High Performance Computing Center (HLRS) . phone
>>>>>>>>>>>>>>>>>>> ++49(0)711/685-
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 65530
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> University of Stuttgart . . . . . . . . .. fax
>>>>>>>>>>>>>>>>>>> ++49(0)711
>>>>>>>>>>>>>>>>>>> / 685-65832
>>>>>>>>>>>>>>>>>>> Head of Dpmt Parallel Computing . . .
>>>>>>>>>>>> www.hlrs.de/people/rabenseifner
>>>>>>>>>>>>>>>>>>> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office:
>>>>>>>>>>>>>>>>>>> Allmandring 30)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ____________________________________________________________________
>>>>>>>>>>>> __
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> __
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Martin Schulz, schulzm at llnl.gov,
>>>>>>>>>>>>>>>>>> http://people.llnl.gov/schulzm
>>>>>>>>>>>>>>>>>> CASC @ Lawrence Livermore National Laboratory,
>>>>>>>>>>>>>>>>>> Livermore,
>>>>>>>>>>>>>>>>>> USA
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>> mpi-forum mailing list
>>>>>>>>>>>>>>>>>> mpi-forum at lists.mpi-forum.org
>>>>>>>>>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>> mpi-forum mailing list
>>>>>>>>>>>>>>>>> mpi-forum at lists.mpi-forum.org
>>>>>>>>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> mpi-forum mailing list
>>>>>>>>>>>>>>>> mpi-forum at lists.mpi-forum.org
>>>>>>>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> mpi-forum mailing list
>>>>>>>>>>>>>>> mpi-forum at lists.mpi-forum.org
>>>>>>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> mpi-forum mailing list
>>>>>>>>>>>>>> mpi-forum at lists.mpi-forum.org
>>>>>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> mpi-forum mailing list
>>>>>>>>>>>>> mpi-forum at lists.mpi-forum.org
>>>>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> mpi-forum mailing list
>>>>>>>>>>>> mpi-forum at lists.mpi-forum.org
>>>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> mpi-forum mailing list
>>>>>>>>>>> mpi-forum at lists.mpi-forum.org
>>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>>>>>>>>>>
>>>>>>>>>> ________________________________________________________________________
>>>>>>>>>> Martin Schulz, schulzm at llnl.gov,
>>>>>>>>>> http://people.llnl.gov/schulzm
>>>>>>>>>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> mpi-forum mailing list
>>>>>>>>>> mpi-forum at lists.mpi-forum.org
>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>>>>>>>>>>
>>>>>>>>
>>>>>>>> ________________________________________________________________________
>>>>>>>> Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
>>>>>>>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> mpi-forum mailing list
>>>>>>> mpi-forum at lists.mpi-forum.org
>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>>>>>>
>>>>>> --
>>>>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email
>>>>>> rabenseifner at hlrs.de
>>>>>> High Performance Computing Center (HLRS) . phone
>>>>>> ++49(0)711/685-65530
>>>>>> University of Stuttgart . . . . . . . . .. fax ++49(0)711 /
>>>>>> 685-65832
>>>>>> Head of Dpmt Parallel Computing . . .
>>>>>> www.hlrs.de/people/rabenseifner
>>>>>> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring
>>>>>> 30)
>>>>>>
>>>>
>>>> --
>>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email
>>>> rabenseifner at hlrs.de
>>>> High Performance Computing Center (HLRS) . phone
>>>> ++49(0)711/685-65530
>>>> University of Stuttgart . . . . . . . . .. fax ++49(0)711 /
>>>> 685-65832
>>>> Head of Dpmt Parallel Computing . . .
>>>> www.hlrs.de/people/rabenseifner
>>>> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)
>>>>
>>
>> --
>> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at hlrs.de
>> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
>> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
>> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner
>> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)
>>
>
> _____________________________________________________________________
> Kathryn Mohror, kathryn at llnl.gov, http://people.llnl.gov/mohror1
> CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA
>
>
More information about the mpi-forum
mailing list