[Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE
Adam T. Moody
moody20 at llnl.gov
Tue Jul 24 13:23:07 CDT 2012
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
>
>
More information about the mpi-forum
mailing list