- Mpi3-bwcompat - mailman3.cels.anl.gov

Re: [Mpi3-bwcompat] MPI Backward Compatibility Working Group
by unknown＠example.com 13 Mar '11

13 Mar '11

Jeff, I like your wording, looks good to me. Are you going to fix up the latex and generate new PDFs that we can send out? -Fab -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Sunday, March 13, 2011 7:21 AM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] MPI Backward Compatibility Working Group On Mar 11, 2011, at 6:06 PM, Solt, David George wrote: > 2.5.8 Last sentence change to: > > The size of the MPI_Count type is determined by the MPI implementation > with the restriction that it must be minimally capable of encoding a C > int and Fortran INTEGER and any value that may be stored in an MPI_Aint type. "...and any value that may be stored in a variable of type MPI_Aint." > Rational thingy: Rationale. Potatoes. :-) > MPI_Count is used to communicate both the number of elements in a datatype and the bounds of a datatype. > The number of elements in a datatype is specified at creation time using a C int or Fortran INTEGER. The bounds > may be specified using an MPI_Aint. This is good. I would change the wording slightly -- let's not use the verb "communicate" here: "MPI_Count explicitly specifies the number of elements in a datatype, and therefore implicitly specifies the bounds of that datatype. The number of elements in a datatype is specified at creation time using a C int or Fortran INTEGER. The extent of a datatype is expressed using an MPI_Aint. How's that? -- 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

1 0

Re: [Mpi3-bwcompat] MPI Backward Compatibility Working Group
by unknown＠example.com 13 Mar '11

13 Mar '11

Thanks Dave; we'll finish this up by Monday so that we can get the PDF out in time for a formal reading. Have a great vacation! On Mar 13, 2011, at 1:19 AM, Solt, David George wrote: > I am on vacation this week, so I need to finish up my involvement as I can't say for sure if I will be on e-mail or not during the week. > > I checked in the changes I made here: > > https://svn.mpi-forum.org/svn/mpi-forum-docs/trunk/working-groups/mpi-3/bw-… > > I uploaded new versions of the pdf's to both tickets with the changes we discussed on Friday. For the issue we are discussing here, I added > > "and any value that may be stored in an MPI_Aint type." > > but did not add the rationale. > > Thanks, > Dave > > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Rajeev Thakur > Sent: Friday, March 11, 2011 11:21 PM > To: MPI-3 backwards compatability WG > Subject: Re: [Mpi3-bwcompat] MPI Backward Compatibility Working Group > > Could we say that MPI_Count should be the larger of MPI_Aint and MPI_Offset? (Anything bigger than that is not really useful.) That might help the I/O problem better. > > Rajeev > > > On Mar 11, 2011, at 11:07 PM, Fab Tillier wrote: > >> Hi Rajeev, >> >> A data buffer can't be larger than MPI_Aint in memory, but an MPI Datatype can be larger than what can fit in memory, and thus larger than MPI_Aint. MPI_Count allows such large datatypes to be represented and used in MPI, even if they can't be held in memory all at once. >> >> This proposal is intended to (minimally) solve the I/O problem, not just large network transfers. >> >> Does that make sense? >> -Fab >> >> -----Original Message----- >> From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Rajeev Thakur >> Sent: Friday, March 11, 2011 8:06 PM >> To: MPI-3 backwards compatability WG >> Subject: Re: [Mpi3-bwcompat] MPI Backward Compatibility Working Group >> >> What was the motivation for the new MPI_Type_get_extent_x and MPI_Type_get_true_extent_x functions? >> >> If we say MPI_Count should be at least as large as MPI_Aint, why can't we just use MPI_Aint instead? The data buffer can't be larger than Aint size. I know that for I/O MPI_Offset can be larger than Aint, but this proposal does not solve the I/O problem as far as I know. >> >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 >> >> Rajeev >> >> >> >> On Mar 11, 2011, at 5:06 PM, Solt, David George wrote: >> >>> During our meeting today we decided that MPI_Count should be at least as large as an MPI_Aint. We already had the restriction that it had to be as large as a C/Fortran integer. We want both restrictions (they cannot be combined because there is no guarantee that MPI_Aint > integer). >>> >>> I'll throw this out as a starting point for discussion: >>> >>> >>> >>> >>> 2.5.8 Last sentence change to: >>> >>> The size of the MPI_Count type is determined by the MPI implementation >>> with the restriction that it must be minimally capable of encoding a C >>> int and Fortran INTEGER and any value that may be stored in an MPI_Aint type. >>> >>> Rational thingy: >>> >>> MPI_Count is used to communicate both the number of elements in a datatype and the bounds of a datatype. >>> The number of elements in a datatype is specified at creation time using a C int or Fortran INTEGER. The bounds >>> may be specified using an MPI_Aint. >>> >>> >>> So, I was especially brief here. I did not want to get into the "new" routines vs. "old routines", but if you attempt to go into more depth than what I said, you will inevitably end up going down that path. I can think of a thousand ways not to say it, but its hard to come up with a good way. >>> Dave >>> >>> _______________________________________________ >>> 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/

1 0

Re: [Mpi3-bwcompat] MPI Backward Compatibility Working Group
by unknown＠example.com 13 Mar '11

13 Mar '11

On Mar 11, 2011, at 6:06 PM, Solt, David George wrote: > 2.5.8 Last sentence change to: > > The size of the MPI_Count type is determined by the MPI implementation > with the restriction that it must be minimally capable of encoding a C int and Fortran INTEGER > and any value that may be stored in an MPI_Aint type. "...and any value that may be stored in a variable of type MPI_Aint." > Rational thingy: Rationale. Potatoes. :-) > MPI_Count is used to communicate both the number of elements in a datatype and the bounds of a datatype. > The number of elements in a datatype is specified at creation time using a C int or Fortran INTEGER. The bounds > may be specified using an MPI_Aint. This is good. I would change the wording slightly -- let's not use the verb "communicate" here: "MPI_Count explicitly specifies the number of elements in a datatype, and therefore implicitly specifies the bounds of that datatype. The number of elements in a datatype is specified at creation time using a C int or Fortran INTEGER. The extent of a datatype is expressed using an MPI_Aint. How's that? -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [Mpi3-bwcompat] MPI Backward Compatibility Working Group
by unknown＠example.com 13 Mar '11

13 Mar '11

I am on vacation this week, so I need to finish up my involvement as I can't say for sure if I will be on e-mail or not during the week. I checked in the changes I made here: https://svn.mpi-forum.org/svn/mpi-forum-docs/trunk/working-groups/mpi-3/bw-… I uploaded new versions of the pdf's to both tickets with the changes we discussed on Friday. For the issue we are discussing here, I added "and any value that may be stored in an MPI_Aint type." but did not add the rationale. Thanks, Dave -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Rajeev Thakur Sent: Friday, March 11, 2011 11:21 PM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] MPI Backward Compatibility Working Group Could we say that MPI_Count should be the larger of MPI_Aint and MPI_Offset? (Anything bigger than that is not really useful.) That might help the I/O problem better. Rajeev On Mar 11, 2011, at 11:07 PM, Fab Tillier wrote: > Hi Rajeev, > > A data buffer can't be larger than MPI_Aint in memory, but an MPI Datatype can be larger than what can fit in memory, and thus larger than MPI_Aint. MPI_Count allows such large datatypes to be represented and used in MPI, even if they can't be held in memory all at once. > > This proposal is intended to (minimally) solve the I/O problem, not just large network transfers. > > Does that make sense? > -Fab > > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Rajeev Thakur > Sent: Friday, March 11, 2011 8:06 PM > To: MPI-3 backwards compatability WG > Subject: Re: [Mpi3-bwcompat] MPI Backward Compatibility Working Group > > What was the motivation for the new MPI_Type_get_extent_x and MPI_Type_get_true_extent_x functions? > > If we say MPI_Count should be at least as large as MPI_Aint, why can't we just use MPI_Aint instead? The data buffer can't be larger than Aint size. I know that for I/O MPI_Offset can be larger than Aint, but this proposal does not solve the I/O problem as far as I know. > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 > > Rajeev > > > > On Mar 11, 2011, at 5:06 PM, Solt, David George wrote: > >> During our meeting today we decided that MPI_Count should be at least as large as an MPI_Aint. We already had the restriction that it had to be as large as a C/Fortran integer. We want both restrictions (they cannot be combined because there is no guarantee that MPI_Aint > integer). >> >> I'll throw this out as a starting point for discussion: >> >> >> >> >> 2.5.8 Last sentence change to: >> >> The size of the MPI_Count type is determined by the MPI implementation >> with the restriction that it must be minimally capable of encoding a C >> int and Fortran INTEGER and any value that may be stored in an MPI_Aint type. >> >> Rational thingy: >> >> MPI_Count is used to communicate both the number of elements in a datatype and the bounds of a datatype. >> The number of elements in a datatype is specified at creation time using a C int or Fortran INTEGER. The bounds >> may be specified using an MPI_Aint. >> >> >> So, I was especially brief here. I did not want to get into the "new" routines vs. "old routines", but if you attempt to go into more depth than what I said, you will inevitably end up going down that path. I can think of a thousand ways not to say it, but its hard to come up with a good way. >> Dave >> >> _______________________________________________ >> 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

1 0

Re: [Mpi3-bwcompat] MPI Backward Compatibility Working Group
by unknown＠example.com 11 Mar '11

11 Mar '11

Could we say that MPI_Count should be the larger of MPI_Aint and MPI_Offset? (Anything bigger than that is not really useful.) That might help the I/O problem better. Rajeev On Mar 11, 2011, at 11:07 PM, Fab Tillier wrote: > Hi Rajeev, > > A data buffer can't be larger than MPI_Aint in memory, but an MPI Datatype can be larger than what can fit in memory, and thus larger than MPI_Aint. MPI_Count allows such large datatypes to be represented and used in MPI, even if they can't be held in memory all at once. > > This proposal is intended to (minimally) solve the I/O problem, not just large network transfers. > > Does that make sense? > -Fab > > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Rajeev Thakur > Sent: Friday, March 11, 2011 8:06 PM > To: MPI-3 backwards compatability WG > Subject: Re: [Mpi3-bwcompat] MPI Backward Compatibility Working Group > > What was the motivation for the new MPI_Type_get_extent_x and MPI_Type_get_true_extent_x functions? > > If we say MPI_Count should be at least as large as MPI_Aint, why can't we just use MPI_Aint instead? The data buffer can't be larger than Aint size. I know that for I/O MPI_Offset can be larger than Aint, but this proposal does not solve the I/O problem as far as I know. > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 > > Rajeev > > > > On Mar 11, 2011, at 5:06 PM, Solt, David George wrote: > >> During our meeting today we decided that MPI_Count should be at least as large as an MPI_Aint. We already had the restriction that it had to be as large as a C/Fortran integer. We want both restrictions (they cannot be combined because there is no guarantee that MPI_Aint > integer). >> >> I'll throw this out as a starting point for discussion: >> >> >> >> >> 2.5.8 Last sentence change to: >> >> The size of the MPI_Count type is determined by the MPI implementation >> with the restriction that it must be minimally capable of encoding a C >> int and Fortran INTEGER and any value that may be stored in an MPI_Aint type. >> >> Rational thingy: >> >> MPI_Count is used to communicate both the number of elements in a datatype and the bounds of a datatype. >> The number of elements in a datatype is specified at creation time using a C int or Fortran INTEGER. The bounds >> may be specified using an MPI_Aint. >> >> >> So, I was especially brief here. I did not want to get into the "new" routines vs. "old routines", but if you attempt to go into more depth than what I said, you will inevitably end up going down that path. I can think of a thousand ways not to say it, but its hard to come up with a good way. >> Dave >> >> _______________________________________________ >> 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

1 0

Re: [Mpi3-bwcompat] MPI Backward Compatibility Working Group
by unknown＠example.com 11 Mar '11

11 Mar '11

Hi Rajeev, A data buffer can't be larger than MPI_Aint in memory, but an MPI Datatype can be larger than what can fit in memory, and thus larger than MPI_Aint. MPI_Count allows such large datatypes to be represented and used in MPI, even if they can't be held in memory all at once. This proposal is intended to (minimally) solve the I/O problem, not just large network transfers. Does that make sense? -Fab -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Rajeev Thakur Sent: Friday, March 11, 2011 8:06 PM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] MPI Backward Compatibility Working Group What was the motivation for the new MPI_Type_get_extent_x and MPI_Type_get_true_extent_x functions? If we say MPI_Count should be at least as large as MPI_Aint, why can't we just use MPI_Aint instead? The data buffer can't be larger than Aint size. I know that for I/O MPI_Offset can be larger than Aint, but this proposal does not solve the I/O problem as far as I know. https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 Rajeev On Mar 11, 2011, at 5:06 PM, Solt, David George wrote: > During our meeting today we decided that MPI_Count should be at least as large as an MPI_Aint. We already had the restriction that it had to be as large as a C/Fortran integer. We want both restrictions (they cannot be combined because there is no guarantee that MPI_Aint > integer). > > I'll throw this out as a starting point for discussion: > > > > > 2.5.8 Last sentence change to: > > The size of the MPI_Count type is determined by the MPI implementation > with the restriction that it must be minimally capable of encoding a C > int and Fortran INTEGER and any value that may be stored in an MPI_Aint type. > > Rational thingy: > > MPI_Count is used to communicate both the number of elements in a datatype and the bounds of a datatype. > The number of elements in a datatype is specified at creation time using a C int or Fortran INTEGER. The bounds > may be specified using an MPI_Aint. > > > So, I was especially brief here. I did not want to get into the "new" routines vs. "old routines", but if you attempt to go into more depth than what I said, you will inevitably end up going down that path. I can think of a thousand ways not to say it, but its hard to come up with a good way. > Dave > > _______________________________________________ > 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

1 0

Re: [Mpi3-bwcompat] MPI Backward Compatibility Working Group
by unknown＠example.com 11 Mar '11

11 Mar '11

What was the motivation for the new MPI_Type_get_extent_x and MPI_Type_get_true_extent_x functions? If we say MPI_Count should be at least as large as MPI_Aint, why can't we just use MPI_Aint instead? The data buffer can't be larger than Aint size. I know that for I/O MPI_Offset can be larger than Aint, but this proposal does not solve the I/O problem as far as I know. https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 Rajeev On Mar 11, 2011, at 5:06 PM, Solt, David George wrote: > During our meeting today we decided that MPI_Count should be at least as large as an MPI_Aint. We already had the restriction that it had to be as large as a C/Fortran integer. We want both restrictions (they cannot be combined because there is no guarantee that MPI_Aint > integer). > > Ill throw this out as a starting point for discussion: > > > > > 2.5.8 Last sentence change to: > > The size of the MPI_Count type is determined by the MPI implementation > with the restriction that it must be minimally capable of encoding a C int and Fortran INTEGER > and any value that may be stored in an MPI_Aint type. > > Rational thingy: > > MPI_Count is used to communicate both the number of elements in a datatype and the bounds of a datatype. > The number of elements in a datatype is specified at creation time using a C int or Fortran INTEGER. The bounds > may be specified using an MPI_Aint. > > > So, I was especially brief here. I did not want to get into the new routines vs. old routines, but if you attempt to go into more depth than what I said, you will inevitably end up going down that path. I can think of a thousand ways not to say it, but its hard to come up with a good way. > Dave > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat

1 0

Re: [Mpi3-bwcompat] MPI Backward Compatibility Working Group
by unknown＠example.com 11 Mar '11

11 Mar '11

During our meeting today we decided that MPI_Count should be at least as large as an MPI_Aint. We already had the restriction that it had to be as large as a C/Fortran integer. We want both restrictions (they cannot be combined because there is no guarantee that MPI_Aint > integer). I'll throw this out as a starting point for discussion: 2.5.8 Last sentence change to: The size of the MPI_Count type is determined by the MPI implementation with the restriction that it must be minimally capable of encoding a C int and Fortran INTEGER and any value that may be stored in an MPI_Aint type. Rational thingy: MPI_Count is used to communicate both the number of elements in a datatype and the bounds of a datatype. The number of elements in a datatype is specified at creation time using a C int or Fortran INTEGER. The bounds may be specified using an MPI_Aint. So, I was especially brief here. I did not want to get into the "new" routines vs. "old routines", but if you attempt to go into more depth than what I said, you will inevitably end up going down that path. I can think of a thousand ways not to say it, but its hard to come up with a good way. Dave *

1 0

Re: [Mpi3-bwcompat] Plan for MPI_Count
by unknown＠example.com 09 Mar '11

09 Mar '11

I see. I uploaded a new copy. Note to self... In adobe reader, selecting the chapters you want and using right-click "print-pages" does print pages, but not a useful set of pages. Thanks, Dave -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Wednesday, March 09, 2011 10:53 AM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] Plan for MPI_Count Those PDFs do not contain the full chapters -- download them and have a look. On Mar 9, 2011, at 11:50 AM, Solt, David George wrote: > It contains (or I think it does) the full content of any chapter that was changed. Do you want a copy with just the pages that changed? > Dave > > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres > Sent: Wednesday, March 09, 2011 10:47 AM > To: MPI-3 backwards compatability WG > Subject: Re: [Mpi3-bwcompat] Plan for MPI_Count > > It looks like there are *many* pages missing from both of those PDFs -- the page numbering is far from consecutive. Some of the pages that remain contain no changes, so I can't figure out what the rationale was for removing some pages and not others...? > > > > On Mar 7, 2011, at 4:12 PM, Solt, David George wrote: > >>>> - Dave will send a final PDF to the bwcompat group to review early next week >> >> I attached the pdfs to the tickets 265 and 269. I have not reviewed them much myself yet. Perhaps we can do a quick review within the WG before we publicize them to chapter authors or any wider audience? >> >> Thanks, >> Dave >> >> _______________________________________________ >> 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/ _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat

1 0

Re: [Mpi3-bwcompat] Plan for MPI_Count
by unknown＠example.com 09 Mar '11

09 Mar '11

Those PDFs do not contain the full chapters -- download them and have a look. On Mar 9, 2011, at 11:50 AM, Solt, David George wrote: > It contains (or I think it does) the full content of any chapter that was changed. Do you want a copy with just the pages that changed? > Dave > > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres > Sent: Wednesday, March 09, 2011 10:47 AM > To: MPI-3 backwards compatability WG > Subject: Re: [Mpi3-bwcompat] Plan for MPI_Count > > It looks like there are *many* pages missing from both of those PDFs -- the page numbering is far from consecutive. Some of the pages that remain contain no changes, so I can't figure out what the rationale was for removing some pages and not others...? > > > > On Mar 7, 2011, at 4:12 PM, Solt, David George wrote: > >>>> - Dave will send a final PDF to the bwcompat group to review early next week >> >> I attached the pdfs to the tickets 265 and 269. I have not reviewed them much myself yet. Perhaps we can do a quick review within the WG before we publicize them to chapter authors or any wider audience? >> >> Thanks, >> Dave >> >> _______________________________________________ >> 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/

1 0