From gpaulsen at [hidden] Tue Feb 1 10:24:20 2011 From: gpaulsen at [hidden] (Geoffrey Paulsen) Date: Tue, 1 Feb 2011 11:24:20 -0500 Subject: [Mpi3-bwcompat] Ticket 265 ready for review In-Reply-To: Message-ID: <0B503E76919828489362F1FA50483508E55D96@catoexm07.noam.corp.platform.com> Well, I agree with Rajeev, and would like to see both this approach AND a whole new set of MPI_ functions with MPI_Aint Count (or some new 64bit integer possibly implementation specific MPI_Count datatype) argument for convenience. I would think a new major MPI revision (such as MPI 3.0) is the time to introduce sweeping new classes of APIs, otherwise it'll be another ten years or so until the next major revision of the standard. Of course providing backwards compatibility with MPI 2.2 (hopefully at the binary level of a particular implementation) is a priority as well. It would be nice if we could have both. Geoff Paulsen Platform MPI - http://www.platform.com/cluster-computing/platform-mpi -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Friday, January 28, 2011 3:33 PM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] Ticket 265 ready for review Rajeev -- The problem with your proposal is that it very, very quickly becomes a slippery slope of making a new MPI_() with an MPI_Count argument for every value of . The Forum has soundly rejected every form of that. This proposal is a (return to) just proposing absolute minimal functionality that is required for correctness. On Jan 28, 2011, at 12:07 PM, Fab Tillier wrote: > Rajeev Thakur wrote on Fri, 28 Jan 2011 at 08:09:29 > >> Yes, it is not absolutely required, but becomes a convenience feature. > > I believe Quincy will be bringing forth a proposal to address this, but we wanted to get the minimum functionality to provide full support for large datatypes captured in a single ticket without adding convenience features. > > -Fab > >> >> Rajeev >> >> On Jan 27, 2011, at 11:33 AM, Fab Tillier wrote: >> >>> Hi Rajeev, >>> >>> Rajeev Thakur wrote on Wed, 26 Jan 2011 at 21:59:33 >>> >>>> OK, thanks for the explanation. >>>> >>>> If count is encapsulated in derived datatypes, we might need new >>>> datatype constructor functions that take MPI_Count, or at least a new >>>> MPI_Type_contiguous. Let's say the user wants to send an array of size >>>> X integers, where X is some weird number greater than 2G. If there is a >>>> new Type_contiguous, we have to see how it affects Type_get_envelope >>>> and Type_get_contents. >>> >>> We shouldn't need new datatype creator functions for this to work - a user >> can nest types, for example by creating a struct type of contiguous types to >> achieve the length desired. In this case, the >> MPI_Type_get_envelope/contents would still work as currently defined. >>> >>> Does that make sense? >>> >>> Do we want to capture this discussion as comments on the ticket? >>> >>> Thanks for the feedback! >>> -Fab >>> >>>> Rajeev >>>> >>>> >>>> On Jan 26, 2011, at 4:56 PM, Fab Tillier wrote: >>>> >>>>> Hi Rajeev, >>>>> >>>>> Rajeev Thakur wrote on Wed, 26 Jan 2011 at 14:31:06 >>>>> >>>>>> I wasn't at the last Forum meeting, so may have missed some of the >>>>>> background. >>>>>> >>>>>> Is ticket #224 obsolete now? If so, you may want to indicate that in >>>> 224. >>>>> >>>>> Sorry, I've resolved it as withdrawn, with a comment that it was >>>>> supersceded by 265. >>>>> >>>>>> Do MPI_Send/Recv etc. remain unchanged, i.e., no MPI_Count in them? >>>>>> If so, why do we need a new MPI_Get_count? >>>>> >>>>> MPI_Send/Recv remain unchanged, and users are expected to create >>>> derived datatypes to express data structures that are larger than 2^31 >>>> basic elements. Now that you point it out, though, I would think >>>> MPI_Get_elements is sufficient, as MPI_Get_count should be using the >>>> same datatype as used in the operation that transferred the data. >>>> Hoping that Jeff, Quincy, or David can chime in here and clarify why we >>>> need it. >>>>> >>>>>> Are the new "w" versions of the collectives specifically related to >>>>>> this ticket (i.e. to address the 64-bit count requirement) or are they >>>>>> a separate issue (i.e. a general need for array of datatypes instead >>>>>> of one datatype)? >>>>> >>>>> By addressing the need for large counts via derived datatypes, we >>>> effectively encapsulate the 'count' in the 'datatype' parameters. As >>>> an example, if you want to gather different 'counts' from different >>>> ranks where there is no common denominator, you would need to derive a >>>> datatype for each source rank, and specify those individual datatypes. >>>> That can't be done today, we can only specify different counts, but >>>> are limited by the 2^31 range of the count fields. So the missing 'w' >>>> functions allow the datatype to be used to encapsulate the count. >>>>> >>>>>> Minor typos: Two of the prototypes for Scatterw say Scatterv >>>> instead. >>>>> >>>>> Fixed, thanks. >>>>> >>>>> -Fab >>>>> >>>>>> >>>>>> Rajeev >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Jan 26, 2011, at 3:38 PM, Fab Tillier wrote: >>>>>> >>>>>>> Ok folks, not a whole lot of time before the meeting, so it would >>>> be >>>>>> great if we could get everyone to read through the ticket and make >>>>>> sure I didn't miss something. I'd like to have David Solt generate a >>>>>> PDF sometime next week, in time for me to read it at the forum the >>>>>> following week (our time slot for this is 'working lunch' on >>>> Tuesday. >>>>>>> >>>>>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 >>>>>>> >>>>>>> Thanks for your help, >>>>>>> -Fab >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Mpi3-bwcompat mailing list >>>>>>> Mpi3-bwcompat_at_[hidden] >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Mpi3-bwcompat mailing list >>>>>> Mpi3-bwcompat_at_[hidden] >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat >>>>> >>>>> _______________________________________________ >>>>> Mpi3-bwcompat mailing list >>>>> Mpi3-bwcompat_at_[hidden] >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat >>>> >>>> >>>> _______________________________________________ >>>> Mpi3-bwcompat mailing list >>>> Mpi3-bwcompat_at_[hidden] >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat >>> >>> _______________________________________________ >>> Mpi3-bwcompat mailing list >>> Mpi3-bwcompat_at_[hidden] >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat >> >> >> _______________________________________________ >> Mpi3-bwcompat mailing list >> Mpi3-bwcompat_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat From jsquyres at [hidden] Thu Feb 3 06:57:24 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 3 Feb 2011 07:57:24 -0500 Subject: [Mpi3-bwcompat] Ticket 265 ready for review In-Reply-To: <0B503E76919828489362F1FA50483508E55D96@catoexm07.noam.corp.platform.com> Message-ID: Just FYI, the debates surrounding how to do MPI_Count have been going around in circles for about 2 years. Just ask Dave. :-) (MPI_Aint isn't really the right type -- it would need to be a new type; MPI_Count) On Feb 1, 2011, at 11:24 AM, Geoffrey Paulsen wrote: > Well, I agree with Rajeev, and would like to see both this approach AND > a whole new set of MPI_ functions with MPI_Aint Count (or some new > 64bit integer possibly implementation specific MPI_Count datatype) > argument for convenience. I would think a new major MPI revision (such > as MPI 3.0) is the time to introduce sweeping new classes of APIs, > otherwise it'll be another ten years or so until the next major revision > of the standard. > > Of course providing backwards compatibility with MPI 2.2 (hopefully at > the binary level of a particular implementation) is a priority as well. > It would be nice if we could have both. > > Geoff Paulsen > Platform MPI - http://www.platform.com/cluster-computing/platform-mpi > > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] > [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff > Squyres > Sent: Friday, January 28, 2011 3:33 PM > To: MPI-3 backwards compatability WG > Subject: Re: [Mpi3-bwcompat] Ticket 265 ready for review > > Rajeev -- > > The problem with your proposal is that it very, very quickly becomes a > slippery slope of making a new MPI_() with an MPI_Count argument > for every value of . > > The Forum has soundly rejected every form of that. This proposal is a > (return to) just proposing absolute minimal functionality that is > required for correctness. > > > On Jan 28, 2011, at 12:07 PM, Fab Tillier wrote: > >> Rajeev Thakur wrote on Fri, 28 Jan 2011 at 08:09:29 >> >>> Yes, it is not absolutely required, but becomes a convenience > feature. >> >> I believe Quincy will be bringing forth a proposal to address this, > but we wanted to get the minimum functionality to provide full support > for large datatypes captured in a single ticket without adding > convenience features. >> >> -Fab >> >>> >>> Rajeev >>> >>> On Jan 27, 2011, at 11:33 AM, Fab Tillier wrote: >>> >>>> Hi Rajeev, >>>> >>>> Rajeev Thakur wrote on Wed, 26 Jan 2011 at 21:59:33 >>>> >>>>> OK, thanks for the explanation. >>>>> >>>>> If count is encapsulated in derived datatypes, we might need new >>>>> datatype constructor functions that take MPI_Count, or at least a > new >>>>> MPI_Type_contiguous. Let's say the user wants to send an array of > size >>>>> X integers, where X is some weird number greater than 2G. If there > is a >>>>> new Type_contiguous, we have to see how it affects > Type_get_envelope >>>>> and Type_get_contents. >>>> >>>> We shouldn't need new datatype creator functions for this to work - > a user >>> can nest types, for example by creating a struct type of contiguous > types to >>> achieve the length desired. In this case, the >>> MPI_Type_get_envelope/contents would still work as currently defined. >>>> >>>> Does that make sense? >>>> >>>> Do we want to capture this discussion as comments on the ticket? >>>> >>>> Thanks for the feedback! >>>> -Fab >>>> >>>>> Rajeev >>>>> >>>>> >>>>> On Jan 26, 2011, at 4:56 PM, Fab Tillier wrote: >>>>> >>>>>> Hi Rajeev, >>>>>> >>>>>> Rajeev Thakur wrote on Wed, 26 Jan 2011 at 14:31:06 >>>>>> >>>>>>> I wasn't at the last Forum meeting, so may have missed some of > the >>>>>>> background. >>>>>>> >>>>>>> Is ticket #224 obsolete now? If so, you may want to indicate that > in >>>>> 224. >>>>>> >>>>>> Sorry, I've resolved it as withdrawn, with a comment that it was >>>>>> supersceded by 265. >>>>>> >>>>>>> Do MPI_Send/Recv etc. remain unchanged, i.e., no MPI_Count in > them? >>>>>>> If so, why do we need a new MPI_Get_count? >>>>>> >>>>>> MPI_Send/Recv remain unchanged, and users are expected to create >>>>> derived datatypes to express data structures that are larger than > 2^31 >>>>> basic elements. Now that you point it out, though, I would think >>>>> MPI_Get_elements is sufficient, as MPI_Get_count should be using > the >>>>> same datatype as used in the operation that transferred the data. >>>>> Hoping that Jeff, Quincy, or David can chime in here and clarify > why we >>>>> need it. >>>>>> >>>>>>> Are the new "w" versions of the collectives specifically related > to >>>>>>> this ticket (i.e. to address the 64-bit count requirement) or are > they >>>>>>> a separate issue (i.e. a general need for array of datatypes > instead >>>>>>> of one datatype)? >>>>>> >>>>>> By addressing the need for large counts via derived datatypes, we >>>>> effectively encapsulate the 'count' in the 'datatype' parameters. > As >>>>> an example, if you want to gather different 'counts' from different >>>>> ranks where there is no common denominator, you would need to > derive a >>>>> datatype for each source rank, and specify those individual > datatypes. >>>>> That can't be done today, we can only specify different counts, but >>>>> are limited by the 2^31 range of the count fields. So the missing > 'w' >>>>> functions allow the datatype to be used to encapsulate the count. >>>>>> >>>>>>> Minor typos: Two of the prototypes for Scatterw say Scatterv >>>>> instead. >>>>>> >>>>>> Fixed, thanks. >>>>>> >>>>>> -Fab >>>>>> >>>>>>> >>>>>>> Rajeev >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Jan 26, 2011, at 3:38 PM, Fab Tillier wrote: >>>>>>> >>>>>>>> Ok folks, not a whole lot of time before the meeting, so it > would >>>>> be >>>>>>> great if we could get everyone to read through the ticket and > make >>>>>>> sure I didn't miss something. I'd like to have David Solt > generate a >>>>>>> PDF sometime next week, in time for me to read it at the forum > the >>>>>>> following week (our time slot for this is 'working lunch' on >>>>> Tuesday. >>>>>>>> >>>>>>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 >>>>>>>> >>>>>>>> Thanks for your help, >>>>>>>> -Fab >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Mpi3-bwcompat mailing list >>>>>>>> Mpi3-bwcompat_at_[hidden] >>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Mpi3-bwcompat mailing list >>>>>>> Mpi3-bwcompat_at_[hidden] >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat >>>>>> >>>>>> _______________________________________________ >>>>>> Mpi3-bwcompat mailing list >>>>>> Mpi3-bwcompat_at_[hidden] >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat >>>>> >>>>> >>>>> _______________________________________________ >>>>> Mpi3-bwcompat mailing list >>>>> Mpi3-bwcompat_at_[hidden] >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat >>>> >>>> _______________________________________________ >>>> Mpi3-bwcompat mailing list >>>> Mpi3-bwcompat_at_[hidden] >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat >>> >>> >>> _______________________________________________ >>> Mpi3-bwcompat mailing list >>> Mpi3-bwcompat_at_[hidden] >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat >> >> _______________________________________________ >> Mpi3-bwcompat mailing list >> Mpi3-bwcompat_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat > > > -- > Jeff Squyres > jsquyres_at_[hidden] > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ From david.solt at [hidden] Thu Feb 3 21:42:21 2011 From: david.solt at [hidden] (Solt, David George) Date: Fri, 4 Feb 2011 03:42:21 +0000 Subject: [Mpi3-bwcompat] Ticket 265 ready for review In-Reply-To: <91B583BE4B6FCD408F53D1B8F537E0921D6D4C76@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: Attached is a first draft at the pdf. I'm having trouble with chapter 4, my "ticket" sections are being applied to strange texts that I didn't mark, etc. I'll work on it more tomorrow, but the new text is there (just in the wrong color). Here are some issues I came across as I did the pdf. I did NOT change these in the tex/pdf yet, but bring them to your attention first: P16, line 13 change: "width and encode address values" should be "width and encode count values" or "width and encode an number of datatype values" ? MPI_Scatterw definition uses sendtype in the argument list, but sendtypes in the argument list description. The "examples" (really in-line code) uses ';' for argument separators, is that "normal"? The displs description for MIP_Allgatherw uses some parenthesis not used in other displs descriptions. There are various lists of collective routines on page 137 (5.2.2) that should now include the w versions we added? The ticket lists Chapter 4 twice, but the second occurrence is meant to be Collectives. One thing I did change in the tex/pdf: In places where Fab added a _X function call and just added it in the ticket as if it should just be combined with the non-_X version, but the format of the tex/standard does not allow for this, the function needs to have its own separate presentation in order to use the tex macros. A general MPI problem (not specific to this ticket)... we often describe operations with the term: "specifying the number of elements to send to each processor". But processor/rank should not be used interchangeably. Thanks, Dave -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Fab Tillier Sent: Wednesday, January 26, 2011 3:39 PM To: MPI-3 backwards compatability WG Subject: [Mpi3-bwcompat] Ticket 265 ready for review Ok folks, not a whole lot of time before the meeting, so it would be great if we could get everyone to read through the ticket and make sure I didn't miss something. I'd like to have David Solt generate a PDF sometime next week, in time for me to read it at the forum the following week (our time slot for this is 'working lunch' on Tuesday. https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 Thanks for your help, -Fab _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat * -------------- next part -------------- A non-text attachment was scrubbed... Name: count-report.pdf Type: application/pdf Size: 4306517 bytes Desc: count-report.pdf URL: From jsquyres at [hidden] Fri Feb 4 10:25:54 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 4 Feb 2011 11:25:54 -0500 Subject: [Mpi3-bwcompat] Teleconf today: 1pm US Eastern Message-ID: I assume we're having the 1pm US Eastern call today to go over what will be discussed for the MPI_Count plenary, right? -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ From david.solt at [hidden] Fri Feb 4 11:23:16 2011 From: david.solt at [hidden] (Solt, David George) Date: Fri, 4 Feb 2011 17:23:16 +0000 Subject: [Mpi3-bwcompat] Teleconf today: 1pm US Eastern In-Reply-To: Message-ID: Yes, we are on for today. Dave -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Friday, February 04, 2011 10:26 AM To: MPI-3 Backwards Compat WG Subject: [Mpi3-bwcompat] Teleconf today: 1pm US Eastern I assume we're having the 1pm US Eastern call today to go over what will be discussed for the MPI_Count plenary, right? -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat From jsquyres at [hidden] Fri Feb 4 14:24:04 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 4 Feb 2011 15:24:04 -0500 Subject: [Mpi3-bwcompat] Ticket 265 ready for review In-Reply-To: Message-ID: On Feb 3, 2011, at 10:42 PM, Solt, David George wrote: > Attached is a first draft at the pdf. I'm having trouble with chapter 4, my "ticket" sections are being applied to strange texts that I didn't mark, etc. I'll work on it more tomorrow, but the new text is there (just in the wrong color). > > Here are some issues I came across as I did the pdf. I did NOT change these in the tex/pdf yet, but bring them to your attention first: > > P16, line 13 change: "width and encode address values" should be "width and encode count values" or "width and encode an number of datatype values" ? We resolved this on the call today. > MPI_Scatterw definition uses sendtype in the argument list, but sendtypes in the argument list description. Should all be "sendtypes". > The "examples" (really in-line code) uses ';' for argument separators, is that "normal"? Can you give a page/line of what you're referring to? > The displs description for MIP_Allgatherw uses some parenthesis not used in other displs descriptions. Can you give a page/line of what you're referring to? > There are various lists of collective routines on page 137 (5.2.2) that should now include the w versions we added? Agreed -- all I see in there is MPI_IALLTOALLW. > A general MPI problem (not specific to this ticket)... we often describe operations with the term: "specifying the number of elements to send to each processor". But processor/rank should not be used interchangeably. True. If you have a list of such places, I'd help with a ticket. -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ From david.solt at [hidden] Fri Feb 4 14:33:12 2011 From: david.solt at [hidden] (Solt, David George) Date: Fri, 4 Feb 2011 20:33:12 +0000 Subject: [Mpi3-bwcompat] Ticket 265 ready for review In-Reply-To: Message-ID: >> The "examples" (really in-line code) uses ';' for argument separators, is that >"normal"? > >Can you give a page/line of what you're referring to? P145 line 39 >> The displs description for MIP_Allgatherw uses some parenthesis not used in >other displs descriptions. > >Can you give a page/line of what you're referring to? Nevermind. It looks the same as MPI_Allgatherv, so I'm not sure what I was thinking. >> There are various lists of collective routines on page 137 (5.2.2) that should >now include the w versions we added? Will make this change. Regarding "processor vs rank", I'll get back to it after this ticket is ready for next week. Dave -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Friday, February 04, 2011 2:24 PM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] Ticket 265 ready for review On Feb 3, 2011, at 10:42 PM, Solt, David George wrote: > Attached is a first draft at the pdf. I'm having trouble with chapter 4, my "ticket" sections are being applied to strange texts that I didn't mark, etc. I'll work on it more tomorrow, but the new text is there (just in the wrong color). > > Here are some issues I came across as I did the pdf. I did NOT change these in the tex/pdf yet, but bring them to your attention first: > > P16, line 13 change: "width and encode address values" should be "width and encode count values" or "width and encode an number of datatype values" ? We resolved this on the call today. > MPI_Scatterw definition uses sendtype in the argument list, but sendtypes in the argument list description. Should all be "sendtypes". > The "examples" (really in-line code) uses ';' for argument separators, is that "normal"? Can you give a page/line of what you're referring to? > The displs description for MIP_Allgatherw uses some parenthesis not used in other displs descriptions. Can you give a page/line of what you're referring to? > There are various lists of collective routines on page 137 (5.2.2) that should now include the w versions we added? Agreed -- all I see in there is MPI_IALLTOALLW. > A general MPI problem (not specific to this ticket)... we often describe operations with the term: "specifying the number of elements to send to each processor". But processor/rank should not be used interchangeably. True. If you have a list of such places, I'd help with a ticket. -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat From ftillier at [hidden] Fri Feb 4 15:08:04 2011 From: ftillier at [hidden] (Fab Tillier) Date: Fri, 4 Feb 2011 21:08:04 +0000 Subject: [Mpi3-bwcompat] meeting minutes, 2.4.2011 Message-ID: <91B583BE4B6FCD408F53D1B8F537E0921D6E3E1E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Attendees - Alexander - Quincy - Jeff - David - Fab - Terry Need to add MPI_COUNT: pg 171_at_39 pg 545_at_27 pg 547_at_12 pg 554_at_7 pg16_at_18 "MPI_OFFSET_KIND" -> "MPI_COUNT_KIND" pg16_at_19 "encode address values" -> "encode values" pg16_at_23 "C int or Fortran INTEGER" -> "C int and Fortran INTEGER" pg33_at_18, missing '_X' pg105_at_36, document that MPI_GET_ELEMENTS overflow returns MPI_UNDEFINED. pg106_at_15, MPI_GET_ELEMENTS_X should have been MPI_GET_COUNT_X but is going away. pg98_at_6, 8, missing '_x' pg98_at_15, talk about overflow, return MPI_UNDEFINED. pg163_at_16, wrong opening quote for "in place" pg194_at_48, missing IGATHERW Drop MPI_Get_count_x, not needed - datatype must match call to recv/read/write, which are ints. From jsquyres at [hidden] Fri Feb 4 15:12:36 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 4 Feb 2011 16:12:36 -0500 Subject: [Mpi3-bwcompat] Ticket 265 ready for review In-Reply-To: Message-ID: <1D8CFAB2-655D-4A0B-9380-18C2663EC271@cisco.com> On Feb 4, 2011, at 3:33 PM, Solt, David George wrote: >>> The "examples" (really in-line code) uses ';' for argument separators, is that >"normal"? >> >> Can you give a page/line of what you're referring to? > > P145 line 39 Ya, that's weird. They should be commas. MPI_GATHERV, for example, uses commas. > Regarding "processor vs rank", I'll get back to it after this ticket is ready for next week. Fair enough. I'll make you a deal: if you make up the list of locations, I'll type up the ticket and shepherd it through the process. -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ From jsquyres at [hidden] Tue Feb 8 15:11:33 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Tue, 8 Feb 2011 13:11:33 -0800 Subject: [Mpi3-bwcompat] notes from MPI_Count discussion Message-ID: section 2.5.8 ...to overcome this *limitation*. p29:9 MPI_COUNT -> MPI_Count p123:32 Move "The following auxillary..." down. p96:16 We don't *return* the value MPI_UNDEFINED; we assign it to the OUT variable size. p96:16 also dont return size from function p102:44 needs to mention get_elements_x p103:27 missing an "and" 103:35 "returns" is listed twice p125 there was some allergic reactions to the pack_size changes drop change on line 4 keep change at line 7 p144:27 recvtype should be pluaral int recvcounts[] (not *) p155:12-13 t in front of the j p155:38 missing a "dot" (multiply) before the extent --> do we need to fix get_extent / get_true_extent to also return count types? (adam thinks that MPI_Aint is not guaranteed to be large enough -- may be problematic for files) Quincy chimes in later that he thinks Adam is right. p161:45-46 pointer types should be array types p194:4 indent is screwed up p194:15-16 t is in front of the j Follow up with Pavan: he doesn't think that the W collectives traw vote: as it stands - yes: 14 - no: 3 -- dave g, pavan, ...? (adam?) - pavan: hates w collectives - dave: hates w collectives - adam: thinks critical pieces missing (elements) -- and others that might be missing, too - abstain: 6 -- didn't get all of them, but saw: - 2 from OSU (Sayantan and the OSU grad student) - new IBM guy - ...? -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ From david.solt at [hidden] Fri Feb 18 10:16:34 2011 From: david.solt at [hidden] (Solt, David George) Date: Fri, 18 Feb 2011 16:16:34 +0000 Subject: [Mpi3-bwcompat] Meeting reminder In-Reply-To: Message-ID: Reminder that we are meeting today to discuss the feedback from the last forum meeting and determine what corrections are needed in the ticket and pdf. 11:00pm eastern time U.S. toll number 702.696.4520 U.S. toll-free dial-in number 866.409.2889 - Conference Code: 3582114059 From jsquyres at [hidden] Fri Feb 18 10:19:20 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 18 Feb 2011 11:19:20 -0500 Subject: [Mpi3-bwcompat] Meeting reminder In-Reply-To: Message-ID: <654A665F-BC10-4880-9372-15634CBCCAE2@cisco.com> On Feb 18, 2011, at 11:16 AM, Solt, David George wrote: > Reminder that we are meeting today to discuss the feedback from the last forum meeting and determine what corrections are needed in the ticket and pdf. > > 11:00pm eastern time I'm boring in my old age; I'll likely be asleep by that time. :-p -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ From jsquyres at [hidden] Fri Feb 18 10:59:45 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 18 Feb 2011 11:59:45 -0500 Subject: [Mpi3-bwcompat] Meeting reminder In-Reply-To: Message-ID: <86E10977-2397-4BE0-BAE6-8C0C7AA4386C@cisco.com> On Feb 18, 2011, at 11:16 AM, Solt, David George wrote: > 11:00pm eastern time Actually, now I'm unsure -- is that supposed to be 11am Eastern time, or 1pm Eastern time? -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ From david.solt at [hidden] Fri Feb 18 11:07:10 2011 From: david.solt at [hidden] (Solt, David George) Date: Fri, 18 Feb 2011 17:07:10 +0000 Subject: [Mpi3-bwcompat] Meeting reminder In-Reply-To: <86E10977-2397-4BE0-BAE6-8C0C7AA4386C@cisco.com> Message-ID: This is why I don't send out meeting reminders... I cause more confusion than I clear up. It is at 1:00pm eastern 12:00pm central, or in about an hour (depending on the speed of this mail getting to you). It's at the usual time. Thanks, Dave -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Friday, February 18, 2011 11:00 AM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] Meeting reminder On Feb 18, 2011, at 11:16 AM, Solt, David George wrote: > 11:00pm eastern time Actually, now I'm unsure -- is that supposed to be 11am Eastern time, or 1pm Eastern time? -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat