January 2008 - Mpi-21 - mailman3.cels.anl.gov

Ballot 4 - Re: Request for interpretation
by unknown＠example.com 30 Jan '08

30 Jan '08

This is a proposal for MPI 2.1, Ballot 4. I'm asking especially Linda Stanberry, Bill Gropp, rajeev Thakur, Dick Treumann, Raja Daoud, the participants of the email-discussion in 1999, to review this proposal. This is a follow up to: What info keys can be set? in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.… with mail discussion in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… ___________________________________ Background: The sentence MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38 "If a function does not recognize a key, it will ignore it, unless otherwise specified." was interpreted in two different ways: 1. This sentence is only valid in the routines in other chapters (e.g. processs creation and management, one-sided communication, parallel file I/O) where infos may be used to specify portable and implementation defined hints. 2. This interpretation is also valid for MPI_INFO_DELETE, MPI_INFO_SET, MPI_INFO_GET, and MPI_INFO_DUP. The following proposal ist based on Option 1. Option 2 is rejected due to the reason shown after the proposal. ___________________________________ Proposal: MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38 read: If a function does not recognize a key, it will ignore it, unless otherwise specified. but should read: If a function in another section of the MPI standard does not recognize a key, it will ignore it, unless otherwise specified. The routines in this section. The functions in this section must not ignore any (key,value) pair. Add after MPI 2.0, Sect. 4.10 Info Objects, page 44, line 22 a new paragraph: Advice to implementors. For optimization, an MPI implementation may already sort out which (key,value) pair can be recognized for use in other chapters (e.g., in processs creation and management, one-sided communication, parallel file I/O) to guarantee a fast access to the appropriate information when used in routines of those chapters. For porpose of MPI_INFO_GET_NKEYS, MPI_INFO_GET_NTHKEY, MPI_INFO_GET_VALUELEN, and MPI_INFO_GET, the implementation must still keep also all other (key,value) pairs that cannot be recognized by that MPI implementation. (End of advice to implementors.) ________________________________ Rationale for this clarification: The first of the two interpretation options mentioned in the background information is the only valid interpretation when we assume, that layered implementation of parts of the MPI-2 standard should be possible. This was a goal of the MPI-2 Forum and the MPI-2.0 specification. ___________________________________ Comment: In the discussion (see the mails from 1999) one can clearly see, that an implementation of option 2 (done by IBM) cannot coexist with a layered implementation of MPI parallel file I/O, because MPI parallel file I/O routine need a different implementation of the INFO routines. Other chapters of MPI (e.g. 1-sided) need the original INF implementation. Two different INFO implementations cannot coexist in the same MPI library. We could see the ouutcome of such problems with MPI_Wait & co. as long as a generalized request concept was not available. ROMIO had to define non-standard MPIO_Wait & co. routines. And they persist for a long time! Without the clarification above, we have the same problem with the INFO handling. Best regards Rolf Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] 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

MPI 2.1 protocol from Jan. 2008 meeting of the MPI Forum
by unknown＠example.com 30 Jan '08

30 Jan '08

Dear all, I have done the protocol of the MPI 2.1 sessions of the Jan. 2008 meeting in form of a copy of the slides. I modified the slides in the way that they already reflect the decisions made by the Forum, e.g., names are now MPI 2.1 and MPI 1.3. Bill has stored the protocol on the web-pages at http://mpi-forum.cs.uiuc.edu/meetings/2008/JAN-14/mpi_21_at_MPIforum_2008-0… Best regards Rolf Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] 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-21] Reading of Chapter 4
by unknown＠example.com 30 Jan '08

30 Jan '08

Thank you for your detailed reading of MPI 2.0 Chapter 4. Some comments and answers are inline below. Most will be for MPI 2.1 Ballot 4. Therefore, I switched the mail distribution to mpi-21_at_[hidden] On Wed, 9 Jan 2008 12:07:24 +0100 Jesper Larsson Traeff <traff_at_it.neclab.eu> wrote: > >Dear all, > >I have read Chapter 4 - here are my corrections, comments and suggestions >(only things not already in the errata sheet from Jan 30, 2002). There is >little of great substance. > >I have prefixed the comments as follows: >(typo) - uncontroversial typo/misspelling, should be corrected >(suggestion) - suggestion for alternative wording/extra comment >(addition) - suggestion for addition >(comment) - my comment, not intended for standard document > >General typo: is "implementor" (with an "o") a word in US English? >Shouldn't it be "Implementers"? (as in "Advice to implementers") > >General comments: the chapter is quite awful, and in the longer run I >would be in favor of having the parts (e.g. on datatypes) moved to >the chapters where they belong properly. I think Rolf will be doing some >of this. >I would also suggest having a special chapter in the new 2.1 >document summarizing all deprecated functionality (with a short rationale >as to why the function was deprecated) > >For mnemonic reasons, I would suggest having all datatype constructors >being of the form > >MPI_TYPE_CREATE_XXX > >and thus deprecate MPI_TYPE_CONTIGUOUS and MPI_TYPE_VECTOR as well. >It could also be argued to have an MPI_TYPE_CREATE_HINDEXED_BLOCK as >counterpart to MPI_TYPE_CREATE_INDEXED_BLOCK (but I am not making a >strong suggestion). > >best regards > >Jesper > >Chapter 4: >---------- > >Page 37, line 44-46: >(suggestion) drop, since this is largely a repetition of lines 34-36 >(except the statement "It is not suggested that this be the only way..." --> Ballot 4 > Page 43, line 33-34: >(suggestion) change "It consists of (key,value) pairs" to >"It stores a(n unordered) set of (key,value) pairs" to emphasize that the >info object is a kind of dictionary (data structure) --> Ballot 4 > >Page 43, line 34: >(suggestion) replace "may have only one value" by "can have only one value" --> Ballot 4 > >Page 43, line 37: > >(addition) "An empty info object is denoted by MPI_INFO_NULL." --> Ballot 4 Page 43, line 37: >(comment/discussion) The default is that the "null handle" is not >allowed as an IN argument (see MPI 1, Page 8, line 28), unless >explicitly allowed. This explicit permission is missing at some >places in MPI-2 (I found two): MPI_WIN_CREATE, page 111, and >MPI_FILE_SET_INFO, page 218. Is this default interpretation also intended >for MPI_INFO_NULL? A sentence on this would be in order, since the >info object is introduced here:" It is erroneous to pass MPI_INFO_NULL >as an IN argument, unless where explicitly allowed" (or whatever appropriate >depending on the intended interpretation). No, because MPI-1.1, Sect. 2.4.1, Page 8, line 28 is no longer valid. Whole Chapter 2 is substituted by MPI 2.0, Chapter 2. And in MPI 2.0, Sect. 2.5.1, Pages 8-9 the cited paragraph is removed. >Page 47, line 1: >(suggestion) change "Keys are numbered..." to >"At any point in time, keys are numbered consecutively from 0 to N-1, where..." If it is okay, I would ignore this, because it isn't a clarification. >Page 47, line 32: >(addition) >"Advice to implementers: The info object is a dictionary, and can be >implemented by a suitable data structure. Since the number of (key,value) >pairs can normally be assumed to be small a linear list implementation >will often suffice." This must be handled in the discussion thread "What info keys can be set?" on the errata page and http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… I will continue on that thread with a ballot 4 proposal. >Page 49, line 21: >(addition) to align with the Fortran example 4.7, add C comment >"/* no memory is allocated */" --> Ballot 4 > >Page 49, line 22: >(addition) to make consistent with Fortran example, add line: >/* memory allocated */ --> Ballot 4 > >Page 50, line 9: >(type) remove first "in" --> Ballot 4 > >Page 55, line 26: >(comment) is this good Fortran style - scalars, e.g. 5 and MPI_REAL, >as implicit arrays of size 1? For a C programmer this is hurtful, and >some Fortran compilers do complain. I would suggest declaring the >proper arrays, so as to make the example more readily understandable, >also to the Fortran non-expert. Same goes for the similar Example 4.14 >on Page 60. --> Ballot 4 with following details: MPI 2.0, Sect. 4.12.6, Exa. 4.12, page 55, line 21-22 read: INTEGER TYPE, IERR INTEGER (KIND=MPI_ADDRESS_KIND) ADDR but should read: INTEGER TYPE, IERR, AOBLEN(1), AOTYPE(1) INTEGER (KIND=MPI_ADDRESS_KIND) AODISP(1) MPI 2.0, Sect. 4.12.6, Exa. 4.12, page 55, line 25-26 read: CALL MPI_GET_ADDRESS( R, ADDR, IERR) CALL MPI_TYPE_CREATE_STRUCT(1, 5, ADDR, MPI_REAL, TYPE, IERR) but should read: AOBLEN(1) = 5 CALL MPI_GET_ADDRESS( R, AODISP(1), IERR) AOTYPE(1) = MPI_REAL CALL MPI_TYPE_CREATE_STRUCT(1, AOBLEN(1),AODISP(1),AOTYPE(1), TYPE, IERR) MPI 2.0, Sect. 4.12.10, Exa. 4.14, page 60, line 31-32 read: INTEGER TYPE, IERR, MYRANK INTEGER (KIND=MPI_ADDRESS_KIND) ADDR but should read: INTEGER TYPE, IERR, MYRANK, AOBLEN(1), AOTYPE(1) INTEGER (KIND=MPI_ADDRESS_KIND) AODISP(1) MPI 2.0, Sect. 4.12.10, Exa. 4.14, page 55, line 35-36 read: CALL MPI_GET_ADDRESS( R, ADDR, IERR) CALL MPI_TYPE_CREATE_STRUCT(1, 5, ADDR, MPI_REAL, TYPE, IERR) but should read: AOBLEN(1) = 5 CALL MPI_GET_ADDRESS( R, AODISP(1), IERR) AOTYPE(1) = MPI_REAL CALL MPI_TYPE_CREATE_STRUCT(1, AOBLEN(1),AODISP(1),AOTYPE(1), TYPE, IERR) > >Page 56, line 29: >(typo) "assciated" should be "associated" --> Ballot 4 > >Page 67, line 18: >(suggestion) change "array of integer" to "array of nonnegative integer" >(shouldn't it be "integers"?) - to make consistent with HVECTOR and >HINDEXED. >(comment) There was an email discussion about 0-blocklengths, and >although it did not go very far, I think the conclusion was that >0-blocklengths are allowed and give rise to no element in the type >map. I think that some changes in the MPI-1 rules for how type maps >are generated by the INDEXED and STRUCT constructors are needed to >make this precise and correct. I have put this into the thread "Block lengths of zero in MPI Datatypes" http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… >Page 70-77: >(comment) Two pictures illustrating the subarray and distributed array >constructors would be really helpful. May be nice to have. > >Page 74, line 9: >(typo) "is" missing in "it erroneous" --> Ballot 4 > >Chapter 5: >---------- > >Page 85, line 25: >(typo) "as the as the" should be "as the" --> Ballot 4 > Best regards Rolf Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] 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-21] Intended meaning of zero blocklengths in MPI_Type_indexed/MPI_Type_create_struct
by unknown＠example.com 29 Jan '08

29 Jan '08

Yes, agreed, your text fits better to the clarification needs. Rolf On Tue, 29 Jan 2008 13:26:04 -0500 Richard Treumann <treumann_at_[hidden]> wrote: >How about this? > > > Most datatype constructors have replication count or block > length arguments. Allowed values are nonnegative integers. > If the value is zero, no elements are generated in the type map > and there is no effect on datatype bounds or extent. > >I think it is bounds and extent that were questioned. I think it is self >evident that a zero value cannot affect the type signature. > >Dick Treumann - MPI Team/TCEM >IBM Systems & Technology Group >Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 >Tele (845) 433-7846 Fax (845) 433-8363 > > >mpi-21-bounces_at_[hidden] wrote on 01/29/2008 12:43:02 PM: > >> This is a proposal for MPI 2.1, Ballot 4. >> >> This is a follow up to: >> Block lengths of zero in MPI Datatypes >> in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- >> errata/index.html >> with mail discussion in >> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- >> errata/discuss/blklenzero/ >> ___________________________________ >> >> Proposal: >> Add the following paragraph in MPI 1.1, Sect. 3.12, page 62, >> after line 2 (i.e., after ... "of the types defined by Typesig."): >> >> Most datatype constructors have replication count or block >> length arguments. Allowed values are nonnegative integers. >> If the value is zero, no elements are generated in the type map >> nor in the type signature for this entry in the argument list. >> >> MPI 1.1, Sect 3.12.1, MPI_TYPE_HINDEXED, page 67, line 22-24 read: >> IN count number of blocks â also number of entries in >> array_of_displacements and array_of_blocklengths >> (integer) >> but should read: >> IN count number of blocks â also number of entries in >> array_of_displacements and array_of_blocklengths >> (nonnegative integer) >> >> >> MPI 1.1, Sect 3.12.1, MPI_TYPE_STRUCT, page 68, line 19-22 read: >> IN count number of blocks (integer) â also number >> of entries in arrays array_of_types, >> array_of_displacements and array_of_blocklengths >> IN array of blocklength number of elements in each >> block (array of integer) >> but should read: >> IN count number of blocks (nonnegative integer) â also number >> of entries in arrays array_of_types, >> array_of_displacements and array_of_blocklengths >> IN array of blocklength number of elements in each >> block (array of nonnegative integer) >> >> >> MPI 2.0, Sect 4.14.1, MPI_TYPE_CREATE_HINDEXED, page 66, line 36-38 read: >> IN count number of blocks â also number of entries in >> array_of_displacements and array_of_blocklengths >> (integer) >> but should read: >> IN count number of blocks â also number of entries in >> array_of_displacements and array_of_blocklengths >> (nonnegative integer) >> >> >> MPI 2.0, Sect 4.14.1, MPI_TYPE_CREATE_STRUCT, page 67, line 14-18 read: >> IN count number of blocks (integer) â also number >> of entries in arrays array_of_types, >> array_of_displacements and array_of_blocklengths >> IN array of blocklength number of elements in each >> block (array of integer) >> but should read: >> IN count number of blocks (nonnegative integer) â also number >> of entries in arrays array_of_types, >> array_of_displacements and array_of_blocklengths >> IN array of blocklength number of elements in each >> block (array of nonnegative integer) >> ___________________________________ >> >> Rationale for this clarification and modification: >> The outcome of zero-count entries in the type map was not defined. >> For this, a clarification was needed. >> The interfaces of HINDEXED and STRUCT was inconsistent to the rest >> derived datatype routines. This was probably due to editing errors. >> A meaning of negative values was never defined not intended. >> Therefore, portable applications could not use negative values. >> These editing errors are fixed by this proposal. >> ___________________________________ >> >> >> I hope, I could catch all the problems Jesper mentioned in his mail. >> >> Best regards >> Rolf >> >> On Tue, 29 Jan 2008 15:02:10 +0100 >> Jesper Larsson Traeff <traff_at_it.neclab.eu> wrote: >> > >> >Dear Rolf, >> > >> >(thanks for all the work you are putting into this!) >> > >> >On Tue, Jan 29, 2008 at 12:47:14PM +0100, Rolf Rabenseifner wrote: >> >> Reply is off-line from the mailing list. >> >> >> >> Dear Jesper and Bill, >> >> >> >> I believe that this is not a topic for the one and final shot >> >> of MPI 2.1 Ballot 4 in the next (March 2008) meeting. >> >> Therefore, I would propose to handle it in MPI 2.2. >> >> >> >In the MPI-1 document (p.66, p.68) index and struct types are treated >> >differently. For index, blocklength is an array of non-negative integers >> >(p.66, line 12), for struct, just an array of integers (p. 68, line 22). >> >Same inconsistency for the new MPI-2 types, p.66 and p.67. >> >I believe that this should at least be made consistent. >> > >> >I would also be in favor of a small remark that 0 blocklengths are >allowed, >> >with the remarks that these are (of course) not included in the type >map. >> > >> >Btw, I will be coming to the meeting in March >> > >> >best regards >> > >> >Jesper >> > >> >> Jesper, you have not been at Jan meeting. Therefore a short >background. >> >> We decided, that MPI 2.1 is mainly the combining of the MPI 1.1 >> >> and 2.0 documents to one MPI 2.1 standard. >> >> Additionally the existing MPI 1.1 errata, and the MPI-2 electonically >> >> voted Ballots 1 & 2, and the Jan. meeting Ballot 3 and the March >meeting >> >> Ballot 4 are included. Topics that do not get final official reading >> >> in these meetings are forwarded to MPI 2.2. >> >> >> >> Therefore I try to have mainly items in Ballot 3 and 4 that do not >> >> need longer discussions and that are mainly obvious, i.e., that can >> >> be shown on one or two slides together with needed background infos. >> >> >> >> Implication for me: I do not put your item on my MPI 2.1 agenda. >> >> >> >> Okay? >> >> >> >> Best regards >> >> Rolf >> >> >> >> On Mon, 23 Apr 2007 17:10:35 +0200 >> >> Jesper Larsson Traeff <traff_at_[hidden]> wrote: >> >> > >> >> >(ps: also sent to mpi-core_at_[hidden] - did anybody get it from >there?) >> >> > >> >> >Dear MPI forum, >> >> > >> >> >an old discussion (July-September 2001) concluded that blocklengths >of >> >> >value zero are allowed in MPI indexed and struct types. Reading the >> >> >standard, both text and specification (p.66ff), such "blocks" >generate >> >> >no entries in the corresponding type maps, at least this seems to be >> >> >the idea - and implementations like mpich2 follow this >interpretation, >> >> >while the original MPICH for instance did not, and maybe with some >right? >> >> > >> >> >The question is what a derived datatype is intended to specify. If >> >> >it specifies just a type map, then clearly blocks of length zero >should >> >> >simply be treated as not being there, and the resulting type map >alone >> >> >defines the extent, lower and upper bounds of the datatype. But if a >> >> >derived datatype is intended as specifying a layout in memory, zero >> >> >length blocks could possibly have another meaning (as markers >oflocations >> >> >in the layout), and in addition to the type map affect the extent, >> >> >lower and upper bound of the datatype. >> >> > >> >> > >> >> >A concrete example >> >> > >> >> > displacements(1)=1 >> >> > displacements(2)=0 >> >> > lengths(1)=1 >> >> > lengths(2)=0 >> >> > >> >> > call >mpi_type_indexed(2,lengths,displacements,MPI_INTEGER,newtype,code) >> >> > call mpi_type_commit(newtype,code) >> >> > >> >> >In the first interpretation (datatypes specify type map) the above >has >> >> >extent 4 (assuming MPI_INTEGER is 4 bytes) and lower bound 4 >> >> > >> >> >In the second interpretation (datatypes specify layout) the above >would >> >> >have lower bound 0 and extent 8 >> >> > >> >> > >> >> >The point is that in the first interpretation (which is the one at >least >> >> >implicitly prescribed by the standard) the layout that was >> possibly intended >> >> >by the user ("something starting at displacement soandso" - >> irrespective of >> >> >whether there is actual data at displacement soandso) can be quite >> >> >arbitrarily collapsed. In an application where datatypes are >generated >> >> >automatically, it might be a high burden on the user to take care of >> >> >the special cases arising by some blocklenghts just happening to >> >> >be zero (either he would have to resize, or to put in explcit >> >> >MPI_LB/MPI_UB markers). >> >> > >> >> >A point could therefore be made for treating blocks of length >> >> >zero still as "markers" in the specification of a layout - as did for >> >> >instance the original MPICH implementation. Some changes in the text >> >> >would be necessary to put this interpretation on a firm foundation. >> >> >That is not the intention here, but only to see if there are opinions >> >> >on this issue? A suggestion would be to add a short paragraph stating >> >> >that zero blocklengths are allowed, and what their effects and >> side-effects >> >> >are. >> >> > >> >> >Jesper >> >> > >> >> > >> >> >Minor clarifications: >> >> > >> >> >p.63, l.39, p.66, l.12, and p.67, l.25 have "nonnegative integer" >> >> >blocklengths, but p. 68, l.22 only has "integer". >> >> >To be consistent P. 68, l.22 should also be "nonnegative integer" >> >> >(negative blocklenghts don't make sense) >> >> > >> >> >(as already pointed out by Steven Huss-Lederman) The specification >> >> >p.66, l.46ff and similarly for MPI_Type_hindexed and MPI_Type_struct >> >> >makes little sense (well, is plain wrong) when some B[i] is >> actually zero. >> >> >First, l.46 forces some elements into the type map [ (type_0, >> disp_0+D[0]) ,,,] >> >> >that shouldn't be there (blocks of length zero shouln't give rise to >any >> >> >elements in the type map), and also l.48 has no real meaning >> >> >when B[0]. Better would be to add two lines after l.48 giving the >general >> >> >case: >> >> > >> >> >(type_0,disp_0+D[i]*ex),...,(type_{n-1},disp_{n-1}+D[i]*ex),..., >> >> >(type_0,disp_0+(D[i]+B[i]-1)*ex,...,(type_{n-1},disp_{n-1}+(D[i] >> +B[i]-1)*ex, >> >> > >> >> >with the proviso that this is empty if B[i]==0 (or even more formally >> >> >precise/correct) >> >> > >> >> >> >> >> >> >> >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] >> >> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 >> >> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 >> >> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner >> >> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) >> >> >> >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] >> 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-21 mailing list >> mpi-21_at_[hidden] >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] 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-21] MPI_FINALIZE
by unknown＠example.com 29 Jan '08

29 Jan '08

I agree. Hubert William Gropp wrote: > I think that we're fine as is, and can move this to the discussed but > require no change page. > > Bill > > On Jan 28, 2008, at 11:52 AM, Rolf Rabenseifner wrote: > >> Mainly to Jeff Squyres, Hubert Ritzdorf, Rolf Rabenseifner, Nicholas >> Nevin, >> Bill Gropp, Dick Treumann >> >> This is a follow up to: >> MPI_FINALIZE in MPI-2 (with spawn) >> in >> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.… >> with mail discussion in >> >> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… >> _________________________________________ >> >> When I understand correctly, then a clarification is not needed >> because the MPI standard expresses all, i.e. >> - MPI_Finalize need not to behave like a barrier >> - but is allowed to have a barrier inside. >> - If the user wants to exit one spawned process while >> the others still continue to work, he/she must >> disconnect this process before calling MPI_Finalize on it. >> >> If somebody wants a clarification to be included into the standard >> and therefore in Ballot 4, please send me your wording >> with the page and line references included. >> >> If all agree, that no clarification is needed, then I would finish >> this track. >> >> Best regards >> Rolf >> >> >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] >> <mailto:rabenseifner_at_[hidden]> >> 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 >> <http://www.hlrs.de/people/rabenseifner> >> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) >> _______________________________________________ >> mpi-21 mailing list >> mpi-21_at_[hidden] <mailto:mpi-21_at_[hidden]> >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 >> > > William Gropp > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > ------------------------------------------------------------------------ > > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > *

1 0

Re: [mpi-21] Intended meaning of zero blocklengths in MPI_Type_indexed/MPI_Type_create_struct
by unknown＠example.com 29 Jan '08

29 Jan '08

How about this? Most datatype constructors have replication count or block length arguments. Allowed values are nonnegative integers. If the value is zero, no elements are generated in the type map and there is no effect on datatype bounds or extent. I think it is bounds and extent that were questioned. I think it is self evident that a zero value cannot affect the type signature. Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-21-bounces_at_[hidden] wrote on 01/29/2008 12:43:02 PM: > This is a proposal for MPI 2.1, Ballot 4. > > This is a follow up to: > Block lengths of zero in MPI Datatypes > in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > errata/index.html > with mail discussion in > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > errata/discuss/blklenzero/ > ___________________________________ > > Proposal: > Add the following paragraph in MPI 1.1, Sect. 3.12, page 62, > after line 2 (i.e., after ... "of the types defined by Typesig."): > > Most datatype constructors have replication count or block > length arguments. Allowed values are nonnegative integers. > If the value is zero, no elements are generated in the type map > nor in the type signature for this entry in the argument list. > > MPI 1.1, Sect 3.12.1, MPI_TYPE_HINDEXED, page 67, line 22-24 read: > IN count number of blocks â also number of entries in > array_of_displacements and array_of_blocklengths > (integer) > but should read: > IN count number of blocks â also number of entries in > array_of_displacements and array_of_blocklengths > (nonnegative integer) > > > MPI 1.1, Sect 3.12.1, MPI_TYPE_STRUCT, page 68, line 19-22 read: > IN count number of blocks (integer) â also number > of entries in arrays array_of_types, > array_of_displacements and array_of_blocklengths > IN array of blocklength number of elements in each > block (array of integer) > but should read: > IN count number of blocks (nonnegative integer) â also number > of entries in arrays array_of_types, > array_of_displacements and array_of_blocklengths > IN array of blocklength number of elements in each > block (array of nonnegative integer) > > > MPI 2.0, Sect 4.14.1, MPI_TYPE_CREATE_HINDEXED, page 66, line 36-38 read: > IN count number of blocks â also number of entries in > array_of_displacements and array_of_blocklengths > (integer) > but should read: > IN count number of blocks â also number of entries in > array_of_displacements and array_of_blocklengths > (nonnegative integer) > > > MPI 2.0, Sect 4.14.1, MPI_TYPE_CREATE_STRUCT, page 67, line 14-18 read: > IN count number of blocks (integer) â also number > of entries in arrays array_of_types, > array_of_displacements and array_of_blocklengths > IN array of blocklength number of elements in each > block (array of integer) > but should read: > IN count number of blocks (nonnegative integer) â also number > of entries in arrays array_of_types, > array_of_displacements and array_of_blocklengths > IN array of blocklength number of elements in each > block (array of nonnegative integer) > ___________________________________ > > Rationale for this clarification and modification: > The outcome of zero-count entries in the type map was not defined. > For this, a clarification was needed. > The interfaces of HINDEXED and STRUCT was inconsistent to the rest > derived datatype routines. This was probably due to editing errors. > A meaning of negative values was never defined not intended. > Therefore, portable applications could not use negative values. > These editing errors are fixed by this proposal. > ___________________________________ > > > I hope, I could catch all the problems Jesper mentioned in his mail. > > Best regards > Rolf > > On Tue, 29 Jan 2008 15:02:10 +0100 > Jesper Larsson Traeff <traff_at_it.neclab.eu> wrote: > > > >Dear Rolf, > > > >(thanks for all the work you are putting into this!) > > > >On Tue, Jan 29, 2008 at 12:47:14PM +0100, Rolf Rabenseifner wrote: > >> Reply is off-line from the mailing list. > >> > >> Dear Jesper and Bill, > >> > >> I believe that this is not a topic for the one and final shot > >> of MPI 2.1 Ballot 4 in the next (March 2008) meeting. > >> Therefore, I would propose to handle it in MPI 2.2. > >> > >In the MPI-1 document (p.66, p.68) index and struct types are treated > >differently. For index, blocklength is an array of non-negative integers > >(p.66, line 12), for struct, just an array of integers (p. 68, line 22). > >Same inconsistency for the new MPI-2 types, p.66 and p.67. > >I believe that this should at least be made consistent. > > > >I would also be in favor of a small remark that 0 blocklengths are allowed, > >with the remarks that these are (of course) not included in the type map. > > > >Btw, I will be coming to the meeting in March > > > >best regards > > > >Jesper > > > >> Jesper, you have not been at Jan meeting. Therefore a short background. > >> We decided, that MPI 2.1 is mainly the combining of the MPI 1.1 > >> and 2.0 documents to one MPI 2.1 standard. > >> Additionally the existing MPI 1.1 errata, and the MPI-2 electonically > >> voted Ballots 1 & 2, and the Jan. meeting Ballot 3 and the March meeting > >> Ballot 4 are included. Topics that do not get final official reading > >> in these meetings are forwarded to MPI 2.2. > >> > >> Therefore I try to have mainly items in Ballot 3 and 4 that do not > >> need longer discussions and that are mainly obvious, i.e., that can > >> be shown on one or two slides together with needed background infos. > >> > >> Implication for me: I do not put your item on my MPI 2.1 agenda. > >> > >> Okay? > >> > >> Best regards > >> Rolf > >> > >> On Mon, 23 Apr 2007 17:10:35 +0200 > >> Jesper Larsson Traeff <traff_at_[hidden]> wrote: > >> > > >> >(ps: also sent to mpi-core_at_[hidden] - did anybody get it from there?) > >> > > >> >Dear MPI forum, > >> > > >> >an old discussion (July-September 2001) concluded that blocklengths of > >> >value zero are allowed in MPI indexed and struct types. Reading the > >> >standard, both text and specification (p.66ff), such "blocks" generate > >> >no entries in the corresponding type maps, at least this seems to be > >> >the idea - and implementations like mpich2 follow this interpretation, > >> >while the original MPICH for instance did not, and maybe with some right? > >> > > >> >The question is what a derived datatype is intended to specify. If > >> >it specifies just a type map, then clearly blocks of length zero should > >> >simply be treated as not being there, and the resulting type map alone > >> >defines the extent, lower and upper bounds of the datatype. But if a > >> >derived datatype is intended as specifying a layout in memory, zero > >> >length blocks could possibly have another meaning (as markers oflocations > >> >in the layout), and in addition to the type map affect the extent, > >> >lower and upper bound of the datatype. > >> > > >> > > >> >A concrete example > >> > > >> > displacements(1)=1 > >> > displacements(2)=0 > >> > lengths(1)=1 > >> > lengths(2)=0 > >> > > >> > call mpi_type_indexed(2,lengths,displacements,MPI_INTEGER,newtype,code) > >> > call mpi_type_commit(newtype,code) > >> > > >> >In the first interpretation (datatypes specify type map) the above has > >> >extent 4 (assuming MPI_INTEGER is 4 bytes) and lower bound 4 > >> > > >> >In the second interpretation (datatypes specify layout) the above would > >> >have lower bound 0 and extent 8 > >> > > >> > > >> >The point is that in the first interpretation (which is the one at least > >> >implicitly prescribed by the standard) the layout that was > possibly intended > >> >by the user ("something starting at displacement soandso" - > irrespective of > >> >whether there is actual data at displacement soandso) can be quite > >> >arbitrarily collapsed. In an application where datatypes are generated > >> >automatically, it might be a high burden on the user to take care of > >> >the special cases arising by some blocklenghts just happening to > >> >be zero (either he would have to resize, or to put in explcit > >> >MPI_LB/MPI_UB markers). > >> > > >> >A point could therefore be made for treating blocks of length > >> >zero still as "markers" in the specification of a layout - as did for > >> >instance the original MPICH implementation. Some changes in the text > >> >would be necessary to put this interpretation on a firm foundation. > >> >That is not the intention here, but only to see if there are opinions > >> >on this issue? A suggestion would be to add a short paragraph stating > >> >that zero blocklengths are allowed, and what their effects and > side-effects > >> >are. > >> > > >> >Jesper > >> > > >> > > >> >Minor clarifications: > >> > > >> >p.63, l.39, p.66, l.12, and p.67, l.25 have "nonnegative integer" > >> >blocklengths, but p. 68, l.22 only has "integer". > >> >To be consistent P. 68, l.22 should also be "nonnegative integer" > >> >(negative blocklenghts don't make sense) > >> > > >> >(as already pointed out by Steven Huss-Lederman) The specification > >> >p.66, l.46ff and similarly for MPI_Type_hindexed and MPI_Type_struct > >> >makes little sense (well, is plain wrong) when some B[i] is > actually zero. > >> >First, l.46 forces some elements into the type map [ (type_0, > disp_0+D[0]) ,,,] > >> >that shouldn't be there (blocks of length zero shouln't give rise to any > >> >elements in the type map), and also l.48 has no real meaning > >> >when B[0]. Better would be to add two lines after l.48 giving the general > >> >case: > >> > > >> >(type_0,disp_0+D[i]*ex),...,(type_{n-1},disp_{n-1}+D[i]*ex),..., > >> >(type_0,disp_0+(D[i]+B[i]-1)*ex,...,(type_{n-1},disp_{n-1}+(D[i] > +B[i]-1)*ex, > >> > > >> >with the proviso that this is empty if B[i]==0 (or even more formally > >> >precise/correct) > >> > > >> > >> > >> > >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > >> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > >> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > >> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > >> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > 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-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 *

1 0

Re: [mpi-21] Intended meaning of zero blocklengths in MPI_Type_indexed/MPI_Type_create_struct
by unknown＠example.com 29 Jan '08

29 Jan '08

This is a proposal for MPI 2.1, Ballot 4. This is a follow up to: Block lengths of zero in MPI Datatypes in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.… with mail discussion in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… ___________________________________ Proposal: Add the following paragraph in MPI 1.1, Sect. 3.12, page 62, after line 2 (i.e., after ... "of the types defined by Typesig."): Most datatype constructors have replication count or block length arguments. Allowed values are nonnegative integers. If the value is zero, no elements are generated in the type map nor in the type signature for this entry in the argument list. MPI 1.1, Sect 3.12.1, MPI_TYPE_HINDEXED, page 67, line 22-24 read: IN count number of blocks  also number of entries in array_of_displacements and array_of_blocklengths (integer) but should read: IN count number of blocks  also number of entries in array_of_displacements and array_of_blocklengths (nonnegative integer) MPI 1.1, Sect 3.12.1, MPI_TYPE_STRUCT, page 68, line 19-22 read: IN count number of blocks (integer)  also number of entries in arrays array_of_types, array_of_displacements and array_of_blocklengths IN array of blocklength number of elements in each block (array of integer) but should read: IN count number of blocks (nonnegative integer)  also number of entries in arrays array_of_types, array_of_displacements and array_of_blocklengths IN array of blocklength number of elements in each block (array of nonnegative integer) MPI 2.0, Sect 4.14.1, MPI_TYPE_CREATE_HINDEXED, page 66, line 36-38 read: IN count number of blocks  also number of entries in array_of_displacements and array_of_blocklengths (integer) but should read: IN count number of blocks  also number of entries in array_of_displacements and array_of_blocklengths (nonnegative integer) MPI 2.0, Sect 4.14.1, MPI_TYPE_CREATE_STRUCT, page 67, line 14-18 read: IN count number of blocks (integer)  also number of entries in arrays array_of_types, array_of_displacements and array_of_blocklengths IN array of blocklength number of elements in each block (array of integer) but should read: IN count number of blocks (nonnegative integer)  also number of entries in arrays array_of_types, array_of_displacements and array_of_blocklengths IN array of blocklength number of elements in each block (array of nonnegative integer) ___________________________________ Rationale for this clarification and modification: The outcome of zero-count entries in the type map was not defined. For this, a clarification was needed. The interfaces of HINDEXED and STRUCT was inconsistent to the rest derived datatype routines. This was probably due to editing errors. A meaning of negative values was never defined not intended. Therefore, portable applications could not use negative values. These editing errors are fixed by this proposal. ___________________________________ I hope, I could catch all the problems Jesper mentioned in his mail. Best regards Rolf On Tue, 29 Jan 2008 15:02:10 +0100 Jesper Larsson Traeff <traff_at_it.neclab.eu> wrote: > >Dear Rolf, > >(thanks for all the work you are putting into this!) > >On Tue, Jan 29, 2008 at 12:47:14PM +0100, Rolf Rabenseifner wrote: >> Reply is off-line from the mailing list. >> >> Dear Jesper and Bill, >> >> I believe that this is not a topic for the one and final shot >> of MPI 2.1 Ballot 4 in the next (March 2008) meeting. >> Therefore, I would propose to handle it in MPI 2.2. >> >In the MPI-1 document (p.66, p.68) index and struct types are treated >differently. For index, blocklength is an array of non-negative integers >(p.66, line 12), for struct, just an array of integers (p. 68, line 22). >Same inconsistency for the new MPI-2 types, p.66 and p.67. >I believe that this should at least be made consistent. > >I would also be in favor of a small remark that 0 blocklengths are allowed, >with the remarks that these are (of course) not included in the type map. > >Btw, I will be coming to the meeting in March > >best regards > >Jesper > >> Jesper, you have not been at Jan meeting. Therefore a short background. >> We decided, that MPI 2.1 is mainly the combining of the MPI 1.1 >> and 2.0 documents to one MPI 2.1 standard. >> Additionally the existing MPI 1.1 errata, and the MPI-2 electonically >> voted Ballots 1 & 2, and the Jan. meeting Ballot 3 and the March meeting >> Ballot 4 are included. Topics that do not get final official reading >> in these meetings are forwarded to MPI 2.2. >> >> Therefore I try to have mainly items in Ballot 3 and 4 that do not >> need longer discussions and that are mainly obvious, i.e., that can >> be shown on one or two slides together with needed background infos. >> >> Implication for me: I do not put your item on my MPI 2.1 agenda. >> >> Okay? >> >> Best regards >> Rolf >> >> On Mon, 23 Apr 2007 17:10:35 +0200 >> Jesper Larsson Traeff <traff_at_[hidden]> wrote: >> > >> >(ps: also sent to mpi-core_at_[hidden] - did anybody get it from there?) >> > >> >Dear MPI forum, >> > >> >an old discussion (July-September 2001) concluded that blocklengths of >> >value zero are allowed in MPI indexed and struct types. Reading the >> >standard, both text and specification (p.66ff), such "blocks" generate >> >no entries in the corresponding type maps, at least this seems to be >> >the idea - and implementations like mpich2 follow this interpretation, >> >while the original MPICH for instance did not, and maybe with some right? >> > >> >The question is what a derived datatype is intended to specify. If >> >it specifies just a type map, then clearly blocks of length zero should >> >simply be treated as not being there, and the resulting type map alone >> >defines the extent, lower and upper bounds of the datatype. But if a >> >derived datatype is intended as specifying a layout in memory, zero >> >length blocks could possibly have another meaning (as markers of locations >> >in the layout), and in addition to the type map affect the extent, >> >lower and upper bound of the datatype. >> > >> > >> >A concrete example >> > >> > displacements(1)=1 >> > displacements(2)=0 >> > lengths(1)=1 >> > lengths(2)=0 >> > >> > call mpi_type_indexed(2,lengths,displacements,MPI_INTEGER,newtype,code) >> > call mpi_type_commit(newtype,code) >> > >> >In the first interpretation (datatypes specify type map) the above has >> >extent 4 (assuming MPI_INTEGER is 4 bytes) and lower bound 4 >> > >> >In the second interpretation (datatypes specify layout) the above would >> >have lower bound 0 and extent 8 >> > >> > >> >The point is that in the first interpretation (which is the one at least >> >implicitly prescribed by the standard) the layout that was possibly intended >> >by the user ("something starting at displacement soandso" - irrespective of >> >whether there is actual data at displacement soandso) can be quite >> >arbitrarily collapsed. In an application where datatypes are generated >> >automatically, it might be a high burden on the user to take care of >> >the special cases arising by some blocklenghts just happening to >> >be zero (either he would have to resize, or to put in explcit >> >MPI_LB/MPI_UB markers). >> > >> >A point could therefore be made for treating blocks of length >> >zero still as "markers" in the specification of a layout - as did for >> >instance the original MPICH implementation. Some changes in the text >> >would be necessary to put this interpretation on a firm foundation. >> >That is not the intention here, but only to see if there are opinions >> >on this issue? A suggestion would be to add a short paragraph stating >> >that zero blocklengths are allowed, and what their effects and side-effects >> >are. >> > >> >Jesper >> > >> > >> >Minor clarifications: >> > >> >p.63, l.39, p.66, l.12, and p.67, l.25 have "nonnegative integer" >> >blocklengths, but p. 68, l.22 only has "integer". >> >To be consistent P. 68, l.22 should also be "nonnegative integer" >> >(negative blocklenghts don't make sense) >> > >> >(as already pointed out by Steven Huss-Lederman) The specification >> >p.66, l.46ff and similarly for MPI_Type_hindexed and MPI_Type_struct >> >makes little sense (well, is plain wrong) when some B[i] is actually zero. >> >First, l.46 forces some elements into the type map [ (type_0,disp_0+D[0]) ,,,] >> >that shouldn't be there (blocks of length zero shouln't give rise to any >> >elements in the type map), and also l.48 has no real meaning >> >when B[0]. Better would be to add two lines after l.48 giving the general >> >case: >> > >> >(type_0,disp_0+D[i]*ex),...,(type_{n-1},disp_{n-1}+D[i]*ex),..., >> >(type_0,disp_0+(D[i]+B[i]-1)*ex,...,(type_{n-1},disp_{n-1}+(D[i]+B[i]-1)*ex, >> > >> >with the proviso that this is empty if B[i]==0 (or even more formally >> >precise/correct) >> > >> >> >> >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] >> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 >> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 >> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner >> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] 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-21] MPI_GET_PROCESSOR_NAME Fortran and C
by unknown＠example.com 29 Jan '08

29 Jan '08

Agreed - the migration and checkpoint/restart issues are already clear in MPI 1.1 Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-21-bounces_at_[hidden] wrote on 01/28/2008 03:24:32 AM: > Dick, > > your right and it is already decided: > MPI 1.1 Sect. 7.1 page 193, lines 13-14: > "This routine returns the name of the processor on which it > was called at the moment of the call." > And lines 22-25: > "Rationale. This function allows MPI implementations that do > process migration to return the current processor. Note that > nothing in MPI requires or defines process migration; this > definition of MPI GET PROCESSOR NAME simply allows such > an implementation. (End of rationale.)" > > I.e., current location, i.e., it may change in case of > check point/restart and all the other reasons you mentioned. > > I would say, that the sentences above are clear enough. > > Okay? > > Best regards > Rolf > > > On Fri, 25 Jan 2008 15:32:07 -0500 > Richard Treumann <treumann_at_[hidden]> wrote: > >We also should decide whether every call to MPI_GET_PROCESSOR_NAME across > >the life of the task must return the same name. On very large machines > >running very large jobs, migration of some tasks off of failing nodes and > >on to robust nodes will become more interesting. Checkpoint/restart raises > >the same issue. A restarted job will probably not have the same task to > >node mapping. > > > >We can either require the name to remain constant and allow that it might > >be a "virtual" name or require that it return an "actual" name but allow it > >to change. > > > > Dick > > > >Dick Treumann - MPI Team/TCEM > >IBM Systems & Technology Group > >Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > >Tele (845) 433-7846 Fax (845) 433-8363 > > > > > >mpi-21-bounces_at_[hidden] wrote on 01/25/2008 12:00:42 PM: > > > >> This is a discussion-point for MPI 2.1, Ballot 4. > >> > >> This is a follow up to: > >> MPI_GET_PROCESSOR_NAME and Fortran > >> in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > >> errata/index.html > >> with mail discussion in > >> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > >> errata/discuss/procname/ > >> > >> _________________________________________________________________ > >> > >> MPI_GET_PROCESSOR_NAME and Fortran > >> and in C and all MPI_xxxx_GET_NAME routines > >> ------------------------------------------- > >> > >> Summary: Returning strings is defined in MPI_GET_PROCESSOR_NAME > >> and MPI_xxxx_GET_NAME quite different. Not all implementations > >> are doing the same with zero-filling. And what they do is > >> at least with MPI_GET_PROCESSOR_NAME different to what > >> the current standard requires. A propose to adapt the standard > >> to the common reasonable implementations. > >> The very short proposal for clarification can be found at the > >> end of this text, see C. Proposal. > >> > >> A. MPI_GET_PROCESSOR_NAME > ... > >> B. MPI_COMM_GET_NAME (and other MPI_xxxx_GET_NAME) > ... > >> C. Proposal: > >> ------------ > >> > >> Add the following sentences to the current interface definitions: > >> ------------------ > >> In C, a \0 is additionally stored at name[resultlen]. resultlen > >> cannot be larger then MPI_MAX_PROCESSOR_NAME-1 > >> (or MPI_MAX_OBJECT_NAME-1). In Fortran, name(resultlen+1:) > >> is filled with spaces. resultlen cannot be larger then > >> MPI_MAX_PROCESSOR_NAME (or MPI_MAX_OBJECT_NAME). > >> ------------------ > >> > >> Typo correction: > >> ---------------- > >> MPI-1.1 Sect. 7.1, page 193, beginning of line 29 reads > >> examine the ouput argument > >> But should read (additional t in output) > >> examine the output argument > >> > >> > >> Okay? > >> _________________________________________________________________ > >> > >> Best regards > >> Rolf > >> > >> PS: Attached my tests and short protocols > >> > >> > >> > >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > >> 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) > >> [attachment "mpi_get_xxx_name.tar.gz" deleted by Richard > >> Treumann/Poughkeepsie/IBM] > >_______________________________________________ > >> mpi-21 mailing list > >> mpi-21_at_[hidden] > >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > 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-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 *

1 0

Re: [mpi-21] MPI_FINALIZE
by unknown＠example.com 29 Jan '08

29 Jan '08

I do not see a need for clarification. As long as somewhere in the standard the following points are clear enough: 1) Only MPI_BARRIER promises barrier behavior 2) Any collective may be implemented with barrier behavior as a side effect (performance issues make some collectives (eg. MPI_Bcast) unlikely to be barrier like. An MPI_Allreduce will always be barrier like. Either way though, the standard does not stipulate) Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-21-bounces_at_[hidden] wrote on 01/28/2008 12:52:54 PM: > Mainly to Jeff Squyres, Hubert Ritzdorf, Rolf Rabenseifner, Nicholas Nevin, > Bill Gropp, Dick Treumann > > This is a follow up to: > MPI_FINALIZE in MPI-2 (with spawn) > in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > errata/index.html > with mail discussion in > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > errata/discuss/finalize/ > _________________________________________ > > When I understand correctly, then a clarification is not needed > because the MPI standard expresses all, i.e. > - MPI_Finalize need not to behave like a barrier > - but is allowed to have a barrier inside. > - If the user wants to exit one spawned process while > the others still continue to work, he/she must > disconnect this process before calling MPI_Finalize on it. > > If somebody wants a clarification to be included into the standard > and therefore in Ballot 4, please send me your wording > with the page and line references included. > > If all agree, that no clarification is needed, then I would finish > this track. > > Best regards > Rolf > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > 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-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 *

1 0

Re: [mpi-21] MPI_FINALIZE
by unknown＠example.com 29 Jan '08

29 Jan '08

I agree; there is no need for clarification (I already withdrew this errata request: http://lists.cs.uiuc.edu/mailman/private/mpi-21/2008-January/000011.html) . On Jan 28, 2008, at 12:52 PM, Rolf Rabenseifner wrote: > Mainly to Jeff Squyres, Hubert Ritzdorf, Rolf Rabenseifner, Nicholas > Nevin, > Bill Gropp, Dick Treumann > > This is a follow up to: > MPI_FINALIZE in MPI-2 (with spawn) > in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.… > with mail discussion in > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… > _________________________________________ > > When I understand correctly, then a clarification is not needed > because the MPI standard expresses all, i.e. > - MPI_Finalize need not to behave like a barrier > - but is allowed to have a barrier inside. > - If the user wants to exit one spawned process while > the others still continue to work, he/she must > disconnect this process before calling MPI_Finalize on it. > > If somebody wants a clarification to be included into the standard > and therefore in Ballot 4, please send me your wording > with the page and line references included. > > If all agree, that no clarification is needed, then I would finish > this track. > > Best regards > Rolf > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > 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-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 -- Jeff Squyres Cisco Systems

1 0