July 2012 - mpi-forum - mailman3.cels.anl.gov

Re: [Mpi-forum] Compile problems with examples in MPI Standard
by John DelSignore 24 Jul '12

24 Jul '12

In C and C++, the type of "char *argv[]" as a parameter is equivalent to the type of "char **argv", because you can't pass an array as an argument. Therefore, as written in the example, the type of argv is "a pointer to a pointer to a char". I don't know what the type signature of MPI_Init() is in your implementation, but it's possible that a "const" got tossed in there somewhere, for example: int MPI_Init(int *, const char ***); Here's a simple test: cap:/nfs/san0/user/home/jdelsign>cat xxx.c void bar( char ***p) {} void foo(const char ***p) {} main(int argc, char *argv[]) { bar(&argv); foo(&argv); } cap:/nfs/san0/user/home/jdelsign>gcc --version | head -1 gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44) cap:/nfs/san0/user/home/jdelsign>gcc xxx.c xxx.c: In function 'main': xxx.c:6: warning: passing argument 1 of 'foo' from incompatible pointer type cap:/nfs/san0/user/home/jdelsign> Hope this helps. Cheers, John D. William Gropp wrote: > I've run my code checker over the examples in the MPI-3 Standard, and I've found some issues. Perhaps the biggest is this (a typical example): > > Opening file one-side-2.tex > ex5501.c: In function ï¿½mainï¿½: > ex5501.c:58: warning: passing argument 2 of ï¿½MPI_Initï¿½ from incompatible pointer type > > This occurs everywhere we include MPI_Init in an example. The compiler is gcc 4.2.1 . The corresponding > declaration of argv is as intended: > > int main(int argc, char *argv[]) > > The declaration in MPI_Init looks correct (argv is a pointer to an array of pointers to char). Is this a place where we should stick with the *** notation just to keep compilers happy? Or is there something I'm missing in the declaration? > > There are a number of other errors as well. Three examples in the new tools chapter don't compile. There are a number of problems in the datatype chapter, most minor. > > I can fix the obvious ones or leave them to the chapter authors. Let me know what is preferred. > > I can't check the Fortran 08 examples because I only have gfortran :( > > 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 > > > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >

1 0

Re: [Mpi-forum] Compile problems with examples in MPI Standard
by Bronis R. de Supinski 24 Jul '12

24 Jul '12

Bill: Feel free to fix examples in the tools chapter if the problems are obvious. Thanks, Bronis On Tue, 24 Jul 2012, William Gropp wrote: > I've run my code checker over the examples in the MPI-3 Standard, and I've found some issues. Perhaps the biggest is this (a typical example): > > Opening file one-side-2.tex > ex5501.c: In function ï¿½mainï¿½: > ex5501.c:58: warning: passing argument 2 of ï¿½MPI_Initï¿½ from incompatible pointer type > > This occurs everywhere we include MPI_Init in an example. The compiler is gcc 4.2.1 . The corresponding > declaration of argv is as intended: > > int main(int argc, char *argv[]) > > The declaration in MPI_Init looks correct (argv is a pointer to an array of pointers to char). Is this a place where we should stick with the *** notation just to keep compilers happy? Or is there something I'm missing in the declaration? > > There are a number of other errors as well. Three examples in the new tools chapter don't compile. There are a number of problems in the datatype chapter, most minor. > > I can fix the obvious ones or leave them to the chapter authors. Let me know what is preferred. > > I can't check the Fortran 08 examples because I only have gfortran :( > > 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 > > > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >

1 0

Compile problems with examples in MPI Standard
by William Gropp 24 Jul '12

24 Jul '12

I've run my code checker over the examples in the MPI-3 Standard, and I've found some issues. Perhaps the biggest is this (a typical example): Opening file one-side-2.tex ex5501.c: In function ï¿½mainï¿½: ex5501.c:58: warning: passing argument 2 of ï¿½MPI_Initï¿½ from incompatible pointer type This occurs everywhere we include MPI_Init in an example. The compiler is gcc 4.2.1 . The corresponding declaration of argv is as intended: int main(int argc, char *argv[]) The declaration in MPI_Init looks correct (argv is a pointer to an array of pointers to char). Is this a place where we should stick with the *** notation just to keep compilers happy? Or is there something I'm missing in the declaration? There are a number of other errors as well. Three examples in the new tools chapter don't compile. There are a number of problems in the datatype chapter, most minor. I can fix the obvious ones or leave them to the chapter authors. Let me know what is preferred. I can't check the Fortran 08 examples because I only have gfortran :( 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

1 0

Re: [Mpi-forum] MPI-3: MPI_T_... names
by Bronis R. de Supinski 24 Jul '12

24 Jul '12

I have no strong opinion on this issue. On Tue, 24 Jul 2012, Rolf Rabenseifner wrote: > I started a new email-trunk, because this mail is mainly about names. > > The problem with MPI_T_... names is that they are partially > very long: > > Current longest MPI_T constants: > > 123456789012345678901234567890 > MPI_T_PVAR_CLASS_HIGHWATERMARK (30) > MPI_T_PVAR_CLASS_LOWWATERMARK (29) > MPI_T_VERBOSITY_MPIDEV_DETAIL (29) > > The system is classes of constants are named with underscores, > e.g. MPI_T_PVAR_CLASS, the end-names without underscores, > e.g. HIGHWATERMARK. > > In the error codes, your right, they > - should change from > MPI_T_ERR_INVALIDINDEX > MPI_T_ERR_INVALIDITEM > MPI_T_ERR_INVALIDSESSION > MPI_T_ERR_INVALIDHANDLE > to > MPI_T_ERR_INVALID_INDEX > MPI_T_ERR_INVALID_ITEM > 123456789012345678901234567890 > MPI_T_ERR_INVALID_SESSION (25) > MPI_T_ERR_INVALID_HANDLE > because the class name is MPI_T_ERR_INVALID_ > > - and also > MPI_T_ERR_OUTOFHANDLES > MPI_T_ERR_OUTOFSESSIONS > to > MPI_T_ERR_OUT_OF_HANDLES > MPI_T_ERR_OUT_OF_SESSIONS > - and they may change > MPI_T_ERR_CANNOTINIT > MPI_T_ERR_NOTINITIALIZED > MPI_T_ERR_MEMORY > MPI_T_ERR_CVAR_SETNOTNOW > MPI_T_ERR_CVAR_SETNEVER > MPI_T_ERR_PVAR_NOWRITE > MPI_T_ERR_PVAR_NOSTARTSTOP > MPI_T_ERR_PVAR_NOATOMIC > to > MPI_T_ERR_CANNOT_INIT > MPI_T_ERR_NOT_INITIALIZED > MPI_T_ERR_MEMORY > MPI_T_ERR_CVAR_SET_NOT_NOW > MPI_T_ERR_CVAR_SET_NEVER > MPI_T_ERR_PVAR_NO_WRITE > 123456789012345678901234567890 > MPI_T_ERR_PVAR_NO_STARTSTOP (27) > MPI_T_ERR_PVAR_NO_ATOMIC > > All the other MPI_T_... names seem to be fine. > > Bets regards > Rolf > > ----- Original Message ----- >> From: "Alexander Supalov" <alexander.supalov(a)intel.com> >> To: "Martin Schulz" <schulzm(a)llnl.gov>, "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >> Sent: Tuesday, July 24, 2012 9:35:13 AM >> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE >> Hi everybody, >> >> I see that that my innocent remarks re. Annex A have lead to a lot of >> discussion. What I'm going to say may resemble Bart Simpson's "I >> didn't do it", but I think I have to: >> >> When commenting on the MPI_T_* names, I meant only their composition >> that differed from most other comparable MPI constant names in that it >> was 1) using contractions and 2) not using underscores to separate >> different words. The MPI_T_CANTINIT was but one example of this. I >> proposed to change all MPI_T_* names to follow the more traditional >> rules (i.e., 1) do not use contractions and 2) do use underscores), >> which lead to the MPI_T_CANNOT_INIT proposal that should be >> consistently followed up on for every other MPI_T_* name. The >> MPI_ERR_LASTCODE was mentioned as a counterexample of a known MPI >> constant name that was not following this set of rules either. Oh >> well, this is an old one and we won't change it. At no time did I >> intend the MPI_T series to become a part of the MPI_ERR series, >> although I must admit that they look really close when you start >> thinking about them. We will probably have enough time for this >> contemplation in the MPI 3.1 time frame. >> >> To sum up, my proposal now is: >> >> 1) Consider replacing contractions in all MPI_T_* names >> 2) Consider using underscores in all MPI_T_* names >> 3) Drop the MPI_ERR and MPI_T connection idea >> >> And if 1) and 2) are considered too invasive at this point, I won't go >> nuts either: after all, these are just constant names. >> >> Best regards. >> >> Alexander > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)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(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >

1 0

Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE
by Bronis R. de Supinski 24 Jul '12

24 Jul '12

Rolf: Re: > My proposal (repeated below) is exactly doing what you all want: > - the MPI_T_ERR_... codes are handled as fixed codes that need not > any further translation. > The MPI name for such codes is "error classes" and not > "return codes" or "error codes". > Normally, MPI routines do not return such "error classes". I think your wordin was perhaps a little obscure. I will try to offer a fix below. > They return "error codes" that need to be first translated > with MPI_ERROR_CLASS into an "error class" before you > can compare it with the well-known fixed numbers > as MPI_ERR_... > - Instead of adding (i.e., reinvent) a completely new set of > methods to handle MPI_T_ERR_... "return codes", it is more > useful to use the existing methods. > For this, we have to do four things: > a. guarantee that there is no value-overlap with other MPI_ERR_... > error classes (already done in your text), > b. guarantee that 0 = MPI_SUCCESS < MPI_T_ERR_... > (not done in your text, but intended by putting MPI_SUCCESS > on the first position of Table 14.5), > c. guarantee that > MPI_T_ERR_... <= MPI_ERR_LASTCODE > d. include MPI_T_ERR_... names into the list of error classes. > You did 25% of that list already: > a. is done, b. was intended but not done, c.+d. is missing. > - You never expected that there is a chance to get the error strings > for MPI_T_ERR_... codes from MPI_ERROR_STRING. > This is the only additional quality, my proposal will add. > Because you never expected this, it is no problem, > that this quality does not exist before MPI_INIT. > By the way, MPI_INIT (and all other routines that can be called > before MPI_INIT) can never return an error code > because you can never switch on ERROR_ON_RETURN before > MPI_INIT (it was my fault that I mentioned this non-existing > possibility in an earlier email). I think we should change this (but in 3.1). I believe we are adding more and more functionality that may be called before MPI_INIT_THREAD and should allow full handling of any errors encountered there. Further, the translation should be available beforehand. I believe these changes are fairly easy to handle. They might entail some overhead in the translations and in setting error handlers (at least for MPI_COMM_WORLD). However, those functions should not be used in performance critical code paths so it should not matter. > With MPI-3.1, you can discuss with the Forum whether MPI_ERROR_STRING > (and MPI_ERROR_CLASS) should be callable already after MPI_T_INIT. > - I go with Adam's 2nd way, but there is no need to allow > MPI_ERROR_STRING and MPI_ERROR_CLASS before MPI_INIT > because the MPI_T_ interface is not intended to be visible for > the application, as stated in MPI-3.0 in Sect 14.3.9 by > "None of the return codes returned by an routine impact > the execution of the MPI process and do not invoke MPI > error handlers. ..." > > Therefore, my question again, Kathrin, Bronis, Martin and Dave, > is it okay for you as chapter committee that we proceed with > this proposal: > > ------------------------- > 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 [modified] 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. With that, then I am happy with the addition. Bronis > 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. > -------------------- > > As far as I understand, Martin is still convinced, that this > proposal is the best way to solve your problems. > > Or do you really want to add a completely new set of > naming and methods for MPI_T_ERR_.. codes? > > Best regards > Rolf > > ----- Original Message ----- >> From: "Martin Schulz" <schulzm(a)llnl.gov> >> To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >> Sent: Tuesday, July 24, 2012 8:18:34 AM >> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE >> Hi Adam, all, >> >> I don't think that is necessary in this case. The way the tools >> section is written right now, all MPI_T return codes are well defined >> and can be interpreted without translating them. >> >> In addition to that, I don't like the idea of creating a separate >> number space (aside from the issue that this is very invasive at this >> point): it is not really consistent with MPI_T functions being part of >> the MPI namespace (as requested by the forum during one of the >> readings) and it also provides no clean way for tools, in particular >> PMPI tools that use MPI_T, to return MPI_T return codes as error >> conditions for MPI routines. >> >> Martin >> > ----- Original Message ----- >> From: "Martin Schulz" <schulzm(a)llnl.gov> >> To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >> Sent: Tuesday, July 24, 2012 8:13:54 AM >> Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE >> Hi Kathryn, all, >> >> On Jul 23, 2012, at 1: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? >> >> That's more or less what the last proposal is - we have MPI_T return >> codes and those should be treated as MPI error classes. I guess we >> always refrained from calling them error classes or error codes since >> we put more constraints on them wrt. their influence on the overall >> execution and because we defined them more closely. >> >>> I think that MPI calls return codes and the codes are translated to >>> classes by the MPI_ERROR_CLASS function. >> >> That's not how it was intended. I agree, though, we didn't formulate >> this in the most optimal way. >> >>> 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? >> >> Yes, I agree - that's the intent of the big table at the end of the >> tools section - fixed return codes for each condition, such that one >> needs no translation. That's also why I like the currently proposed >> formulation of having MPI_T return codes that are (only) treated the >> same as MPI error classes. There were only two reasons why we stuck >> them at the end into the same number space as MPI error classes or >> codes: a) it should be possible to return an MPI_T error as a return >> value of an MPI function (e.g., if the call got intercepted using PMPI >> and the wrapper uses MPI_T) and b) it was consistent with shifting >> from MPIT (separate name space) to MPI as the prefix. >> >> Martin > >> >> On Jul 23, 2012, at 4:45 PM, Adam T. Moody wrote: >> >>> This reminds me of the discussions we had on datatypes, regarding >>> which >>> datatypes are available and can be used before MPI_Init is called. >>> Since people weren't keen on the fact of duplicating all of the >>> datatypes and associated routines for MPI_T, in that case, we boiled >>> down the list of datatypes allowed in MPI_T to a very limited set of >>> the >>> existing MPI datatypes, and then required that implementations >>> support >>> these after MPI_T_INIT but before MPI_INIT. >>> >>> I think it's best to resolve this cleanly, even if that means things >>> are >>> undefined between now and 3.1. I can think of two "clean" ways to >>> resolve this: >>> >>> 1) remove all overlap of MPI_T_ and MPI_ error codes, i.e., >>> MPI_T_ >>> errors live in a separate space from MPI_ errors, 0 = MPI_T_SUCCESS >>> < >>> MPI_T_* < MPI_T_LAST_ERRCODE, and introduce new corresponding >>> MPI_T_ERROR_CLASS/STRING functions that can be invoked after >>> MPI_T_INIT. Then all MPI_T functions return MPI_T error codes (and >>> only >>> MPI_T error codes), which must be interpretted with the new >>> MPI_T_ERROR* >>> functions. Personally, it feels a little strange to pass an MPI_T_ >>> error code to standard MPI_ functions, since we've otherwise >>> separated >>> the interfaces as much as possible. >>> >>> 2) Specify that MPI_T error codes can be passed to the existing >>> MPI_ERROR* functions, but require that implementations allow one to >>> call >>> these functions before MPI_INIT (at least for MPI_T_ error codes). >>> >>> By the way, does the standard say anything about calling MPI_ERROR* >>> functions before MPI_INIT? What if someone wanted to process an >>> error >>> code returned from one of the functions you are allowed to call >>> before >>> MPI_INIT, such as MPI_INITIALIZED? >>> -Adam >>> >>> >>> Bronis R. de Supinski wrote: >>> >>>> These are good points. I withdraw my agreement to the changes >>>> until Martin or Rolf addresses them. >>>> >>>> On Mon, 23 Jul 2012, 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(a)lists.mpi-forum.org [mailto:mpi-forum- >>>>>> bounces(a)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(a)llnl.gov> >>>>>>>>>> To: "Main MPI Forum mailing list" >>>>>>>>>> <mpi-forum(a)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(a)llnl.gov> >>>>>>>>>>>> To: "Main MPI Forum mailing list" >>>>>>>>>>>> <mpi-forum(a)lists.mpi-forum.org> >>>>>>>>>>>> Cc: "Rolf Rabenseifner" <rabenseifner(a)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(a)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(a)lists.mpi-forum.org >>>>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email >>>>>>>>>>> rabenseifner(a)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(a)lists.mpi-forum.org >>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> ______________________________________________________________________ >>>>>> __ >>>>>> >>>>>> >>>>>>>>>> Martin Schulz, schulzm(a)llnl.gov, >>>>>>>>>> http://people.llnl.gov/schulzm >>>>>>>>>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> mpi-forum mailing list >>>>>>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>>>>>> >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email >>>>>>>>> rabenseifner(a)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(a)llnl.gov, http://people.llnl.gov/schulzm >>>>>>>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> mpi-forum mailing list >>>>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> mpi-forum mailing list >>>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> mpi-forum mailing list >>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> mpi-forum mailing list >>>>> mpi-forum(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> mpi-forum mailing list >>>> mpi-forum(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>> >>>> >>> >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> >> ________________________________________________________________________ >> Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm >> CASC @ Lawrence Livermore National Laboratory, Livermore, USA >> >> >> >> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)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(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >

1 0

MPI-3: MPI_T_... names
by Rolf Rabenseifner 24 Jul '12

24 Jul '12

I started a new email-trunk, because this mail is mainly about names. The problem with MPI_T_... names is that they are partially very long: Current longest MPI_T constants: 123456789012345678901234567890 MPI_T_PVAR_CLASS_HIGHWATERMARK (30) MPI_T_PVAR_CLASS_LOWWATERMARK (29) MPI_T_VERBOSITY_MPIDEV_DETAIL (29) The system is classes of constants are named with underscores, e.g. MPI_T_PVAR_CLASS, the end-names without underscores, e.g. HIGHWATERMARK. In the error codes, your right, they - should change from MPI_T_ERR_INVALIDINDEX MPI_T_ERR_INVALIDITEM MPI_T_ERR_INVALIDSESSION MPI_T_ERR_INVALIDHANDLE to MPI_T_ERR_INVALID_INDEX MPI_T_ERR_INVALID_ITEM 123456789012345678901234567890 MPI_T_ERR_INVALID_SESSION (25) MPI_T_ERR_INVALID_HANDLE because the class name is MPI_T_ERR_INVALID_ - and also MPI_T_ERR_OUTOFHANDLES MPI_T_ERR_OUTOFSESSIONS to MPI_T_ERR_OUT_OF_HANDLES MPI_T_ERR_OUT_OF_SESSIONS - and they may change MPI_T_ERR_CANNOTINIT MPI_T_ERR_NOTINITIALIZED MPI_T_ERR_MEMORY MPI_T_ERR_CVAR_SETNOTNOW MPI_T_ERR_CVAR_SETNEVER MPI_T_ERR_PVAR_NOWRITE MPI_T_ERR_PVAR_NOSTARTSTOP MPI_T_ERR_PVAR_NOATOMIC to MPI_T_ERR_CANNOT_INIT MPI_T_ERR_NOT_INITIALIZED MPI_T_ERR_MEMORY MPI_T_ERR_CVAR_SET_NOT_NOW MPI_T_ERR_CVAR_SET_NEVER MPI_T_ERR_PVAR_NO_WRITE 123456789012345678901234567890 MPI_T_ERR_PVAR_NO_STARTSTOP (27) MPI_T_ERR_PVAR_NO_ATOMIC All the other MPI_T_... names seem to be fine. Bets regards Rolf ----- Original Message ----- > From: "Alexander Supalov" <alexander.supalov(a)intel.com> > To: "Martin Schulz" <schulzm(a)llnl.gov>, "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > Sent: Tuesday, July 24, 2012 9:35:13 AM > Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE > Hi everybody, > > I see that that my innocent remarks re. Annex A have lead to a lot of > discussion. What I'm going to say may resemble Bart Simpson's "I > didn't do it", but I think I have to: > > When commenting on the MPI_T_* names, I meant only their composition > that differed from most other comparable MPI constant names in that it > was 1) using contractions and 2) not using underscores to separate > different words. The MPI_T_CANTINIT was but one example of this. I > proposed to change all MPI_T_* names to follow the more traditional > rules (i.e., 1) do not use contractions and 2) do use underscores), > which lead to the MPI_T_CANNOT_INIT proposal that should be > consistently followed up on for every other MPI_T_* name. The > MPI_ERR_LASTCODE was mentioned as a counterexample of a known MPI > constant name that was not following this set of rules either. Oh > well, this is an old one and we won't change it. At no time did I > intend the MPI_T series to become a part of the MPI_ERR series, > although I must admit that they look really close when you start > thinking about them. We will probably have enough time for this > contemplation in the MPI 3.1 time frame. > > To sum up, my proposal now is: > > 1) Consider replacing contractions in all MPI_T_* names > 2) Consider using underscores in all MPI_T_* names > 3) Drop the MPI_ERR and MPI_T connection idea > > And if 1) and 2) are considered too invasive at this point, I won't go > nuts either: after all, these are just constant names. > > Best regards. > > Alexander -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)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)

1 0

Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE
by Rolf Rabenseifner 24 Jul '12

24 Jul '12

Martin Schulz wrote: > [...] The way the tools > section is written right now, all MPI_T return codes are well defined > and can be interpreted without translating them. > > In addition to that, I don't like the idea of creating a separate > number space (aside from the issue that this is very invasive at this > point): [...] > > Bronis R. de Supinski wrote: > >> These are good points. I withdraw my agreement to the changes > >> until Martin or Rolf addresses them. > >> On Mon, 23 Jul 2012, Mohror, Kathryn wrote: > >>> Does anyone have different insight on error codes vs classes? > On Jul 23, 2012, at 4:45 PM, Adam T. Moody wrote: > > 2) Specify that MPI_T error codes can be passed to the existing > > MPI_ERROR* functions, but require that implementations allow one to > > call these functions before MPI_INIT (at least for MPI_T_ error codes). Dear all, My proposal (repeated below) is exactly doing what you all want: - the MPI_T_ERR_... codes are handled as fixed codes that need not any further translation. The MPI name for such codes is "error classes" and not "return codes" or "error codes". Normally, MPI routines do not return such "error classes". They return "error codes" that need to be first translated with MPI_ERROR_CLASS into an "error class" before you can compare it with the well-known fixed numbers as MPI_ERR_... - Instead of adding (i.e., reinvent) a completely new set of methods to handle MPI_T_ERR_... "return codes", it is more useful to use the existing methods. For this, we have to do four things: a. guarantee that there is no value-overlap with other MPI_ERR_... error classes (already done in your text), b. guarantee that 0 = MPI_SUCCESS < MPI_T_ERR_... (not done in your text, but intended by putting MPI_SUCCESS on the first position of Table 14.5), c. guarantee that MPI_T_ERR_... <= MPI_ERR_LASTCODE d. include MPI_T_ERR_... names into the list of error classes. You did 25% of that list already: a. is done, b. was intended but not done, c.+d. is missing. - You never expected that there is a chance to get the error strings for MPI_T_ERR_... codes from MPI_ERROR_STRING. This is the only additional quality, my proposal will add. Because you never expected this, it is no problem, that this quality does not exist before MPI_INIT. By the way, MPI_INIT (and all other routines that can be called before MPI_INIT) can never return an error code because you can never switch on ERROR_ON_RETURN before MPI_INIT (it was my fault that I mentioned this non-existing possibility in an earlier email). With MPI-3.1, you can discuss with the Forum whether MPI_ERROR_STRING (and MPI_ERROR_CLASS) should be callable already after MPI_T_INIT. - I go with Adam's 2nd way, but there is no need to allow MPI_ERROR_STRING and MPI_ERROR_CLASS before MPI_INIT because the MPI_T_ interface is not intended to be visible for the application, as stated in MPI-3.0 in Sect 14.3.9 by "None of the return codes returned by an routine impact the execution of the MPI process and do not invoke MPI error handlers. ..." Therefore, my question again, Kathrin, Bronis, Martin and Dave, is it okay for you as chapter committee that we proceed with this proposal: ------------------------- 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. -------------------- As far as I understand, Martin is still convinced, that this proposal is the best way to solve your problems. Or do you really want to add a completely new set of naming and methods for MPI_T_ERR_.. codes? Best regards Rolf ----- Original Message ----- > From: "Martin Schulz" <schulzm(a)llnl.gov> > To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > Sent: Tuesday, July 24, 2012 8:18:34 AM > Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE > Hi Adam, all, > > I don't think that is necessary in this case. The way the tools > section is written right now, all MPI_T return codes are well defined > and can be interpreted without translating them. > > In addition to that, I don't like the idea of creating a separate > number space (aside from the issue that this is very invasive at this > point): it is not really consistent with MPI_T functions being part of > the MPI namespace (as requested by the forum during one of the > readings) and it also provides no clean way for tools, in particular > PMPI tools that use MPI_T, to return MPI_T return codes as error > conditions for MPI routines. > > Martin > ----- Original Message ----- > From: "Martin Schulz" <schulzm(a)llnl.gov> > To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > Sent: Tuesday, July 24, 2012 8:13:54 AM > Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE > Hi Kathryn, all, > > On Jul 23, 2012, at 1: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? > > That's more or less what the last proposal is - we have MPI_T return > codes and those should be treated as MPI error classes. I guess we > always refrained from calling them error classes or error codes since > we put more constraints on them wrt. their influence on the overall > execution and because we defined them more closely. > > > I think that MPI calls return codes and the codes are translated to > > classes by the MPI_ERROR_CLASS function. > > That's not how it was intended. I agree, though, we didn't formulate > this in the most optimal way. > > > 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? > > Yes, I agree - that's the intent of the big table at the end of the > tools section - fixed return codes for each condition, such that one > needs no translation. That's also why I like the currently proposed > formulation of having MPI_T return codes that are (only) treated the > same as MPI error classes. There were only two reasons why we stuck > them at the end into the same number space as MPI error classes or > codes: a) it should be possible to return an MPI_T error as a return > value of an MPI function (e.g., if the call got intercepted using PMPI > and the wrapper uses MPI_T) and b) it was consistent with shifting > from MPIT (separate name space) to MPI as the prefix. > > Martin > > On Jul 23, 2012, at 4:45 PM, Adam T. Moody wrote: > > > This reminds me of the discussions we had on datatypes, regarding > > which > > datatypes are available and can be used before MPI_Init is called. > > Since people weren't keen on the fact of duplicating all of the > > datatypes and associated routines for MPI_T, in that case, we boiled > > down the list of datatypes allowed in MPI_T to a very limited set of > > the > > existing MPI datatypes, and then required that implementations > > support > > these after MPI_T_INIT but before MPI_INIT. > > > > I think it's best to resolve this cleanly, even if that means things > > are > > undefined between now and 3.1. I can think of two "clean" ways to > > resolve this: > > > > 1) remove all overlap of MPI_T_ and MPI_ error codes, i.e., > > MPI_T_ > > errors live in a separate space from MPI_ errors, 0 = MPI_T_SUCCESS > > < > > MPI_T_* < MPI_T_LAST_ERRCODE, and introduce new corresponding > > MPI_T_ERROR_CLASS/STRING functions that can be invoked after > > MPI_T_INIT. Then all MPI_T functions return MPI_T error codes (and > > only > > MPI_T error codes), which must be interpretted with the new > > MPI_T_ERROR* > > functions. Personally, it feels a little strange to pass an MPI_T_ > > error code to standard MPI_ functions, since we've otherwise > > separated > > the interfaces as much as possible. > > > > 2) Specify that MPI_T error codes can be passed to the existing > > MPI_ERROR* functions, but require that implementations allow one to > > call > > these functions before MPI_INIT (at least for MPI_T_ error codes). > > > > By the way, does the standard say anything about calling MPI_ERROR* > > functions before MPI_INIT? What if someone wanted to process an > > error > > code returned from one of the functions you are allowed to call > > before > > MPI_INIT, such as MPI_INITIALIZED? > > -Adam > > > > > > Bronis R. de Supinski wrote: > > > >> These are good points. I withdraw my agreement to the changes > >> until Martin or Rolf addresses them. > >> > >> On Mon, 23 Jul 2012, 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(a)lists.mpi-forum.org [mailto:mpi-forum- > >>>> bounces(a)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(a)llnl.gov> > >>>>>>>> To: "Main MPI Forum mailing list" > >>>>>>>> <mpi-forum(a)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(a)llnl.gov> > >>>>>>>>>> To: "Main MPI Forum mailing list" > >>>>>>>>>> <mpi-forum(a)lists.mpi-forum.org> > >>>>>>>>>> Cc: "Rolf Rabenseifner" <rabenseifner(a)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(a)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(a)lists.mpi-forum.org > >>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email > >>>>>>>>> rabenseifner(a)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(a)lists.mpi-forum.org > >>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>> ______________________________________________________________________ > >>>> __ > >>>> > >>>> > >>>>>>>> Martin Schulz, schulzm(a)llnl.gov, > >>>>>>>> http://people.llnl.gov/schulzm > >>>>>>>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> mpi-forum mailing list > >>>>>>>> mpi-forum(a)lists.mpi-forum.org > >>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > >>>>>>>> > >>>>>>>> > >>>>>>> -- > >>>>>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email > >>>>>>> rabenseifner(a)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(a)llnl.gov, http://people.llnl.gov/schulzm > >>>>>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> mpi-forum mailing list > >>>>>> mpi-forum(a)lists.mpi-forum.org > >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > >>>>>> > >>>>>> > >>>>> _______________________________________________ > >>>>> mpi-forum mailing list > >>>>> mpi-forum(a)lists.mpi-forum.org > >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > >>>>> > >>>>> > >>>>> > >>>> _______________________________________________ > >>>> mpi-forum mailing list > >>>> mpi-forum(a)lists.mpi-forum.org > >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > >>>> > >>>> > >>> _______________________________________________ > >>> mpi-forum mailing list > >>> mpi-forum(a)lists.mpi-forum.org > >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > >>> > >>> > >>> > >> _______________________________________________ > >> mpi-forum mailing list > >> mpi-forum(a)lists.mpi-forum.org > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > >> > >> > > > > _______________________________________________ > > mpi-forum mailing list > > mpi-forum(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > ________________________________________________________________________ > Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm > CASC @ Lawrence Livermore National Laboratory, Livermore, USA > > > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)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)

1 0

Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE
by Supalov, Alexander 24 Jul '12

24 Jul '12

Hi everybody, I see that that my innocent remarks re. Annex A have lead to a lot of discussion. What I'm going to say may resemble Bart Simpson's "I didn't do it", but I think I have to: When commenting on the MPI_T_* names, I meant only their composition that differed from most other comparable MPI constant names in that it was 1) using contractions and 2) not using underscores to separate different words. The MPI_T_CANTINIT was but one example of this. I proposed to change all MPI_T_* names to follow the more traditional rules (i.e., 1) do not use contractions and 2) do use underscores), which lead to the MPI_T_CANNOT_INIT proposal that should be consistently followed up on for every other MPI_T_* name. The MPI_ERR_LASTCODE was mentioned as a counterexample of a known MPI constant name that was not following this set of rules either. Oh well, this is an old one and we won't change it. At no time did I intend the MPI_T series to become a part of the MPI_ERR series, although I must admit that they look really close when you start thinking about them. We will probably have enough time for this contemplation in the MPI 3.1 time frame. To sum up, my proposal now is: 1) Consider replacing contractions in all MPI_T_* names 2) Consider using underscores in all MPI_T_* names 3) Drop the MPI_ERR and MPI_T connection idea And if 1) and 2) are considered too invasive at this point, I won't go nuts either: after all, these are just constant names. Best regards. Alexander -----Original Message----- From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Schulz, Martin Sent: Tuesday, July 24, 2012 8:19 AM To: Main MPI Forum mailing list Subject: Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE Hi Adam, all, I don't think that is necessary in this case. The way the tools section is written right now, all MPI_T return codes are well defined and can be interpreted without translating them. In addition to that, I don't like the idea of creating a separate number space (aside from the issue that this is very invasive at this point): it is not really consistent with MPI_T functions being part of the MPI namespace (as requested by the forum during one of the readings) and it also provides no clean way for tools, in particular PMPI tools that use MPI_T, to return MPI_T return codes as error conditions for MPI routines. Martin On Jul 23, 2012, at 4:45 PM, Adam T. Moody wrote: > This reminds me of the discussions we had on datatypes, regarding > which datatypes are available and can be used before MPI_Init is called. > Since people weren't keen on the fact of duplicating all of the > datatypes and associated routines for MPI_T, in that case, we boiled > down the list of datatypes allowed in MPI_T to a very limited set of > the existing MPI datatypes, and then required that implementations > support these after MPI_T_INIT but before MPI_INIT. > > I think it's best to resolve this cleanly, even if that means things > are undefined between now and 3.1. I can think of two "clean" ways to > resolve this: > > 1) remove all overlap of MPI_T_ and MPI_ error codes, i.e., MPI_T_ > errors live in a separate space from MPI_ errors, 0 = MPI_T_SUCCESS < > MPI_T_* < MPI_T_LAST_ERRCODE, and introduce new corresponding > MPI_T_ERROR_CLASS/STRING functions that can be invoked after > MPI_T_INIT. Then all MPI_T functions return MPI_T error codes (and > only MPI_T error codes), which must be interpretted with the new > MPI_T_ERROR* functions. Personally, it feels a little strange to pass > an MPI_T_ error code to standard MPI_ functions, since we've otherwise > separated the interfaces as much as possible. > > 2) Specify that MPI_T error codes can be passed to the existing > MPI_ERROR* functions, but require that implementations allow one to > call these functions before MPI_INIT (at least for MPI_T_ error codes). > > By the way, does the standard say anything about calling MPI_ERROR* > functions before MPI_INIT? What if someone wanted to process an error > code returned from one of the functions you are allowed to call before > MPI_INIT, such as MPI_INITIALIZED? > -Adam > > > Bronis R. de Supinski wrote: > >> These are good points. I withdraw my agreement to the changes until >> Martin or Rolf addresses them. >> >> On Mon, 23 Jul 2012, 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(a)lists.mpi-forum.org [mailto:mpi-forum- >>>> bounces(a)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(a)llnl.gov> >>>>>>>> To: "Main MPI Forum mailing list" >>>>>>>> <mpi-forum(a)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(a)llnl.gov> >>>>>>>>>> To: "Main MPI Forum mailing list" >>>>>>>>>> <mpi-forum(a)lists.mpi-forum.org> >>>>>>>>>> Cc: "Rolf Rabenseifner" <rabenseifner(a)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-withou >>>>>>>>>>>> t- >>>>>>>>>>>> >>>>>>>>>>>> >>>> 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(a)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(a)lists.mpi-forum.org >>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> -- >>>>>>>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email >>>>>>>>> rabenseifner(a)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(a)lists.mpi-forum.org >>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>> ___________________________________________________________________ >>>> ___ >>>> __ >>>> >>>> >>>>>>>> Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm >>>>>>>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> mpi-forum mailing list >>>>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email >>>>>>> rabenseifner(a)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(a)llnl.gov, http://people.llnl.gov/schulzm >>>>>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mpi-forum mailing list >>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> mpi-forum mailing list >>>>> mpi-forum(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> mpi-forum mailing list >>>> mpi-forum(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>> >>>> >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>> >>> >>> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> >> > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer, Christian Lamprechter Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

1 0

Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE
by Schulz, Martin 24 Jul '12

24 Jul '12

Hi Adam, all, I don't think that is necessary in this case. The way the tools section is written right now, all MPI_T return codes are well defined and can be interpreted without translating them. In addition to that, I don't like the idea of creating a separate number space (aside from the issue that this is very invasive at this point): it is not really consistent with MPI_T functions being part of the MPI namespace (as requested by the forum during one of the readings) and it also provides no clean way for tools, in particular PMPI tools that use MPI_T, to return MPI_T return codes as error conditions for MPI routines. Martin On Jul 23, 2012, at 4:45 PM, Adam T. Moody wrote: > This reminds me of the discussions we had on datatypes, regarding which > datatypes are available and can be used before MPI_Init is called. > Since people weren't keen on the fact of duplicating all of the > datatypes and associated routines for MPI_T, in that case, we boiled > down the list of datatypes allowed in MPI_T to a very limited set of the > existing MPI datatypes, and then required that implementations support > these after MPI_T_INIT but before MPI_INIT. > > I think it's best to resolve this cleanly, even if that means things are > undefined between now and 3.1. I can think of two "clean" ways to > resolve this: > > 1) remove all overlap of MPI_T_ and MPI_ error codes, i.e., MPI_T_ > errors live in a separate space from MPI_ errors, 0 = MPI_T_SUCCESS < > MPI_T_* < MPI_T_LAST_ERRCODE, and introduce new corresponding > MPI_T_ERROR_CLASS/STRING functions that can be invoked after > MPI_T_INIT. Then all MPI_T functions return MPI_T error codes (and only > MPI_T error codes), which must be interpretted with the new MPI_T_ERROR* > functions. Personally, it feels a little strange to pass an MPI_T_ > error code to standard MPI_ functions, since we've otherwise separated > the interfaces as much as possible. > > 2) Specify that MPI_T error codes can be passed to the existing > MPI_ERROR* functions, but require that implementations allow one to call > these functions before MPI_INIT (at least for MPI_T_ error codes). > > By the way, does the standard say anything about calling MPI_ERROR* > functions before MPI_INIT? What if someone wanted to process an error > code returned from one of the functions you are allowed to call before > MPI_INIT, such as MPI_INITIALIZED? > -Adam > > > Bronis R. de Supinski wrote: > >> These are good points. I withdraw my agreement to the changes >> until Martin or Rolf addresses them. >> >> On Mon, 23 Jul 2012, 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(a)lists.mpi-forum.org [mailto:mpi-forum- >>>> bounces(a)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(a)llnl.gov> >>>>>>>> To: "Main MPI Forum mailing list" <mpi-forum(a)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(a)llnl.gov> >>>>>>>>>> To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >>>>>>>>>> Cc: "Rolf Rabenseifner" <rabenseifner(a)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(a)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(a)lists.mpi-forum.org >>>>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> -- >>>>>>>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email >>>>>>>>> rabenseifner(a)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(a)lists.mpi-forum.org >>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>> ______________________________________________________________________ >>>> __ >>>> >>>> >>>>>>>> Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm >>>>>>>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> mpi-forum mailing list >>>>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)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(a)llnl.gov, http://people.llnl.gov/schulzm >>>>>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mpi-forum mailing list >>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> mpi-forum mailing list >>>>> mpi-forum(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> mpi-forum mailing list >>>> mpi-forum(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>> >>>> >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>> >>> >>> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> >> > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE
by Schulz, Martin 24 Jul '12

24 Jul '12

Hi Kathryn, all, On Jul 23, 2012, at 1: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? That's more or less what the last proposal is - we have MPI_T return codes and those should be treated as MPI error classes. I guess we always refrained from calling them error classes or error codes since we put more constraints on them wrt. their influence on the overall execution and because we defined them more closely. > I think that MPI calls return codes and the codes are translated to classes by the MPI_ERROR_CLASS function. That's not how it was intended. I agree, though, we didn't formulate this in the most optimal way. > 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? Yes, I agree - that's the intent of the big table at the end of the tools section - fixed return codes for each condition, such that one needs no translation. That's also why I like the currently proposed formulation of having MPI_T return codes that are (only) treated the same as MPI error classes. There were only two reasons why we stuck them at the end into the same number space as MPI error classes or codes: a) it should be possible to return an MPI_T error as a return value of an MPI function (e.g., if the call got intercepted using PMPI and the wrapper uses MPI_T) and b) it was consistent with shifting from MPIT (separate name space) to MPI as the prefix. Martin > > Does anyone have different insight on error codes vs classes? > > Kathryn > >> -----Original Message----- >> From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:mpi-forum- >> bounces(a)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(a)llnl.gov> >>>>>> To: "Main MPI Forum mailing list" <mpi-forum(a)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(a)llnl.gov> >>>>>>>> To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >>>>>>>> Cc: "Rolf Rabenseifner" <rabenseifner(a)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(a)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(a)lists.mpi-forum.org >>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email >>>>>>> rabenseifner(a)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(a)lists.mpi-forum.org >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>>> >>>>>> >> ______________________________________________________________________ >> __ >>>>>> Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm >>>>>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mpi-forum mailing list >>>>>> mpi-forum(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>>>> >>>>> -- >>>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)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(a)llnl.gov, http://people.llnl.gov/schulzm >>>> CASC @ Lawrence Livermore National Laboratory, Livermore, USA >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> mpi-forum mailing list >>>> mpi-forum(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>> >>> >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0