24 Jul
2012
24 Jul
'12
1:31 p.m.
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