May 2014 - mpiwg-tools - mailman3.cels.anl.gov

Re: [mpiwg-tools] [Mpi-forum] Ticket #383: MPI_T Errata
by Kathryn Mohror 29 May '14

29 May '14

Hi Jeff, I uploaded the document to the ticket. Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA On 5/29/14, 10:00 AM, "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> wrote: >Kathryn -- > >Can you please update the PDF on the ticket with the final final final >version of the PDF for 383? > >Thanks. > > >On May 19, 2014, at 2:05 PM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: > >> Hi all, >> >> The tools group will present ticket #383 as an errata ticket at the June >> meeting. The changes are in the attached PDF. >> >> Kathryn >> >> >> _________________________________________________________________ >> Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ >> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, >>CA, >> USA >> >> >> >> >> <tools-3.pdf>_______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > >-- >Jeff Squyres >jsquyres(a)cisco.com >For corporate legal information go to: >http://www.cisco.com/web/about/doing_business/legal/cri/ > >_______________________________________________ >mpiwg-tools mailing list >mpiwg-tools(a)lists.mpi-forum.org >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0

Re: [mpiwg-tools] [Mpi-forum] Ticket #383: MPI_T Errata
by Jeff Squyres (jsquyres) 29 May '14

29 May '14

Kathryn -- Can you please update the PDF on the ticket with the final final final version of the PDF for 383? Thanks. On May 19, 2014, at 2:05 PM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: > Hi all, > > The tools group will present ticket #383 as an errata ticket at the June > meeting. The changes are in the attached PDF. > > Kathryn > > > _________________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ > Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, > USA > > > > > <tools-3.pdf>_______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Skip Meeting May 29
by Kathryn Mohror 22 May '14

22 May '14

Hi all, Given that the MPI Forum is the week of June 2, let¹s skip the May 29 telecon. However, if anyone objects because they want to talk about something, let me know and we can have a call. Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

Re: [mpiwg-tools] [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled
by Martin Schulz 21 May '14

21 May '14

I fully agree - we won’t have all people at the meeting, but I have already added the ticket to the tools WG slot and we’ll come up with at least a draft that we can discuss via email after the meeting. The earlier we get this done, the better. Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ CASC @ Lawrence Livermore National Laboratory, Livermore, USA On 5/21/14, 12:11 AM, "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> wrote: >Yes, to take the time is a good idea, but best would be to >take the time now and having the final text latest at the end >of this meeting. To make a 3 month pause would not help. > >And for me, the result goes in this direction: >> >Allow for all these special cases that they are non-interceptable, >> >and require that the PMPI version is still available, >> >and to mention "macro in C" only as an "e.g.", >> >and the list includes the existing list plus MPI_SIZEOF >> >plus status conversion routines. >> >Due to the problems in the existing wording, and with MPI_SIZEOF, >> >I would propose it as an erratum, that is needed for MPI-3.1. > >Best regards >Rolf > >----- Original Message ----- >> From: "Martin Schulz" <schulzm(a)llnl.gov> >> To: mpiwg-tools(a)lists.mpi-forum.org >> Cc: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org> >> Sent: Tuesday, May 20, 2014 1:40:26 AM >> Subject: Re: [mpiwg-tools] [MPIWG Fortran] Proposal: MPI_SIZEOF not >>profiled >> >> Hi Rolf, >> >> I agree and (I think) so does Jeff - I think Jeff’s point was only >> that we >> should take the time and get the wording right. We can still bring >> this up >> as an errata item in Japan and it will get into MPI 3.1. >> >> Sound OK? >> >> Martin >> >> ________________________________________________________________________ >> Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ >> CASC @ Lawrence Livermore National Laboratory, Livermore, USA >> >> >> >> >> >> >> >> >> On 5/19/14, 1:49 PM, "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> >> wrote: >> >> >I'll be not at the June Meeting in Chicago. My apologies. >> > >> >For me, the solution is now nearly clear: >> >Allow for all these special cases that they are non-interceptable, >> >and require that the PMPI Version is still available, >> >and to mention "macro in C" only as an "e.g.", >> >and the list includes the existing list plus MPI_SIZEOF >> >plus status conversion routines. >> >Du to the problems in the existing wording, and with MPI_SIZEOF, >> >I would propose it as an erratum, that is needed for MPI-3.1. >> > >> >Best regards >> >Rolf >> > >> >----- Original Message ----- >> >> From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> >> >> To: "MPI-WG Fortran working group" >> >> <mpiwg-fortran(a)lists.mpi-forum.org> >> >> Cc: mpiwg-tools(a)lists.mpi-forum.org >> >> Sent: Monday, May 19, 2014 8:19:58 PM >> >> Subject: Re: [mpiwg-tools] [MPIWG Fortran] Proposal: MPI_SIZEOF >> >> not >> >>profiled >> >> >> >> Ok. Will any other Fortran people be there? (besides me) >> >> >> >> >> >> On May 19, 2014, at 2:03 PM, Martin Schulz <schulzm(a)llnl.gov> >> >> wrote: >> >> >> >> > Yes, sounds like it - I¹ll take 428 off the list then. We should >> >> > take some >> >> > time on Monday afternoon as part of the tools WG time to talk >> >> > about >> >> > this. >> >> > >> >> > Martin >> >> > >> >> > >> >>>>_______________________________________________________________________ >>>>_ >> >> > Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ >> >> > CASC @ Lawrence Livermore National Laboratory, Livermore, USA >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > On 5/19/14, 8:35 AM, "Jeff Squyres (jsquyres)" >> >> > <jsquyres(a)cisco.com> >> >> > wrote: >> >> > >> >> >> I think we need to push this errata out to the Japan meeting. >> >> >> There >> >> >> seems to be a bunch of subtlety here; trying to rush this >> >> >> through >> >> >> today >> >> >> does not seem like a good idea just to meet the T-2 week >> >> >> deadline >> >> >> for the >> >> >> Chicago meeting (which technically expires at 2pm US Central >> >> >> time >> >> >> today >> >> >> -- which is about 3.5 hours from now). >> >> >> >> >> >> Let me try to summarize the salient points so far: >> >> >> >> >> >> 1. The old text kinda sucks: >> >> >> a. it says "macros" (including the section title) where it >> >> >> really >> >> >> means "not interceptable" >> >> >> b. p19 implies that these function can only be macros in C >> >> >> (not >> >> >> inlined, and not in Fortran), which seems to contradict p555 >> >> >> >> >> >> 2. We need to add the Status conversion functions in there >> >> >> >> >> >> 3. We want to add MPI_SIZEOF (which is Fortran-only, BTW) to >> >> >> the >> >> >> list >> >> >> >> >> >> 4. The use of the word "inline" seems to be a bad idea because >> >> >> it >> >> >> can >> >> >> have many different meanings. We should say that these >> >> >> functions >> >> >> are not >> >> >> interceptable, which is the real requirement. >> >> >> >> >> >> 5. I think it would be better to change p555 to not say >> >> >> "macros" >> >> >> (i.e., >> >> >> "non-interceptable"), but rather to say "the routines listed in >> >> >> 2.6.4" >> >> >> (i.e., who cares what the reason is -- just cite 2.6.4 and let >> >> >> 2.6.4 >> >> >> explain everything). >> >> >> >> >> >> Is that all? >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On May 19, 2014, at 11:08 AM, Rolf Rabenseifner >> >> >> <rabenseifner(a)hlrs.de> >> >> >> wrote: >> >> >> >> >> >>> Yes, the "allowed as macros" on MPI-3.0 p555:32 >> >> >>> would allow a different mechanism for these routines >> >> >>> that makes them non-interceptable. >> >> >>> >> >> >>> If this "non-interceptable" is done by other means >> >> >>> than macro, then p555:35 "For routines implemented >> >> >>> as macros, it is still required that the PMPI_ >> >> >>> version be supplied" would not apply! >> >> >>> >> >> >>> It is bad to use different wording for having >> >> >>> better English quality ;-( >> >> >>> >> >> >>> And your are right, my "#ifdef MPI_Wait" says >> >> >>> therefore nothing. >> >> >>> >> >> >>> Do you all agree that wording in >> >> >>> p19:48 - p20:5 and p555:31-37 is at all inconsistent >> >> >>> and therefore new and useful wording is needed >> >> >>> in this erratum? >> >> >>> >> >> >>> Rolf >> >> >>> >> >> >>> ----- Original Message ----- >> >> >>>> From: "N.M. Maclaren" <nmm1(a)cam.ac.uk> >> >> >>>> To: "MPI-WG Fortran working group" >> >> >>>> <mpiwg-fortran(a)lists.mpi-forum.org> >> >> >>>> Sent: Monday, May 19, 2014 4:35:10 PM >> >> >>>> Subject: Re: [MPIWG Fortran] [mpiwg-tools] Proposal: >> >> >>>> MPI_SIZEOF >> >> >>>> not >> >> >>>> profiled >> >> >>>> >> >> >>>> On May 19 2014, Rolf Rabenseifner wrote: >> >> >>>>> >> >> >>>>> Bill, >> >> >>>>> >> >> >>>>> your text goes beyond the errata goal. >> >> >>>>> >> >> >>>>> The errata goal was: >> >> >>>>> - adding the missing Status conversion >> >> >>>>> - adding MPI_SIZEOF >> >> >>>>> >> >> >>>>> And this works as errata. >> >> >>>>> >> >> >>>>> Your goal is to allow also >> >> >>>>> - Fortran non-interceptable for these routines. >> >> >>>>> >> >> >>>>> Your additional Change is to allow other methods >> >> >>>>> than C macros for C. >> >> >>>>> This would prevent "#ifdef MPI_Wtime". >> >> >>>>> >> >> >>>>> All this would be MPI-4.0 and not MPI-3.0 errata. >> >> >>>> >> >> >>>> Would it? I don't know what useful effect you would expect >> >> >>>> "#ifdef MPI_Wtime" to achieve, but it assuredly would NOT >> >> >>>> tell >> >> >>>> you (reliably) whether or not it can be accessed through the >> >> >>>> profiling interface. 14.2 says: >> >> >>>> >> >> >>>> 1. provide a mechanism through which all of the MPI defined >> >> >>>> functions, except those allowed as macros (See Section >> >> >>>> 2.6.4), >> >> >>>> may be accessed with a name shift. >> >> >>>> >> >> >>>> Because it says "ALLOWED as macros", MPI_Wtime may not be >> >> >>>> accessed >> >> >>>> through the profiling interface, whether or not it is >> >> >>>> implemented >> >> >>>> as a macro. Doing so is a user error, leading to undefined >> >> >>>> behaviour. >> >> >>>> Therefore, an implementation may implement them as C inline >> >> >>>> functions, >> >> >>>> and would meet all of the requirements of MPI. >> >> >>>> >> >> >>>> The error is more pervasive than just for Fortran. Because >> >> >>>> it >> >> >>>> did >> >> >>>> not say what it meant, but something that was equivalent >> >> >>>> under >> >> >>>> K&R C >> >> >>>> (sic), it wasn't strictly true in C90 and was rendered >> >> >>>> significantly >> >> >>>> misleading (arguably erroneous) by C99. And that's the >> >> >>>> reason >> >> >>>> that >> >> >>>> some people get very unhappy about the proposed partial fix. >> >> >>>> >> >> >>>> It's also why the best solution is to regard ALL of the >> >> >>>> wording >> >> >>>> as >> >> >>>> an error - which would probably mean starting a new ticket. >> >> >>>> But >> >> >>>> it's >> >> >>>> definitely an error in the wording, not a change. >> >> >>>> >> >> >>>> >> >> >>>> Regards, >> >> >>>> Nick Maclaren. >> >> >>>> >> >> >>>> _______________________________________________ >> >> >>>> mpiwg-fortran mailing list >> >> >>>> mpiwg-fortran(a)lists.mpi-forum.org >> >> >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >> >> >>>> >> >> >>> >> >> >>> -- >> >> >>> 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: Room >> >> >>> 1.307) >> >> >>> _______________________________________________ >> >> >>> mpiwg-fortran mailing list >> >> >>> mpiwg-fortran(a)lists.mpi-forum.org >> >> >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >> >> >> >> >> >> >> >> >> -- >> >> >> Jeff Squyres >> >> >> jsquyres(a)cisco.com >> >> >> For corporate legal information go to: >> >> >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> >> >> >> >> _______________________________________________ >> >> >> mpiwg-tools mailing list >> >> >> mpiwg-tools(a)lists.mpi-forum.org >> >> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >> >> > >> >> > >> >> > _______________________________________________ >> >> > mpiwg-fortran mailing list >> >> > mpiwg-fortran(a)lists.mpi-forum.org >> >> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >> >> >> >> >> >> -- >> >> Jeff Squyres >> >> jsquyres(a)cisco.com >> >> For corporate legal information go to: >> >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> >> >> _______________________________________________ >> >> mpiwg-tools mailing list >> >> mpiwg-tools(a)lists.mpi-forum.org >> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >> >> >> > >> >-- >> >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: Room >> >1.307) >> >_______________________________________________ >> >mpiwg-tools mailing list >> >mpiwg-tools(a)lists.mpi-forum.org >> >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >> >> >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > >-- >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: Room 1.307) >_______________________________________________ >mpiwg-tools mailing list >mpiwg-tools(a)lists.mpi-forum.org >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0

Re: [mpiwg-tools] [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled
by Rolf Rabenseifner 21 May '14

21 May '14

Yes, to take the time is a good idea, but best would be to take the time now and having the final text latest at the end of this meeting. To make a 3 month pause would not help. And for me, the result goes in this direction: > >Allow for all these special cases that they are non-interceptable, > >and require that the PMPI version is still available, > >and to mention "macro in C" only as an "e.g.", > >and the list includes the existing list plus MPI_SIZEOF > >plus status conversion routines. > >Due to the problems in the existing wording, and with MPI_SIZEOF, > >I would propose it as an erratum, that is needed for MPI-3.1. Best regards Rolf ----- Original Message ----- > From: "Martin Schulz" <schulzm(a)llnl.gov> > To: mpiwg-tools(a)lists.mpi-forum.org > Cc: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org> > Sent: Tuesday, May 20, 2014 1:40:26 AM > Subject: Re: [mpiwg-tools] [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled > > Hi Rolf, > > I agree and (I think) so does Jeff - I think Jeff’s point was only > that we > should take the time and get the wording right. We can still bring > this up > as an errata item in Japan and it will get into MPI 3.1. > > Sound OK? > > Martin > > ________________________________________________________________________ > Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ > CASC @ Lawrence Livermore National Laboratory, Livermore, USA > > > > > > > > > On 5/19/14, 1:49 PM, "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > wrote: > > >I'll be not at the June Meeting in Chicago. My apologies. > > > >For me, the solution is now nearly clear: > >Allow for all these special cases that they are non-interceptable, > >and require that the PMPI Version is still available, > >and to mention "macro in C" only as an "e.g.", > >and the list includes the existing list plus MPI_SIZEOF > >plus status conversion routines. > >Du to the problems in the existing wording, and with MPI_SIZEOF, > >I would propose it as an erratum, that is needed for MPI-3.1. > > > >Best regards > >Rolf > > > >----- Original Message ----- > >> From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> > >> To: "MPI-WG Fortran working group" > >> <mpiwg-fortran(a)lists.mpi-forum.org> > >> Cc: mpiwg-tools(a)lists.mpi-forum.org > >> Sent: Monday, May 19, 2014 8:19:58 PM > >> Subject: Re: [mpiwg-tools] [MPIWG Fortran] Proposal: MPI_SIZEOF > >> not > >>profiled > >> > >> Ok. Will any other Fortran people be there? (besides me) > >> > >> > >> On May 19, 2014, at 2:03 PM, Martin Schulz <schulzm(a)llnl.gov> > >> wrote: > >> > >> > Yes, sounds like it - I¹ll take 428 off the list then. We should > >> > take some > >> > time on Monday afternoon as part of the tools WG time to talk > >> > about > >> > this. > >> > > >> > Martin > >> > > >> > > >>________________________________________________________________________ > >> > Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ > >> > CASC @ Lawrence Livermore National Laboratory, Livermore, USA > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > On 5/19/14, 8:35 AM, "Jeff Squyres (jsquyres)" > >> > <jsquyres(a)cisco.com> > >> > wrote: > >> > > >> >> I think we need to push this errata out to the Japan meeting. > >> >> There > >> >> seems to be a bunch of subtlety here; trying to rush this > >> >> through > >> >> today > >> >> does not seem like a good idea just to meet the T-2 week > >> >> deadline > >> >> for the > >> >> Chicago meeting (which technically expires at 2pm US Central > >> >> time > >> >> today > >> >> -- which is about 3.5 hours from now). > >> >> > >> >> Let me try to summarize the salient points so far: > >> >> > >> >> 1. The old text kinda sucks: > >> >> a. it says "macros" (including the section title) where it > >> >> really > >> >> means "not interceptable" > >> >> b. p19 implies that these function can only be macros in C > >> >> (not > >> >> inlined, and not in Fortran), which seems to contradict p555 > >> >> > >> >> 2. We need to add the Status conversion functions in there > >> >> > >> >> 3. We want to add MPI_SIZEOF (which is Fortran-only, BTW) to > >> >> the > >> >> list > >> >> > >> >> 4. The use of the word "inline" seems to be a bad idea because > >> >> it > >> >> can > >> >> have many different meanings. We should say that these > >> >> functions > >> >> are not > >> >> interceptable, which is the real requirement. > >> >> > >> >> 5. I think it would be better to change p555 to not say > >> >> "macros" > >> >> (i.e., > >> >> "non-interceptable"), but rather to say "the routines listed in > >> >> 2.6.4" > >> >> (i.e., who cares what the reason is -- just cite 2.6.4 and let > >> >> 2.6.4 > >> >> explain everything). > >> >> > >> >> Is that all? > >> >> > >> >> > >> >> > >> >> > >> >> On May 19, 2014, at 11:08 AM, Rolf Rabenseifner > >> >> <rabenseifner(a)hlrs.de> > >> >> wrote: > >> >> > >> >>> Yes, the "allowed as macros" on MPI-3.0 p555:32 > >> >>> would allow a different mechanism for these routines > >> >>> that makes them non-interceptable. > >> >>> > >> >>> If this "non-interceptable" is done by other means > >> >>> than macro, then p555:35 "For routines implemented > >> >>> as macros, it is still required that the PMPI_ > >> >>> version be supplied" would not apply! > >> >>> > >> >>> It is bad to use different wording for having > >> >>> better English quality ;-( > >> >>> > >> >>> And your are right, my "#ifdef MPI_Wait" says > >> >>> therefore nothing. > >> >>> > >> >>> Do you all agree that wording in > >> >>> p19:48 - p20:5 and p555:31-37 is at all inconsistent > >> >>> and therefore new and useful wording is needed > >> >>> in this erratum? > >> >>> > >> >>> Rolf > >> >>> > >> >>> ----- Original Message ----- > >> >>>> From: "N.M. Maclaren" <nmm1(a)cam.ac.uk> > >> >>>> To: "MPI-WG Fortran working group" > >> >>>> <mpiwg-fortran(a)lists.mpi-forum.org> > >> >>>> Sent: Monday, May 19, 2014 4:35:10 PM > >> >>>> Subject: Re: [MPIWG Fortran] [mpiwg-tools] Proposal: > >> >>>> MPI_SIZEOF > >> >>>> not > >> >>>> profiled > >> >>>> > >> >>>> On May 19 2014, Rolf Rabenseifner wrote: > >> >>>>> > >> >>>>> Bill, > >> >>>>> > >> >>>>> your text goes beyond the errata goal. > >> >>>>> > >> >>>>> The errata goal was: > >> >>>>> - adding the missing Status conversion > >> >>>>> - adding MPI_SIZEOF > >> >>>>> > >> >>>>> And this works as errata. > >> >>>>> > >> >>>>> Your goal is to allow also > >> >>>>> - Fortran non-interceptable for these routines. > >> >>>>> > >> >>>>> Your additional Change is to allow other methods > >> >>>>> than C macros for C. > >> >>>>> This would prevent "#ifdef MPI_Wtime". > >> >>>>> > >> >>>>> All this would be MPI-4.0 and not MPI-3.0 errata. > >> >>>> > >> >>>> Would it? I don't know what useful effect you would expect > >> >>>> "#ifdef MPI_Wtime" to achieve, but it assuredly would NOT > >> >>>> tell > >> >>>> you (reliably) whether or not it can be accessed through the > >> >>>> profiling interface. 14.2 says: > >> >>>> > >> >>>> 1. provide a mechanism through which all of the MPI defined > >> >>>> functions, except those allowed as macros (See Section > >> >>>> 2.6.4), > >> >>>> may be accessed with a name shift. > >> >>>> > >> >>>> Because it says "ALLOWED as macros", MPI_Wtime may not be > >> >>>> accessed > >> >>>> through the profiling interface, whether or not it is > >> >>>> implemented > >> >>>> as a macro. Doing so is a user error, leading to undefined > >> >>>> behaviour. > >> >>>> Therefore, an implementation may implement them as C inline > >> >>>> functions, > >> >>>> and would meet all of the requirements of MPI. > >> >>>> > >> >>>> The error is more pervasive than just for Fortran. Because > >> >>>> it > >> >>>> did > >> >>>> not say what it meant, but something that was equivalent > >> >>>> under > >> >>>> K&R C > >> >>>> (sic), it wasn't strictly true in C90 and was rendered > >> >>>> significantly > >> >>>> misleading (arguably erroneous) by C99. And that's the > >> >>>> reason > >> >>>> that > >> >>>> some people get very unhappy about the proposed partial fix. > >> >>>> > >> >>>> It's also why the best solution is to regard ALL of the > >> >>>> wording > >> >>>> as > >> >>>> an error - which would probably mean starting a new ticket. > >> >>>> But > >> >>>> it's > >> >>>> definitely an error in the wording, not a change. > >> >>>> > >> >>>> > >> >>>> Regards, > >> >>>> Nick Maclaren. > >> >>>> > >> >>>> _______________________________________________ > >> >>>> mpiwg-fortran mailing list > >> >>>> mpiwg-fortran(a)lists.mpi-forum.org > >> >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > >> >>>> > >> >>> > >> >>> -- > >> >>> 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: Room > >> >>> 1.307) > >> >>> _______________________________________________ > >> >>> mpiwg-fortran mailing list > >> >>> mpiwg-fortran(a)lists.mpi-forum.org > >> >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > >> >> > >> >> > >> >> -- > >> >> Jeff Squyres > >> >> jsquyres(a)cisco.com > >> >> For corporate legal information go to: > >> >> http://www.cisco.com/web/about/doing_business/legal/cri/ > >> >> > >> >> _______________________________________________ > >> >> mpiwg-tools mailing list > >> >> mpiwg-tools(a)lists.mpi-forum.org > >> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > >> > > >> > > >> > _______________________________________________ > >> > mpiwg-fortran mailing list > >> > mpiwg-fortran(a)lists.mpi-forum.org > >> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > >> > >> > >> -- > >> Jeff Squyres > >> jsquyres(a)cisco.com > >> For corporate legal information go to: > >> http://www.cisco.com/web/about/doing_business/legal/cri/ > >> > >> _______________________________________________ > >> mpiwg-tools mailing list > >> mpiwg-tools(a)lists.mpi-forum.org > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > >> > > > >-- > >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: Room > >1.307) > >_______________________________________________ > >mpiwg-tools mailing list > >mpiwg-tools(a)lists.mpi-forum.org > >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools -- 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: Room 1.307)

1 0

Re: [mpiwg-tools] #405 and #406 scheduled for 1st vote although passed???
by Martin Schulz 19 May '14

19 May '14

Sorry about that and thanks for catching it - must have been a copy/paste error from last time. Fixed, Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ CASC @ Lawrence Livermore National Laboratory, Livermore, USA On 5/19/14, 2:26 PM, "Kathryn Mohror" <kathryn(a)llnl.gov> wrote: >Hi Martin, > >Yes, #405 and #406 were errata tickets that were read and passed at the >last meeting. > >Kathryn >_________________________________________________________________ >Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ >Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, >USA > > > > > > >On 5/19/14, 11:17 AM, "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> wrote: > >>I do not understand why #405 and #406 are scheduled for 1st vote >>although they have priority passed? >> >>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: Room 1.307) >>_______________________________________________ >>mpiwg-tools mailing list >>mpiwg-tools(a)lists.mpi-forum.org >>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > >

1 0

Re: [mpiwg-tools] [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled
by Martin Schulz 19 May '14

19 May '14

Hi Rolf, I agree and (I think) so does Jeff - I think Jeff’s point was only that we should take the time and get the wording right. We can still bring this up as an errata item in Japan and it will get into MPI 3.1. Sound OK? Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ CASC @ Lawrence Livermore National Laboratory, Livermore, USA On 5/19/14, 1:49 PM, "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> wrote: >I'll be not at the June Meeting in Chicago. My apologies. > >For me, the solution is now nearly clear: >Allow for all these special cases that they are non-interceptable, >and require that the PMPI Version is still available, >and to mention "macro in C" only as an "e.g.", >and the list includes the existing list plus MPI_SIZEOF >plus status conversion routines. >Du to the problems in the existing wording, and with MPI_SIZEOF, >I would propose it as an erratum, that is needed for MPI-3.1. > >Best regards >Rolf > >----- Original Message ----- >> From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> >> To: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org> >> Cc: mpiwg-tools(a)lists.mpi-forum.org >> Sent: Monday, May 19, 2014 8:19:58 PM >> Subject: Re: [mpiwg-tools] [MPIWG Fortran] Proposal: MPI_SIZEOF not >>profiled >> >> Ok. Will any other Fortran people be there? (besides me) >> >> >> On May 19, 2014, at 2:03 PM, Martin Schulz <schulzm(a)llnl.gov> wrote: >> >> > Yes, sounds like it - I¹ll take 428 off the list then. We should >> > take some >> > time on Monday afternoon as part of the tools WG time to talk about >> > this. >> > >> > Martin >> > >> > >>________________________________________________________________________ >> > Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ >> > CASC @ Lawrence Livermore National Laboratory, Livermore, USA >> > >> > >> > >> > >> > >> > >> > >> > >> > On 5/19/14, 8:35 AM, "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> >> > wrote: >> > >> >> I think we need to push this errata out to the Japan meeting. >> >> There >> >> seems to be a bunch of subtlety here; trying to rush this through >> >> today >> >> does not seem like a good idea just to meet the T-2 week deadline >> >> for the >> >> Chicago meeting (which technically expires at 2pm US Central time >> >> today >> >> -- which is about 3.5 hours from now). >> >> >> >> Let me try to summarize the salient points so far: >> >> >> >> 1. The old text kinda sucks: >> >> a. it says "macros" (including the section title) where it really >> >> means "not interceptable" >> >> b. p19 implies that these function can only be macros in C (not >> >> inlined, and not in Fortran), which seems to contradict p555 >> >> >> >> 2. We need to add the Status conversion functions in there >> >> >> >> 3. We want to add MPI_SIZEOF (which is Fortran-only, BTW) to the >> >> list >> >> >> >> 4. The use of the word "inline" seems to be a bad idea because it >> >> can >> >> have many different meanings. We should say that these functions >> >> are not >> >> interceptable, which is the real requirement. >> >> >> >> 5. I think it would be better to change p555 to not say "macros" >> >> (i.e., >> >> "non-interceptable"), but rather to say "the routines listed in >> >> 2.6.4" >> >> (i.e., who cares what the reason is -- just cite 2.6.4 and let >> >> 2.6.4 >> >> explain everything). >> >> >> >> Is that all? >> >> >> >> >> >> >> >> >> >> On May 19, 2014, at 11:08 AM, Rolf Rabenseifner >> >> <rabenseifner(a)hlrs.de> >> >> wrote: >> >> >> >>> Yes, the "allowed as macros" on MPI-3.0 p555:32 >> >>> would allow a different mechanism for these routines >> >>> that makes them non-interceptable. >> >>> >> >>> If this "non-interceptable" is done by other means >> >>> than macro, then p555:35 "For routines implemented >> >>> as macros, it is still required that the PMPI_ >> >>> version be supplied" would not apply! >> >>> >> >>> It is bad to use different wording for having >> >>> better English quality ;-( >> >>> >> >>> And your are right, my "#ifdef MPI_Wait" says >> >>> therefore nothing. >> >>> >> >>> Do you all agree that wording in >> >>> p19:48 - p20:5 and p555:31-37 is at all inconsistent >> >>> and therefore new and useful wording is needed >> >>> in this erratum? >> >>> >> >>> Rolf >> >>> >> >>> ----- Original Message ----- >> >>>> From: "N.M. Maclaren" <nmm1(a)cam.ac.uk> >> >>>> To: "MPI-WG Fortran working group" >> >>>> <mpiwg-fortran(a)lists.mpi-forum.org> >> >>>> Sent: Monday, May 19, 2014 4:35:10 PM >> >>>> Subject: Re: [MPIWG Fortran] [mpiwg-tools] Proposal: MPI_SIZEOF >> >>>> not >> >>>> profiled >> >>>> >> >>>> On May 19 2014, Rolf Rabenseifner wrote: >> >>>>> >> >>>>> Bill, >> >>>>> >> >>>>> your text goes beyond the errata goal. >> >>>>> >> >>>>> The errata goal was: >> >>>>> - adding the missing Status conversion >> >>>>> - adding MPI_SIZEOF >> >>>>> >> >>>>> And this works as errata. >> >>>>> >> >>>>> Your goal is to allow also >> >>>>> - Fortran non-interceptable for these routines. >> >>>>> >> >>>>> Your additional Change is to allow other methods >> >>>>> than C macros for C. >> >>>>> This would prevent "#ifdef MPI_Wtime". >> >>>>> >> >>>>> All this would be MPI-4.0 and not MPI-3.0 errata. >> >>>> >> >>>> Would it? I don't know what useful effect you would expect >> >>>> "#ifdef MPI_Wtime" to achieve, but it assuredly would NOT tell >> >>>> you (reliably) whether or not it can be accessed through the >> >>>> profiling interface. 14.2 says: >> >>>> >> >>>> 1. provide a mechanism through which all of the MPI defined >> >>>> functions, except those allowed as macros (See Section 2.6.4), >> >>>> may be accessed with a name shift. >> >>>> >> >>>> Because it says "ALLOWED as macros", MPI_Wtime may not be >> >>>> accessed >> >>>> through the profiling interface, whether or not it is >> >>>> implemented >> >>>> as a macro. Doing so is a user error, leading to undefined >> >>>> behaviour. >> >>>> Therefore, an implementation may implement them as C inline >> >>>> functions, >> >>>> and would meet all of the requirements of MPI. >> >>>> >> >>>> The error is more pervasive than just for Fortran. Because it >> >>>> did >> >>>> not say what it meant, but something that was equivalent under >> >>>> K&R C >> >>>> (sic), it wasn't strictly true in C90 and was rendered >> >>>> significantly >> >>>> misleading (arguably erroneous) by C99. And that's the reason >> >>>> that >> >>>> some people get very unhappy about the proposed partial fix. >> >>>> >> >>>> It's also why the best solution is to regard ALL of the wording >> >>>> as >> >>>> an error - which would probably mean starting a new ticket. But >> >>>> it's >> >>>> definitely an error in the wording, not a change. >> >>>> >> >>>> >> >>>> Regards, >> >>>> Nick Maclaren. >> >>>> >> >>>> _______________________________________________ >> >>>> mpiwg-fortran mailing list >> >>>> mpiwg-fortran(a)lists.mpi-forum.org >> >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >> >>>> >> >>> >> >>> -- >> >>> 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: Room >> >>> 1.307) >> >>> _______________________________________________ >> >>> mpiwg-fortran mailing list >> >>> mpiwg-fortran(a)lists.mpi-forum.org >> >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >> >> >> >> >> >> -- >> >> Jeff Squyres >> >> jsquyres(a)cisco.com >> >> For corporate legal information go to: >> >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> >> >> _______________________________________________ >> >> mpiwg-tools mailing list >> >> mpiwg-tools(a)lists.mpi-forum.org >> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >> > >> > >> > _______________________________________________ >> > mpiwg-fortran mailing list >> > mpiwg-fortran(a)lists.mpi-forum.org >> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >> >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >> > >-- >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: Room 1.307) >_______________________________________________ >mpiwg-tools mailing list >mpiwg-tools(a)lists.mpi-forum.org >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0

Re: [mpiwg-tools] Ticket #383 -- Final text?
by Jeff Squyres (jsquyres) 19 May '14

19 May '14

I think it looks good. Ship it. On May 19, 2014, at 5:30 PM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: > Okay, here’s another try. Please let me know if this is now correct. (Sorry for the delay — I am at IPDPS and the wifi is not so good) > > Kathryn > > _________________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ > Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA > > From: <Schulz>, Martin <schulz6(a)llnl.gov> > Reply-To: "mpiwg-tools(a)lists.mpi-forum.org" <mpiwg-tools(a)lists.mpi-forum.org> > Date: Monday, May 19, 2014 at 9:37 AM > To: "'mpiwg-tools(a)lists.mpi-forum.org'" <mpiwg-tools(a)lists.mpi-forum.org>, "'<mpiwg-tools(a)lists.mpi-forum.org>'" <mpiwg-tools(a)lists.mpi-forum.org> > Subject: Re: [mpiwg-tools] Ticket #383 -- Final text? > > Either option is fine with me - I can see the argument either way > > Martin > > > > Sent with Good (www.good.com) > > > -----Original Message----- > From: Jeff Squyres (jsquyres) [jsquyres(a)cisco.com] > Sent: Monday, May 19, 2014 09:25 AM Pacific Standard Time > To: > Subject: Re: [mpiwg-tools] Ticket #383 -- Final text? > > Good point. I like INOUT, but wont' fight too hard if people want to drop it. > > On May 19, 2014, at 12:08 PM, "Schulz, Martin" <schulz6(a)llnl.gov> > wrote: > > > Looks mostly good to me, but length arguments are INOUT, so that may be confusing - perhaps just drop the IN? > > > > Martin > > > > > > > > Sent with Good (www.good.com) > > > > > > -----Original Message----- > > From: Kathryn Mohror [kathryn(a)llnl.gov] > > Sent: Monday, May 19, 2014 08:31 AM Pacific Standard Time > > To: Bronis R. de Supinski; mpiwg-tools(a)lists.mpi-forum.org > > Subject: Re: [mpiwg-tools] Ticket #383 -- Final text? > > > > Jeff, > > > > Is this what you want for the text, attached? > > > > Kathryn > > _________________________________________________________________ > > Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ > > Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, > > USA > > > > > > > > > > > > > > On 5/19/14, 8:03 AM, "Bronis R. de Supinski" <bronis(a)llnl.gov> wrote: > > > > > > > >"sufficiently long enough" is redundant; "sufficiently long" > > >is sufficient. > > > > > >On Mon, 19 May 2014, Jeff Squyres (jsquyres) wrote: > > > > > >> On May 18, 2014, at 2:35 AM, Martin Schulz <schulzm(a)llnl.gov> wrote: > > >> > > >>> Hi Kathryn, all, > > >>> > > >>> A few comments: > > >>> - "Adhere to the same definition from the MPI implementation.² - not > > >>>sure > > >>> what we meant with this anymore. Perhaps we should just drop this part. > > >> > > >> What I meant by that is that each MPI implementation will create a > > >>definition for each cvar/pvar/etc. The implementation must adhere to > > >>that same definition in all connected processes. I.e., it can't change > > >>the definition of exactly what that variable is in different processes > > >>(e.g., bytes_in = bytes received from TCP in one process, but bytes > > >>received across shared memory in another process). > > >> > > >>> - "OUT index values² is not correct, since index values are IN > > >>>parameters > > >>> to the get_info calls. Perhaps just drop OUT? > > >> > > >> Good catch; missed that. Yes, this whole clause can go. > > >> > > >>> - The mandate of equal OUT/INPUT values is also not quite right - for > > >>>the > > >>> strings, it¹s OK to return substrings of the size argument is too > > >>>small. I > > >>> know that¹s a technicality, but I am not sure if this causes problems > > >>> later down the road. > > >> > > >> Mmm. Good point. So the current text is: > > >> > > >> * Return the same INOUT and OUT values from the relevant > > >>MPI_T_*_GET_INFO function. > > >> > > >> (I took the liberty of dropping the index value clause) > > >> > > >> I notice that we actually return 3 kinds of things from GET_INFO > > >>functions: integers/enums, strings, and MPI handles (i.e., > > >>MPI_Datatype). So how about this: > > >> > > >> * Return the same INOUT and OUT integer and enum values from the > > >>relevant MPI_T_*_GET_INFO function. > > >> * If sufficiently long enough string length IN parameters are supplied, > > >>return the same string OUT parameters from the relevant MPI_T_*_GET_INFO > > >>function. > > >> * Return a handle to an equivalent MPI object from the relevant > > >>MPI_T_*_GET_INFO function. > > >> > > >> > > >> > > >> -- > > >> Jeff Squyres > > >> jsquyres(a)cisco.com > > >> For corporate legal information go to: > > >>http://www.cisco.com/web/about/doing_business/legal/cri/ > > >> > > >> _______________________________________________ > > >> mpiwg-tools mailing list > > >> mpiwg-tools(a)lists.mpi-forum.org > > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > > > > > _______________________________________________ > > mpiwg-tools mailing list > > mpiwg-tools(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > <tools-3.pdf>_______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [mpiwg-tools] Ticket #383 -- Final text?
by Kathryn Mohror 19 May '14

19 May '14

Okay, here’s another try. Please let me know if this is now correct. (Sorry for the delay ― I am at IPDPS and the wifi is not so good) Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA From: <Schulz>, Martin <schulz6(a)llnl.gov> Reply-To: "mpiwg-tools(a)lists.mpi-forum.org" <mpiwg-tools(a)lists.mpi-forum.org> Date: Monday, May 19, 2014 at 9:37 AM To: "'mpiwg-tools(a)lists.mpi-forum.org'" <mpiwg-tools(a)lists.mpi-forum.org>, "'<mpiwg-tools(a)lists.mpi-forum.org>'" <mpiwg-tools(a)lists.mpi-forum.org> Subject: Re: [mpiwg-tools] Ticket #383 -- Final text? Re: [mpiwg-tools] Ticket #383 -- Final text? Either option is fine with me - I can see the argument either way Martin Sent with Good (www.good.com) -----Original Message----- From: Jeff Squyres (jsquyres) [jsquyres(a)cisco.com] Sent: Monday, May 19, 2014 09:25 AM Pacific Standard Time To: Subject: Re: [mpiwg-tools] Ticket #383 -- Final text? Good point. I like INOUT, but wont' fight too hard if people want to drop it. On May 19, 2014, at 12:08 PM, "Schulz, Martin" <schulz6(a)llnl.gov> wrote: > Looks mostly good to me, but length arguments are INOUT, so that may be confusing - perhaps just drop the IN? > > Martin > > > > Sent with Good (www.good.com) > > > -----Original Message----- > From: Kathryn Mohror [kathryn(a)llnl.gov] > Sent: Monday, May 19, 2014 08:31 AM Pacific Standard Time > To: Bronis R. de Supinski; mpiwg-tools(a)lists.mpi-forum.org > Subject: Re: [mpiwg-tools] Ticket #383 -- Final text? > > Jeff, > > Is this what you want for the text, attached? > > Kathryn > _________________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ > Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, > USA > > > > > > > On 5/19/14, 8:03 AM, "Bronis R. de Supinski" <bronis(a)llnl.gov> wrote: > > > > >"sufficiently long enough" is redundant; "sufficiently long" > >is sufficient. > > > >On Mon, 19 May 2014, Jeff Squyres (jsquyres) wrote: > > > >> On May 18, 2014, at 2:35 AM, Martin Schulz <schulzm(a)llnl.gov> wrote: > >> > >>> Hi Kathryn, all, > >>> > >>> A few comments: > >>> - "Adhere to the same definition from the MPI implementation.² - not > >>>sure > >>> what we meant with this anymore. Perhaps we should just drop this part. > >> > >> What I meant by that is that each MPI implementation will create a > >>definition for each cvar/pvar/etc. The implementation must adhere to > >>that same definition in all connected processes. I.e., it can't change > >>the definition of exactly what that variable is in different processes > >>(e.g., bytes_in = bytes received from TCP in one process, but bytes > >>received across shared memory in another process). > >> > >>> - "OUT index values² is not correct, since index values are IN > >>>parameters > >>> to the get_info calls. Perhaps just drop OUT? > >> > >> Good catch; missed that. Yes, this whole clause can go. > >> > >>> - The mandate of equal OUT/INPUT values is also not quite right - for > >>>the > >>> strings, it¹s OK to return substrings of the size argument is too > >>>small. I > >>> know that¹s a technicality, but I am not sure if this causes problems > >>> later down the road. > >> > >> Mmm. Good point. So the current text is: > >> > >> * Return the same INOUT and OUT values from the relevant > >>MPI_T_*_GET_INFO function. > >> > >> (I took the liberty of dropping the index value clause) > >> > >> I notice that we actually return 3 kinds of things from GET_INFO > >>functions: integers/enums, strings, and MPI handles (i.e., > >>MPI_Datatype). So how about this: > >> > >> * Return the same INOUT and OUT integer and enum values from the > >>relevant MPI_T_*_GET_INFO function. > >> * If sufficiently long enough string length IN parameters are supplied, > >>return the same string OUT parameters from the relevant MPI_T_*_GET_INFO > >>function. > >> * Return a handle to an equivalent MPI object from the relevant > >>MPI_T_*_GET_INFO function. > >> > >> > >> > >> -- > >> Jeff Squyres > >> jsquyres(a)cisco.com > >> For corporate legal information go to: > >>http://www.cisco.com/web/about/doing_business/legal/cri/ > >> > >> _______________________________________________ > >> mpiwg-tools mailing list > >> mpiwg-tools(a)lists.mpi-forum.org > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ _______________________________________________ mpiwg-tools mailing list mpiwg-tools(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0

Re: [mpiwg-tools] #405 and #406 scheduled for 1st vote although passed???
by Kathryn Mohror 19 May '14

19 May '14

Hi Martin, Yes, #405 and #406 were errata tickets that were read and passed at the last meeting. Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA On 5/19/14, 11:17 AM, "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> wrote: >I do not understand why #405 and #406 are scheduled for 1st vote >although they have priority passed? > >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: Room 1.307) >_______________________________________________ >mpiwg-tools mailing list >mpiwg-tools(a)lists.mpi-forum.org >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0