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

Re: [Mpi-forum] Fortran change for discussion
by Jeff Squyres (jsquyres) 11 Sep '12

11 Sep '12

FWIW, we chose the copying language not because of the c language, but rather because we have to explain that the MPI data type is applied, and that seemed far easier to explain against a (virtual) contiguous buffer. Sent from my phone. No type good. On Sep 11, 2012, at 3:38 AM, "N.M. Maclaren" <nmm1(a)cam.ac.uk> wrote: > On Sep 11 2012, Jeff Squyres wrote: >> >> You explain the situation in Fortran-eese, but the current text is an attempt to explain it in MPI-eese (i.e., in terms of copying). I think the MPI-reader-friendly text should be used. > > Sort-of, I agree. The problem with the current description is precisely > that it uses copying rather than aliasing as a basis, but I assume that > is for C programmers. There is definitely a problem in trying to explain > something in C-friendly terms that is conceptually outside C's rudimentary > array model. > >>> If the current text is kept, I think the clarification is important. >> >> Ok. > > The other possibility is to stress that the copying can occur at any > time between the initial call and the Wait. That is, after, all precisely > what asynchronous means in this context! > > > Regards, > Nick. > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] Fortran change for discussion
by N.M. Maclaren 11 Sep '12

11 Sep '12

On Sep 11 2012, Jeff Squyres wrote: > > You explain the situation in Fortran-eese, but the current text is an > attempt to explain it in MPI-eese (i.e., in terms of copying). I think > the MPI-reader-friendly text should be used. Sort-of, I agree. The problem with the current description is precisely that it uses copying rather than aliasing as a basis, but I assume that is for C programmers. There is definitely a problem in trying to explain something in C-friendly terms that is conceptually outside C's rudimentary array model. >> If the current text is kept, I think the clarification is important. > >Ok. The other possibility is to stress that the copying can occur at any time between the initial call and the Wait. That is, after, all precisely what asynchronous means in this context! Regards, Nick.

1 0

Re: [Mpi-forum] Fortran change for discussion
by Jeff Squyres 10 Sep '12

10 Sep '12

On Sep 10, 2012, at 4:50 PM, N.M. Maclaren wrote: > Sort of, except that I would say that the second paragraph (there are > actually two) is "unfortunate" not "weak". This is a bit more drastic, > but the following is some wording that is considerably more explicit, > though it does need some knowledge of the Fortran standard. > > All nonblocking MPI functions (e.g., MPI_ISEND, MPI_PUT, > MPI_FILE_WRITE_ALL_BEGIN) address the user-specified elements of > choice buffers as if they were a contiguous scratch buffer using > the rules of Fortran sequence association. > > Strictly, that's all that needs to be said! The remainder of that > paragraph is an explanation of Fortran sequence association in terms > of copying, which I agree is confusing. You explain the situation in Fortran-eese, but the current text is an attempt to explain it in MPI-eese (i.e., in terms of copying). I think the MPI-reader-friendly text should be used. > If the current text is kept, I think the clarification is important. Ok. -- 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: [Mpi-forum] Fortran change for discussion
by N.M. Maclaren 10 Sep '12

10 Sep '12

On Sep 10 2012, Jeff Squyres wrote: > > Jeremiah made the point that the text says that an MPI implementation > behaves as if it makes a copy of the buffer. He says that this implies > that it trumps the "user can't modify a non-blocking sending buffer while > the operation is ongoing" rule -- since the user can't modify the copy, > it might be inferred that the user can go modify the original. > >I think our text is weak but ok. The clarification doesn't hurt, though. Sort of, except that I would say that the second paragraph (there are actually two) is "unfortunate" not "weak". This is a bit more drastic, but the following is some wording that is considerably more explicit, though it does need some knowledge of the Fortran standard. All nonblocking MPI functions (e.g., MPI_ISEND, MPI_PUT, MPI_FILE_WRITE_ALL_BEGIN) address the user-specified elements of choice buffers as if they were a contiguous scratch buffer using the rules of Fortran sequence association. Strictly, that's all that needs to be said! The remainder of that paragraph is an explanation of Fortran sequence association in terms of copying, which I agree is confusing. If the current text is kept, I think the clarification is important. Regards, Nick Maclaren.

1 0

Proposal for voting rules
by Jeff Squyres 10 Sep '12

10 Sep '12

Attached is a proposal for formal voting rules for MPI <next>. It's had a bunch of discussion already; it's now time to open it up to the whole Forum. If possible, I'd like to discuss this in Vienna. Two questions that I gotten asked multiple times: 1. How would the meeting quorum rules have affected the MPI-3 process? 2. How would the individual vote quorum rules have affected the MPI-3 votes? I've written a perl script to calculate #1. #2 will take longer (I haven't even started yet); I doubt I'll have time to do this before Vienna. Short version: -------------- According to the attached proposed rules, the meeting quorum was met at every single MPI-3 meeting... except the Helsinki meeting (where we passed MPI-2.2 -- needed 16 OOE; had 15 orgs). In hindsight, that's actually rather amusing. :-) * Highest / lowest OOE: 28 / 18 * Highest / lowest IMOVE: 25 / 15 Fun fact: the only 2 orgs to have been at every single MPI-2.1/2.2/3.0 meeting are Argonne and Indiana U. More detail: ------------ My perl script can be found here (independent verification would be welcome): https://bitbucket.org/jsquyres/mpi-forum-rules/src/tip/history/analyze.pl The meeting dates and attendance values were input from my spreadsheets over the years. You can see a summary spreadsheet of the attendance in the same directory. Note that the IMOVE criteria is actually more relaxed than attendance -- you only have to *register*, but not actually *attend*. However, I do not have any records of people who registered and did not attend (more specifically, according to prior discussions, we *removed* orgs from voting eligibility if they registered and did not attend). So these records and statistics only reflect organizations that actually attended. Here's the output from running my script -- you can see that there's only one meeting where the quorum number is not met. ----- % ./analyze.pl Meeting: 2008-01 <skipped> Meeting: 2008-03 <skipped> Meeting: 2008-04 OOE (28): Argonne,Bull,Cisco,Cray,HDF,HLRS,HP,IBM,INRIA,IndianaU,Intel,LANL,LBL,LLNL,Mathworks,Mellanox,Microsoft,NEC,ORNL,OSU,QLogic,Sandia,SiCortex,Sun,UAB,UHouston,UIUC,UTenn IMOVE (25): Argonne,Bull,Cisco,Cray,HDF,HLRS,HP,IBM,INRIA,IndianaU,Intel,LANL,LBL,LLNL,Microsoft,NEC,ORNL,OSU,Sandia,SiCortex,Sun,UAB,UHouston,UIUC,UTenn Quorum: 18 +++ Meeting quorum satisfied Meeting: 2008-06 OOE (26): Argonne,Bull,Cisco,Cray,HDF,HLRS,HP,IBM,INRIA,IndianaU,Intel,LANL,LBL,LLNL,Microsoft,NEC,ORNL,OSU,QLogic,Sandia,SiCortex,Sun,UAB,UHouston,UIUC,UTenn IMOVE (21): Argonne,Bull,Cisco,Cray,HLRS,IBM,INRIA,IndianaU,Intel,LANL,LLNL,Microsoft,NEC,ORNL,QLogic,Sandia,SiCortex,Sun,UHouston,UIUC,UTenn Quorum: 17 +++ Meeting quorum satisfied Meeting: 2008-09 OOE (27): Argonne,Bull,Cisco,Cray,Fujitsu,HLRS,HP,IBM,INRIA,IndianaU,Intel,LANL,LBL,LLNL,Microsoft,NEC,ORNL,OSU,QLogic,Sandia,SiCortex,Sun,TokyoInstTech,UHouston,UIUC,UTenn,UTokyo IMOVE (24): Argonne,Cisco,Fujitsu,HLRS,HP,IBM,INRIA,IndianaU,Intel,LANL,LBL,LLNL,Microsoft,NEC,ORNL,OSU,QLogic,Sandia,Sun,TokyoInstTech,UHouston,UIUC,UTenn,UTokyo Quorum: 18 +++ Meeting quorum satisfied Meeting: 2008-10 OOE (28): Argonne,Bull,Cisco,Cray,Fujitsu,HLRS,HP,IBM,INRIA,IndianaU,Intel,LANL,LBL,LLNL,Mellanox,Microsoft,NEC,ORNL,OSU,QLogic,Sandia,SiCortex,Sun,TokyoInstTech,UHouston,UIUC,UTenn,UTokyo IMOVE (24): Argonne,Bull,Cisco,Cray,HLRS,HP,IBM,INRIA,IndianaU,Intel,LBL,LLNL,Mellanox,Microsoft,NEC,ORNL,OSU,Sandia,SiCortex,Sun,TokyoInstTech,UIUC,UTenn,UTokyo Quorum: 18 +++ Meeting quorum satisfied Meeting: 2008-12 OOE (27): Argonne,Cisco,Cray,HDF,HLRS,HP,IBM,INRIA,IndianaU,Intel,LANL,LBL,LLNL,Mellanox,Microsoft,NEC,ORNL,OSU,QLogic,Sandia,SiCortex,Sun,TokyoInstTech,UAB,UIUC,UTenn,UTokyo IMOVE (23): Argonne,Cisco,Cray,HDF,HLRS,IBM,INRIA,IndianaU,Intel,LANL,LLNL,Mellanox,NEC,ORNL,OSU,QLogic,Sandia,SiCortex,Sun,UAB,UIUC,UTenn,UTokyo Quorum: 18 +++ Meeting quorum satisfied Meeting: 2009-02 OOE (26): Argonne,Bull,Cisco,Cray,HDF,HLRS,HP,IBM,INRIA,IndianaU,Intel,LLNL,Mellanox,Microsoft,NEC,ORNL,OSU,QLogic,Sandia,SiCortex,Sun,TokyoInstTech,UAB,UIUC,UTenn,UTokyo IMOVE (24): Argonne,Bull,Cisco,Cray,HDF,HLRS,HP,IBM,INRIA,IndianaU,Intel,LLNL,Microsoft,NEC,ORNL,OSU,QLogic,Sandia,Sun,TokyoInstTech,UAB,UIUC,UTenn,UTokyo Quorum: 17 +++ Meeting quorum satisfied Meeting: 2009-04 OOE (25): Argonne,Cisco,Cray,HDF,HLRS,IBM,INRIA,IndianaU,Intel,LANL,LLNL,Mellanox,Microsoft,NEC,ORNL,OSU,QLogic,Sandia,SiCortex,Sun,TokyoInstTech,UAB,UIUC,UTenn,UTokyo IMOVE (23): Argonne,Cisco,Cray,HDF,HLRS,IBM,INRIA,IndianaU,Intel,LANL,LLNL,Mellanox,Microsoft,NEC,ORNL,OSU,Sandia,SiCortex,Sun,TokyoInstTech,UIUC,UTenn,UTokyo Quorum: 16 +++ Meeting quorum satisfied Meeting: 2009-06 OOE (22): Argonne,Cisco,Cray,HDF,HLRS,IBM,INRIA,IndianaU,Intel,LANL,LLNL,Microsoft,NEC,ORNL,OSU,Sandia,Sun,TokyoInstTech,UAB,UIUC,UTenn,UTokyo IMOVE (17): Argonne,Cisco,Cray,HDF,IBM,IndianaU,Intel,LANL,LLNL,Microsoft,NEC,ORNL,OSU,Sandia,Sun,UAB,UTenn Quorum: 14 +++ Meeting quorum satisfied Meeting: 2009-07 OOE (25): Argonne,Auburn,Cisco,Cray,HDF,HLRS,IBM,INRIA,IndianaU,Intel,LANL,LLNL,Mellanox,Microsoft,NEC,ORNL,OSU,PNNL,Sandia,Sun,TokyoInstTech,UAB,UIUC,UTenn,UTokyo IMOVE (25): Argonne,Auburn,Cisco,Cray,HDF,HLRS,IBM,INRIA,IndianaU,Intel,LANL,LLNL,Mellanox,Microsoft,NEC,ORNL,OSU,PNNL,Sandia,Sun,TokyoInstTech,UAB,UIUC,UTenn,UTokyo Quorum: 16 +++ Meeting quorum satisfied Meeting: 2009-09 OOE (23): Argonne,Auburn,Cisco,Cray,HDF,HLRS,IBM,INRIA,IndianaU,Intel,LANL,LLNL,Microsoft,NEC,ORNL,OSU,PNNL,RunTimeCompSlns,Sandia,Sun,UAB,UIUC,UTenn IMOVE (15): Argonne,Cisco,HDF,HLRS,IBM,INRIA,IndianaU,Intel,NEC,ORNL,RunTimeCompSlns,Sun,UAB,UIUC,UTenn Quorum: 15 --- MEETING QUORUM NOT SATISFIED! ================================== Meeting: 2009-11 OOE (25): Argonne,Cisco,Cray,Fujitsu,HDF,HLRS,HP,IBM,INRIA,IndianaU,Intel,LLNL,Microsoft,NEC,ORNL,OSU,PNNL,RunTimeCompSlns,Sandia,Sun,TokyoInstTech,UAB,UIUC,UTenn,UTokyo IMOVE (25): Argonne,Cisco,Cray,Fujitsu,HDF,HLRS,HP,IBM,INRIA,IndianaU,Intel,LLNL,Microsoft,NEC,ORNL,OSU,PNNL,RunTimeCompSlns,Sandia,Sun,TokyoInstTech,UAB,UIUC,UTenn,UTokyo Quorum: 16 +++ Meeting quorum satisfied Meeting: 2010-01 OOE (20): Argonne,Cisco,Cray,Fujitsu,HDF,HLRS,IBM,INRIA,IndianaU,Intel,LLNL,NEC,ORNL,OSU,RunTimeCompSlns,Sandia,Sun,UAB,UIUC,UTenn IMOVE (15): Argonne,Cisco,Cray,Fujitsu,HDF,INRIA,IndianaU,Intel,LLNL,OSU,RunTimeCompSlns,Sandia,UAB,UIUC,UTenn Quorum: 13 +++ Meeting quorum satisfied Meeting: 2010-03 OOE (24): Argonne,Cisco,Cray,Fujitsu,HDF,HLRS,HP,IBM,INRIA,IndianaU,Intel,LLNL,Microsoft,NEC,OSU,PNNL,RunTimeCompSlns,Sandia,TokyoInstTech,UAB,UHouston,UIUC,UTenn,UTokyo IMOVE (23): Argonne,Cisco,Cray,Fujitsu,HDF,HLRS,HP,IBM,INRIA,IndianaU,Intel,LLNL,Microsoft,NEC,OSU,PNNL,Sandia,TokyoInstTech,UAB,UHouston,UIUC,UTenn,UTokyo Quorum: 16 +++ Meeting quorum satisfied Meeting: 2010-05 OOE (21): Argonne,Cisco,Cray,Fujitsu,HDF,HLRS,IBM,INRIA,IndianaU,Intel,LANL,LLNL,Microsoft,OSU,Oracle,RunTimeCompSlns,Sandia,UAB,UHouston,UIUC,UTenn IMOVE (17): Argonne,Cisco,HDF,HLRS,IBM,INRIA,IndianaU,Intel,LANL,LLNL,Microsoft,OSU,Oracle,RunTimeCompSlns,Sandia,UAB,UIUC Quorum: 14 +++ Meeting quorum satisfied Meeting: 2010-06 OOE (21): Argonne,Cisco,Cray,Fujitsu,HDF,HLRS,HP,IBM,INRIA,IndianaU,Intel,LANL,LLNL,Microsoft,OSU,Oracle,RunTimeCompSlns,Sandia,UAB,UIUC,UTokyo IMOVE (18): Argonne,Cisco,Cray,Fujitsu,HDF,HLRS,HP,IBM,INRIA,IndianaU,LLNL,Microsoft,OSU,Oracle,RunTimeCompSlns,UAB,UIUC,UTokyo Quorum: 14 +++ Meeting quorum satisfied Meeting: 2010-09 OOE (21): Argonne,Cisco,Fujitsu,HDF,HLRS,IBM,INRIA,IndianaU,Intel,LANL,LBL,LLNL,Microsoft,ORNL,OSU,Oracle,RunTimeCompSlns,Sandia,UAB,UIUC,UTokyo IMOVE (16): Argonne,Cisco,Fujitsu,HDF,HLRS,IBM,INRIA,IndianaU,Intel,LANL,LBL,ORNL,Sandia,UAB,UIUC,UTokyo Quorum: 14 +++ Meeting quorum satisfied Meeting: 2010-10 OOE (22): Argonne,Cisco,Cray,Fujitsu,HDF,HLRS,HP,IBM,INRIA,IndianaU,Intel,LBL,LLNL,Microsoft,ORNL,OSU,Oracle,RunTimeCompSlns,Sandia,UAB,UIUC,UTokyo IMOVE (20): Argonne,Cisco,Cray,Fujitsu,HDF,HLRS,HP,IBM,IndianaU,Intel,LLNL,Microsoft,ORNL,OSU,Oracle,RunTimeCompSlns,Sandia,UAB,UIUC,UTokyo Quorum: 14 +++ Meeting quorum satisfied Meeting: 2010-12 OOE (20): Argonne,Bull,Cisco,Fujitsu,HDF,HLRS,IBM,IndianaU,Intel,LANL,LLNL,Microsoft,ORNL,OSU,Oracle,Sandia,UAB,UIUC,UTenn,UTokyo IMOVE (18): Argonne,Bull,Cisco,HDF,HLRS,IBM,IndianaU,Intel,LANL,LLNL,Microsoft,ORNL,OSU,Oracle,Sandia,UAB,UTenn,UTokyo Quorum: 13 +++ Meeting quorum satisfied Meeting: 2011-02 OOE (19): Argonne,Cisco,Cray,Fujitsu,HDF,HLRS,IBM,IndianaU,Intel,LANL,LLNL,Microsoft,ORNL,OSU,Oracle,Sandia,UAB,UIUC,UTokyo IMOVE (17): Argonne,Cisco,Cray,Fujitsu,HDF,IndianaU,Intel,LANL,LLNL,Microsoft,ORNL,OSU,Oracle,Sandia,UAB,UIUC,UTokyo Quorum: 12 +++ Meeting quorum satisfied Meeting: 2011-03 OOE (18): Argonne,Cisco,Cray,Fujitsu,HDF,HLRS,IBM,IndianaU,Intel,LANL,LLNL,Microsoft,ORNL,OSU,Oracle,Sandia,UAB,UTokyo IMOVE (16): Argonne,Cisco,Cray,Fujitsu,HDF,HLRS,IBM,IndianaU,Intel,LLNL,Microsoft,ORNL,OSU,Oracle,Sandia,UTokyo Quorum: 12 +++ Meeting quorum satisfied Meeting: 2011-05 OOE (20): Argonne,Cisco,Cray,Fujitsu,HDF,HLRS,IBM,INRIA,IndianaU,Intel,LANL,LLNL,Microsoft,ORNL,OSU,Oracle,Sandia,UAB,UIUC,UTokyo IMOVE (16): Argonne,Cisco,Fujitsu,HDF,HLRS,IBM,INRIA,IndianaU,Intel,LANL,LLNL,Microsoft,ORNL,Sandia,UAB,UIUC Quorum: 13 +++ Meeting quorum satisfied Meeting: 2011-07 OOE (20): Argonne,Cisco,Cray,Fujitsu,HDF,HLRS,HP,IBM,INRIA,IndianaU,Intel,LANL,LLNL,Microsoft,ORNL,OSU,Oracle,Sandia,UTenn,UTokyo IMOVE (19): Argonne,Cisco,Cray,Fujitsu,HDF,HLRS,HP,IBM,IndianaU,Intel,LANL,LLNL,Microsoft,ORNL,OSU,Oracle,Sandia,UTenn,UTokyo Quorum: 13 +++ Meeting quorum satisfied Meeting: 2011-09 OOE (19): Argonne,Cisco,Cray,Fujitsu,HDF,HLRS,IBM,INRIA,IndianaU,Intel,LANL,LLNL,Microsoft,ORNL,OSU,Riken,Sandia,UTenn,UTokyo IMOVE (15): Argonne,Cray,Fujitsu,HLRS,IBM,INRIA,IndianaU,LANL,LLNL,ORNL,OSU,Riken,Sandia,UTenn,UTokyo Quorum: 12 +++ Meeting quorum satisfied Meeting: 2011-10 OOE (19): Argonne,Cisco,Cray,Fujitsu,HDF,HLRS,IBM,IndianaU,Intel,LANL,LLNL,Microsoft,ORNL,OSU,Oracle,Riken,Sandia,UTenn,UTokyo IMOVE (18): Argonne,Cisco,Fujitsu,HDF,HLRS,IBM,IndianaU,Intel,LANL,LLNL,Microsoft,ORNL,OSU,Oracle,Riken,Sandia,UTenn,UTokyo Quorum: 12 +++ Meeting quorum satisfied Meeting: 2012-01 OOE (20): Argonne,Cisco,Cray,Fujitsu,HDF,HLRS,IBM,IndianaU,Intel,LANL,LLNL,Microsoft,ORNL,OSU,Oracle,Riken,Sandia,UIUC,UTenn,UTokyo IMOVE (18): Argonne,Cisco,Cray,Fujitsu,HDF,HLRS,IBM,IndianaU,Intel,LLNL,Microsoft,ORNL,OSU,Oracle,Riken,Sandia,UIUC,UTenn Quorum: 13 +++ Meeting quorum satisfied Meeting: 2012-03 OOE (21): Argonne,Cisco,Cray,Fujitsu,HDF,HLRS,IBM,IndianaU,Intel,LANL,LLNL,Microsoft,ORNL,OSU,Oracle,Riken,Sandia,UAB,UIUC,UTenn,UTokyo IMOVE (21): Argonne,Cisco,Cray,Fujitsu,HDF,HLRS,IBM,IndianaU,Intel,LANL,LLNL,Microsoft,ORNL,OSU,Oracle,Riken,Sandia,UAB,UIUC,UTenn,UTokyo Quorum: 14 +++ Meeting quorum satisfied Meeting: 2012-05 OOE (22): Argonne,Cisco,Cray,Fujitsu,HDF,HLRS,IBM,INRIA,IndianaU,Intel,Kyushu,LLNL,Microsoft,ORNL,OSU,Oracle,Riken,Sandia,UAB,UIUC,UTenn,UTokyo IMOVE (16): Argonne,Fujitsu,IBM,INRIA,IndianaU,Intel,Kyushu,LLNL,Microsoft,ORNL,Riken,Sandia,UAB,UIUC,UTenn,UTokyo Quorum: 14 +++ Meeting quorum satisfied Meeting: 2012-07 OOE (24): Argonne,Cisco,Cray,Fujitsu,HDF,HLRS,IBM,INRIA,IndianaU,Intel,Kyushu,LANL,LLNL,Mellanox,Microsoft,ORNL,OSU,Oracle,Riken,Sandia,UAB,UIUC,UTenn,UTokyo IMOVE (21): Argonne,Cisco,Cray,Fujitsu,HDF,HLRS,IBM,IndianaU,Intel,LANL,LLNL,Mellanox,Microsoft,ORNL,OSU,Oracle,Riken,Sandia,UAB,UIUC,UTokyo Quorum: 16 +++ Meeting quorum satisfied Highest / lowest OOE: 28 / 18 Highest / lowest IMOVE: 25 / 15 All done! % ----- -- 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: [Mpi-forum] Fortran change for discussion
by Richard Graham 10 Sep '12

10 Sep '12

Yeah - I can see how this could confuse folks, so makes sense. Rich -----Original Message----- From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Jeff Squyres Sent: Monday, September 10, 2012 2:18 PM To: Main MPI Forum mailing list Subject: Re: [Mpi-forum] Fortran change for discussion Jeremiah made the point that the text says that an MPI implementation behaves as if it makes a copy of the buffer. He says that this implies that it trumps the "user can't modify a non-blocking sending buffer while the operation is ongoing" rule -- since the user can't modify the copy, it might be inferred that the user can go modify the original. I think our text is weak but ok. The clarification doesn't hurt, though. On Sep 10, 2012, at 1:28 PM, Richard Graham wrote: > Certainly, > However, if we can come to some agreement over e-mail, this might be better, so we can put the final doc before folks sooner rather than later. > I went back and read the two paragraphs that you mention - why is this additional clarification needed ? I don't follow from the context, though the statement seems innocuous. > > Rich > > -----Original Message----- > From: mpi-forum-bounces(a)lists.mpi-forum.org > [mailto:[email protected]] On Behalf Of Jeff > Squyres > Sent: Monday, September 10, 2012 11:43 AM > To: MPI Forum list > Subject: [Mpi-forum] Fortran change for discussion > > Rich -- > > Per Jeremiah Willcock's comments, we'd like to add one small clarifying paragraph to the Fortran section. I think it's totally safe, but it's somehow intangibly above the "chapter author can add it himself" threshold for me. Specifically: I think the current text is a little weak, but sufficient. I'm therefore on the fence as to whether the text is *needed* in MPI-3.0 or whether it could be pushed to MPI next. > > Can this be added to the agenda during the discussion of user comments for the MPI-3.0 draft 2? > > Here's the specific proposal: > >> I propose adding the following paragraph after the big paragraph in draft 2 p628:27-44: >> >> Note that the above definition does not supercede restrictions about >> buffers used with non-blocking operations (e.g., those specified in >> Section~\ref{subsec:pt2pt-commstart}). > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] Fortran change for discussion
by Jeff Squyres 10 Sep '12

10 Sep '12

Jeremiah made the point that the text says that an MPI implementation behaves as if it makes a copy of the buffer. He says that this implies that it trumps the "user can't modify a non-blocking sending buffer while the operation is ongoing" rule -- since the user can't modify the copy, it might be inferred that the user can go modify the original. I think our text is weak but ok. The clarification doesn't hurt, though. On Sep 10, 2012, at 1:28 PM, Richard Graham wrote: > Certainly, > However, if we can come to some agreement over e-mail, this might be better, so we can put the final doc before folks sooner rather than later. > I went back and read the two paragraphs that you mention - why is this additional clarification needed ? I don't follow from the context, though the statement seems innocuous. > > Rich > > -----Original Message----- > From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Jeff Squyres > Sent: Monday, September 10, 2012 11:43 AM > To: MPI Forum list > Subject: [Mpi-forum] Fortran change for discussion > > Rich -- > > Per Jeremiah Willcock's comments, we'd like to add one small clarifying paragraph to the Fortran section. I think it's totally safe, but it's somehow intangibly above the "chapter author can add it himself" threshold for me. Specifically: I think the current text is a little weak, but sufficient. I'm therefore on the fence as to whether the text is *needed* in MPI-3.0 or whether it could be pushed to MPI next. > > Can this be added to the agenda during the discussion of user comments for the MPI-3.0 draft 2? > > Here's the specific proposal: > >> I propose adding the following paragraph after the big paragraph in draft 2 p628:27-44: >> >> Note that the above definition does not supercede restrictions about >> buffers used with non-blocking operations (e.g., those specified in >> Section~\ref{subsec:pt2pt-commstart}). > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- 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: [Mpi-forum] Fortran change for discussion
by Richard Graham 10 Sep '12

10 Sep '12

Certainly, However, if we can come to some agreement over e-mail, this might be better, so we can put the final doc before folks sooner rather than later. I went back and read the two paragraphs that you mention - why is this additional clarification needed ? I don't follow from the context, though the statement seems innocuous. Rich -----Original Message----- From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Jeff Squyres Sent: Monday, September 10, 2012 11:43 AM To: MPI Forum list Subject: [Mpi-forum] Fortran change for discussion Rich -- Per Jeremiah Willcock's comments, we'd like to add one small clarifying paragraph to the Fortran section. I think it's totally safe, but it's somehow intangibly above the "chapter author can add it himself" threshold for me. Specifically: I think the current text is a little weak, but sufficient. I'm therefore on the fence as to whether the text is *needed* in MPI-3.0 or whether it could be pushed to MPI next. Can this be added to the agenda during the discussion of user comments for the MPI-3.0 draft 2? Here's the specific proposal: > I propose adding the following paragraph after the big paragraph in draft 2 p628:27-44: > > Note that the above definition does not supercede restrictions about > buffers used with non-blocking operations (e.g., those specified in > Section~\ref{subsec:pt2pt-commstart}). -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] Fortran change for discussion
by Rolf Rabenseifner 10 Sep '12

10 Sep '12

I looked at the problems and will give some answers, but I'm teaching a group and have to leave now. Latest on Wednesday I'm back with answers. Rolf ----- Original Message ----- > From: "Jeff Squyres" <jsquyres(a)cisco.com> > To: "MPI Forum list" <mpi-forum(a)lists.mpi-forum.org> > Sent: Monday, September 10, 2012 5:38:42 PM > Subject: [Mpi-forum] Fortran change for discussion > Rich -- > > Per Jeremiah Willcock's comments, we'd like to add one small > clarifying paragraph to the Fortran section. I think it's totally > safe, but it's somehow intangibly above the "chapter author can add it > himself" threshold for me. Specifically: I think the current text is a > little weak, but sufficient. I'm therefore on the fence as to whether > the text is *needed* in MPI-3.0 or whether it could be pushed to MPI > next. > > Can this be added to the agenda during the discussion of user comments > for the MPI-3.0 draft 2? > > Here's the specific proposal: > > > I propose adding the following paragraph after the big paragraph in > > draft 2 p628:27-44: > > > > Note that the above definition does not supercede restrictions about > > buffers used with non-blocking operations (e.g., those specified in > > Section~\ref{subsec:pt2pt-commstart}). > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0

Fortran change for discussion
by Jeff Squyres 10 Sep '12

10 Sep '12

Rich -- Per Jeremiah Willcock's comments, we'd like to add one small clarifying paragraph to the Fortran section. I think it's totally safe, but it's somehow intangibly above the "chapter author can add it himself" threshold for me. Specifically: I think the current text is a little weak, but sufficient. I'm therefore on the fence as to whether the text is *needed* in MPI-3.0 or whether it could be pushed to MPI next. Can this be added to the agenda during the discussion of user comments for the MPI-3.0 draft 2? Here's the specific proposal: > I propose adding the following paragraph after the big paragraph in draft 2 p628:27-44: > > Note that the above definition does not supercede restrictions about > buffers used with non-blocking operations (e.g., those specified in > Section~\ref{subsec:pt2pt-commstart}). -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0