From treumann at [hidden] Mon Mar 3 10:34:42 2008 From: treumann at [hidden] (Richard Treumann) Date: Mon, 3 Mar 2008 11:34:42 -0500 Subject: [Mpi-21] Ballot 4 - Re: MPI_Abort nit In-Reply-To: Message-ID: I am OK with the proposed changes Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 "Rolf Rabenseifner" wrote on 01/29/2008 04:06:49 AM: > This is a proposal for MPI 2.1, Ballot 4. > > I'm asking especially > Karl Feind, Bill Gropp, Andrew Lumsdaine, Dick Treumann, > the participants of the email-discussion in 2001, to review this proposal. > > This is a follow up to: > MPI_Abort > in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > errata/index.html > with mail discussion in > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > errata/discuss/abort/ > ___________________________________ > > Proposal: > MPI-1.1 Sect. 7.5, MPI_Abort, page 200, lines 23-26 read: > This routine makes a "best attempt" to abort all tasks in the > group of comm. This function does not require that the invoking > environment take any action with the error code. However, a Unix or > POSIX environment should handle this as a return errorcode from the > main program or an abort(errorcode). > but should read (" or an abort(errorcode)" removed): > This routine makes a "best attempt" to abort all tasks in the > group of comm. This function does not require that the invoking > environment take any action with the error code. However, a Unix or > POSIX environment should handle this as a return errorcode from the > main program. > ___________________________________ > Rationale for this clarification: > POSIX defines void abort(void). The routine void exit(int status) > may be used to implement "handle this as a return errorcode from the > main program". abort(errorcode) was not substituted by exit(errorcode) > because this is technically not enough, if the MPI implementation > wants to return it also from mpiexec, see next proposal. > ___________________________________ > > Proposal: > Add after MPI-1.1 Sect. 7.5, MPI_Abort, page 200, line 34 (end of rationale): > Advice to users. Whether the errorcode is returned from the executable > or from the MPI process startup mechanism (e.g., mpiexec), is an aspect > of quality of the MPI library but not mandatory. (End of advice tousers.) > ___________________________________ > Rationale for this clarification: > The intent of word "should" in "should handle this as a return > errorcode from the main program" is only a quality of implementation > aspect and not a must. This is not clear and can be misinterpreted. > ___________________________________ > > > Best regards > Rolf > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) * -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaf at [hidden] Mon Mar 3 14:39:51 2008 From: kaf at [hidden] (Karl Feind) Date: Mon, 3 Mar 2008 14:39:51 -0600 Subject: [Mpi-21] Review of MPI-2.1 combined document In-Reply-To: Message-ID: <20080303203950.GB6236@sgi.com> Rolf & others, I have completed my review of Chapter 1 of the MPI 1 + 2 merging document. It looks pretty good. I did notice two sentences on page 4, section 1.4, lines 13 and 14 that apply to MPT 1.2 but not to MPI 2. This seems wrong in an MPI 2.1 standard document. Can we delete the following two sentences from the merged document? "Although no explicit support for threads is provided, the interface has been designed so as not to prejudice their use. With this version of MPI no support is provided for dynamic spawning of tasks." If we do that, we could combine the sentence at line 11 about MIMD and SPMD with the next paragraph that starts at line 15. This is the sentence I'm referring to: "The interface is suitable for use by fully general MIMD programs, as well as those written in the more restricted style of SPMD." Karl Feind On Sat, Feb 23, 2008 at 10:19:18PM +0100, Rolf Rabenseifner wrote: > The first draft of the combined document MPI 1.x plus MPI 2.0 > is ready for review !!! > > All necessary files can be found via > http://www.hlrs.de/mpi/mpi21/ > > The files are stored in a restricted directory to prohibit that > search engines can find the drafts. > > Dear reviewer: > Please print your chapter with colors (!) and check all merging decisions. > The colors will help to identify MPI 1.1-1.3 (black), > MPI-2.0 (magenta) and new text that was necessary for the merge (red). > > The review should be finished a few days before the March meeting. > Please post your review results on mpi-21_at_[hidden] as reply to this > mail. > > Please note, which chapter you reviewed. > > Please refer with all comments exactly to page and line numbers of > - MPI 1.1, the official Postscript version > - MPI 2.0, the official Postscript version > - MPI 2.1, draft 2008-02-23 from http://www.hlrs.de/mpi/mpi21/ > - and the merging plan 2008-02-23, that you can find at same directory > > If you detect a problem, it is necessary that you try to propose > a solution in similar notation as used in the merging plan. > > I have finished all except the merging of the MPI-1 C++ bindings > into the chapters' text, and except of merging the Annexes. > > The Ballots 1-4 are also not included. > In the moment, you need to review only the "merging". Nothing more. > If you detect errors in the original standards, then please > go through normal procedure, i.e., through the MPI 2.1 and MPI 2.2 > ballots. > > And now, thank you very much that you have registered to do a > review (if you are on the list below, done in Jan.2008 meeting). > > Good luck. > > Best regards > Rolf > > ---------------------------------------------------- > Frontmatter: (I've done a new proposal for the abstract, please check) > - Rusty Lusk, Bill Gropp > Chap. 1: Introduction to MPI > - Rusty Lusk, Bill Gropp, Karl Feind, Adam Moody > Chap. 2: MPI-2 Terms and Conventions > - Tony Skjellum, Bill Gropp, Richard Barrett > Chap. 3: Point-to-Point Communication (incl. sections from MPI-2 Misc. + 8.9) > - Rich Graham, Jespar Larsson Traeff, George Bosilca, > Steve Poole, Kannan Narasimhan, David Solt, B. Gropp, Matt Koop > Chap. 4: Collective Communication (incl. sections from MPI-2 Ext. Collect.) > - Steven Ericsson-Zenith, Edgar Gabriel, Rajeev Thakur, > Bill Gropp, Adam Moody, Georg Bosilca > Chap. 5: Groups, Context, and Communicators > (incl. sections from MPI-2 Ext.Col. + 8.8) > - Steven Ericsson-Zenith, Edgar Gabriel, > Bill Gropp, Georg Bosilca, Robert Blackmore > Chap. 6: Process Topologies > - Rusty Lusk, Bill Gropp, Richard Barrett > Chap. 7: MPI Environmental Management (incl. sections from MPI-2 Misc.) > - Rich Graham, Jespar Larsson Traeff, George Bosilca, > Steve Poole, Kannan Narasimhan, David Solt, B. Gropp > Chap. 8: Miscellany > - Rich Graham, George Bosilca, > Steve Poole, Kannan Narasimhan, B. Gropp > Chap. 9: Process Creation and Management > - Dries Kimpe, Rusty Lusk, Georg Bosilca, Bill Gropp, > Kalem Karian > Chap. 10: One-Sided Communication > - Ericsson-Zenith, Jespar Larsson Traeff, Martin Schulz, > Bill Gropp, Darius Buntinas > Chap. 11: External Interfaces > - Bronis de Supinski, Bill Gropp > Chap. 12: I/O > - Rajeev Thakur, Joachim Worringen, Bill Gropp > Chap. 13: Language Bindings > - Jeff Squyres, Steve Poole, Purushotham Bangalore, > Bill Gropp, Erez Haba, Alexander Supalov > Chap. 14: Profiling Interface > - Bronis de Supinski, Bill Gropp, Jeff Brown > Bibliography: (is done automatically) > - Rusty Lusk, Bill Gropp > Annex A: (this chapter is not yet done - therefore no review for this) > - Jeff Squyres, Steve Poole, Purushotham Bangalore, > Bill Gropp, Alexander Supalov > Index: (is done automatically) > - Rusty Lusk, Bill Gropp > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > _______________________________________________ > Mpi-21 mailing list > Mpi-21_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 From rabenseifner at [hidden] Mon Mar 3 15:21:43 2008 From: rabenseifner at [hidden] (Rolf Rabenseifner) Date: Mon, 03 Mar 2008 22:21:43 +0100 Subject: [Mpi-21] Ballot 3+4 - PDF for March meeting Message-ID: Please can you print the MPI-2.1 Ballot 3 and 4 pdf-files for the March meeting. This may help that you can check open questions during the meeting together with your MPI 1.1 and MPI 2.0 standard (e.g. on your Laptop). Ballot 4 slides can be found here: (slides) http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/mpi_21_at_MPIforum_2008-03_ballot_4.pdf Ballot 3: (latex based document) http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/ballot3.pdf This files are also linked at http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/ At the March meeting, MPI-2.1 has 4 different topics: - Ballot 3 (clarifications to MPI 1 and 2) first official vote - Ballot 4 (clarifications to MPI 1 and 2) first official reading - MPI-1.3 (combinded document: MPI-1.1 + 1.2) review - MPI-2.1 (combinded document: MPI-1.3 + 2.0) review Best regards Rolf Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) From rlgraham at [hidden] Mon Mar 3 17:29:03 2008 From: rlgraham at [hidden] (Richard Graham) Date: Mon, 03 Mar 2008 18:29:03 -0500 Subject: [Mpi-21] Review of MPI-2.1 combined document In-Reply-To: <20080303203950.GB6236@sgi.com> Message-ID: Here is a first cut at comments on chapter 3. It looks good overall. Some of these comments, I am sure, are relevant once the automated part is done, as it involves text changes referring to the new document. Rich Chapter 3: ********** What about signed char - it should also be in the basic data section. In addition, this and wide char and unsigned long long should go into the data type table. Pate 34, line 1-6 - ok, but marked in red. They are from the original 1.1 document. Page 39 is incorrect. Lines 36-38. there is a standard definition in Fortran 2003 for fortran/C interoperability. Page 53: lines 30-34, need to get the correct reference based on the new document. (also, unmarked as moved text) What happened to section 4.5/4.5.1 from the MPI 2.0 standard. 4.5.2 made it over. Page 69 line 7 incorrectly states that there are four ways to create persistent communication request. The correct number is 5 - 4 send, 1 receive. Page 72, lines 34-38 need to reference the correct pages in the combined 2.1 document. Page 76 lines 1-4 should not be colored. They are from the 1.1 doc. Page 76 line 39: Do we still want to keep the name New in the title ? This also seems out of place. Page 77 lines 1-12 should be merged with the text, with the MPI 1.1 versions explicitly marked as deprecated. Page 94: lines 42-46, reference the correct pages in the new combined document. Page 95: lines 2-4, do we need this explanation ? Page 95: line 21-22, change to page reference in the new document. On 3/3/08 3:39 PM, "Karl Feind" wrote: > > Rolf & others, > > I have completed my review of Chapter 1 of the MPI 1 + 2 merging > document. > > It looks pretty good. > > I did notice two sentences on page 4, section 1.4, lines 13 and 14 > that apply to MPT 1.2 but not to MPI 2. This seems wrong in an MPI 2.1 > standard document. Can we delete the following two sentences from the > merged document? > > "Although no explicit support for threads is provided, the > interface has been designed so as not to prejudice their use. With > this version of MPI no support is provided for dynamic spawning > of tasks." > > If we do that, we could combine the sentence at line 11 about MIMD and > SPMD with the next paragraph that starts at line 15. This is the sentence > I'm referring to: > > "The interface is suitable for use by fully general MIMD > programs, as well as those written in the more restricted style > of SPMD." > > Karl Feind > > > On Sat, Feb 23, 2008 at 10:19:18PM +0100, Rolf Rabenseifner wrote: >> The first draft of the combined document MPI 1.x plus MPI 2.0 >> is ready for review !!! >> >> All necessary files can be found via >> http://www.hlrs.de/mpi/mpi21/ >> >> The files are stored in a restricted directory to prohibit that >> search engines can find the drafts. >> >> Dear reviewer: >> Please print your chapter with colors (!) and check all merging decisions. >> The colors will help to identify MPI 1.1-1.3 (black), >> MPI-2.0 (magenta) and new text that was necessary for the merge (red). >> >> The review should be finished a few days before the March meeting. >> Please post your review results on mpi-21_at_[hidden] as reply to this >> mail. >> >> Please note, which chapter you reviewed. >> >> Please refer with all comments exactly to page and line numbers of >> - MPI 1.1, the official Postscript version >> - MPI 2.0, the official Postscript version >> - MPI 2.1, draft 2008-02-23 from http://www.hlrs.de/mpi/mpi21/ >> - and the merging plan 2008-02-23, that you can find at same directory >> >> If you detect a problem, it is necessary that you try to propose >> a solution in similar notation as used in the merging plan. >> >> I have finished all except the merging of the MPI-1 C++ bindings >> into the chapters' text, and except of merging the Annexes. >> >> The Ballots 1-4 are also not included. >> In the moment, you need to review only the "merging". Nothing more. >> If you detect errors in the original standards, then please >> go through normal procedure, i.e., through the MPI 2.1 and MPI 2.2 >> ballots. >> >> And now, thank you very much that you have registered to do a >> review (if you are on the list below, done in Jan.2008 meeting). >> >> Good luck. >> >> Best regards >> Rolf >> >> ---------------------------------------------------- >> Frontmatter: (I've done a new proposal for the abstract, please check) >> - Rusty Lusk, Bill Gropp >> Chap. 1: Introduction to MPI >> - Rusty Lusk, Bill Gropp, Karl Feind, Adam Moody >> Chap. 2: MPI-2 Terms and Conventions >> - Tony Skjellum, Bill Gropp, Richard Barrett >> Chap. 3: Point-to-Point Communication (incl. sections from MPI-2 Misc. + 8.9) >> - Rich Graham, Jespar Larsson Traeff, George Bosilca, >> Steve Poole, Kannan Narasimhan, David Solt, B. Gropp, Matt Koop >> Chap. 4: Collective Communication (incl. sections from MPI-2 Ext. Collect.) >> - Steven Ericsson-Zenith, Edgar Gabriel, Rajeev Thakur, >> Bill Gropp, Adam Moody, Georg Bosilca >> Chap. 5: Groups, Context, and Communicators >> (incl. sections from MPI-2 Ext.Col. + 8.8) >> - Steven Ericsson-Zenith, Edgar Gabriel, >> Bill Gropp, Georg Bosilca, Robert Blackmore >> Chap. 6: Process Topologies >> - Rusty Lusk, Bill Gropp, Richard Barrett >> Chap. 7: MPI Environmental Management (incl. sections from MPI-2 Misc.) >> - Rich Graham, Jespar Larsson Traeff, George Bosilca, >> Steve Poole, Kannan Narasimhan, David Solt, B. Gropp >> Chap. 8: Miscellany >> - Rich Graham, George Bosilca, >> Steve Poole, Kannan Narasimhan, B. Gropp >> Chap. 9: Process Creation and Management >> - Dries Kimpe, Rusty Lusk, Georg Bosilca, Bill Gropp, >> Kalem Karian >> Chap. 10: One-Sided Communication >> - Ericsson-Zenith, Jespar Larsson Traeff, Martin Schulz, >> Bill Gropp, Darius Buntinas >> Chap. 11: External Interfaces >> - Bronis de Supinski, Bill Gropp >> Chap. 12: I/O >> - Rajeev Thakur, Joachim Worringen, Bill Gropp >> Chap. 13: Language Bindings >> - Jeff Squyres, Steve Poole, Purushotham Bangalore, >> Bill Gropp, Erez Haba, Alexander Supalov >> Chap. 14: Profiling Interface >> - Bronis de Supinski, Bill Gropp, Jeff Brown >> Bibliography: (is done automatically) >> - Rusty Lusk, Bill Gropp >> Annex A: (this chapter is not yet done - therefore no review for this) >> - Jeff Squyres, Steve Poole, Purushotham Bangalore, >> Bill Gropp, Alexander Supalov >> Index: (is done automatically) >> - Rusty Lusk, Bill Gropp >> >> >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] >> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 >> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 >> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner >> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) >> _______________________________________________ >> Mpi-21 mailing list >> Mpi-21_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 > _______________________________________________ > Mpi-21 mailing list > Mpi-21_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 From rlgraham at [hidden] Mon Mar 3 18:28:57 2008 From: rlgraham at [hidden] (Richard Graham) Date: Mon, 03 Mar 2008 19:28:57 -0500 Subject: [Mpi-21] Review of MPI-2.1 combined document In-Reply-To: <20080303203950.GB6236@sgi.com> Message-ID: Some comments on chapter 7: Chapter 7: Page 247 line 34: MPI_VERSION should be 2 Page 250 lines 1-3: don't need to be red Page 253 lines 1-2: don't need to be red Page 253 line 14: Do we want to refer to MPI-2 specifically, or just as extended error handling ? Page 262: lines 1-11: Should MPI_ERR_KEYVAL be added to the list on page 261 ? Page 264: lines 6-16, should this be changed to reflect NULL arguments to MPI_Init() w/o backward reference to MPI 1.1 ? Rich On 3/3/08 3:39 PM, "Karl Feind" wrote: > > Rolf & others, > > I have completed my review of Chapter 1 of the MPI 1 + 2 merging > document. > > It looks pretty good. > > I did notice two sentences on page 4, section 1.4, lines 13 and 14 > that apply to MPT 1.2 but not to MPI 2. This seems wrong in an MPI 2.1 > standard document. Can we delete the following two sentences from the > merged document? > > "Although no explicit support for threads is provided, the > interface has been designed so as not to prejudice their use. With > this version of MPI no support is provided for dynamic spawning > of tasks." > > If we do that, we could combine the sentence at line 11 about MIMD and > SPMD with the next paragraph that starts at line 15. This is the sentence > I'm referring to: > > "The interface is suitable for use by fully general MIMD > programs, as well as those written in the more restricted style > of SPMD." > > Karl Feind > > > On Sat, Feb 23, 2008 at 10:19:18PM +0100, Rolf Rabenseifner wrote: >> The first draft of the combined document MPI 1.x plus MPI 2.0 >> is ready for review !!! >> >> All necessary files can be found via >> http://www.hlrs.de/mpi/mpi21/ >> >> The files are stored in a restricted directory to prohibit that >> search engines can find the drafts. >> >> Dear reviewer: >> Please print your chapter with colors (!) and check all merging decisions. >> The colors will help to identify MPI 1.1-1.3 (black), >> MPI-2.0 (magenta) and new text that was necessary for the merge (red). >> >> The review should be finished a few days before the March meeting. >> Please post your review results on mpi-21_at_[hidden] as reply to this >> mail. >> >> Please note, which chapter you reviewed. >> >> Please refer with all comments exactly to page and line numbers of >> - MPI 1.1, the official Postscript version >> - MPI 2.0, the official Postscript version >> - MPI 2.1, draft 2008-02-23 from http://www.hlrs.de/mpi/mpi21/ >> - and the merging plan 2008-02-23, that you can find at same directory >> >> If you detect a problem, it is necessary that you try to propose >> a solution in similar notation as used in the merging plan. >> >> I have finished all except the merging of the MPI-1 C++ bindings >> into the chapters' text, and except of merging the Annexes. >> >> The Ballots 1-4 are also not included. >> In the moment, you need to review only the "merging". Nothing more. >> If you detect errors in the original standards, then please >> go through normal procedure, i.e., through the MPI 2.1 and MPI 2.2 >> ballots. >> >> And now, thank you very much that you have registered to do a >> review (if you are on the list below, done in Jan.2008 meeting). >> >> Good luck. >> >> Best regards >> Rolf >> >> ---------------------------------------------------- >> Frontmatter: (I've done a new proposal for the abstract, please check) >> - Rusty Lusk, Bill Gropp >> Chap. 1: Introduction to MPI >> - Rusty Lusk, Bill Gropp, Karl Feind, Adam Moody >> Chap. 2: MPI-2 Terms and Conventions >> - Tony Skjellum, Bill Gropp, Richard Barrett >> Chap. 3: Point-to-Point Communication (incl. sections from MPI-2 Misc. + 8.9) >> - Rich Graham, Jespar Larsson Traeff, George Bosilca, >> Steve Poole, Kannan Narasimhan, David Solt, B. Gropp, Matt Koop >> Chap. 4: Collective Communication (incl. sections from MPI-2 Ext. Collect.) >> - Steven Ericsson-Zenith, Edgar Gabriel, Rajeev Thakur, >> Bill Gropp, Adam Moody, Georg Bosilca >> Chap. 5: Groups, Context, and Communicators >> (incl. sections from MPI-2 Ext.Col. + 8.8) >> - Steven Ericsson-Zenith, Edgar Gabriel, >> Bill Gropp, Georg Bosilca, Robert Blackmore >> Chap. 6: Process Topologies >> - Rusty Lusk, Bill Gropp, Richard Barrett >> Chap. 7: MPI Environmental Management (incl. sections from MPI-2 Misc.) >> - Rich Graham, Jespar Larsson Traeff, George Bosilca, >> Steve Poole, Kannan Narasimhan, David Solt, B. Gropp >> Chap. 8: Miscellany >> - Rich Graham, George Bosilca, >> Steve Poole, Kannan Narasimhan, B. Gropp >> Chap. 9: Process Creation and Management >> - Dries Kimpe, Rusty Lusk, Georg Bosilca, Bill Gropp, >> Kalem Karian >> Chap. 10: One-Sided Communication >> - Ericsson-Zenith, Jespar Larsson Traeff, Martin Schulz, >> Bill Gropp, Darius Buntinas >> Chap. 11: External Interfaces >> - Bronis de Supinski, Bill Gropp >> Chap. 12: I/O >> - Rajeev Thakur, Joachim Worringen, Bill Gropp >> Chap. 13: Language Bindings >> - Jeff Squyres, Steve Poole, Purushotham Bangalore, >> Bill Gropp, Erez Haba, Alexander Supalov >> Chap. 14: Profiling Interface >> - Bronis de Supinski, Bill Gropp, Jeff Brown >> Bibliography: (is done automatically) >> - Rusty Lusk, Bill Gropp >> Annex A: (this chapter is not yet done - therefore no review for this) >> - Jeff Squyres, Steve Poole, Purushotham Bangalore, >> Bill Gropp, Alexander Supalov >> Index: (is done automatically) >> - Rusty Lusk, Bill Gropp >> >> >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] >> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 >> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 >> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner >> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) >> _______________________________________________ >> Mpi-21 mailing list >> Mpi-21_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 > _______________________________________________ > Mpi-21 mailing list > Mpi-21_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 From thakur at [hidden] Mon Mar 3 19:37:19 2008 From: thakur at [hidden] (Rajeev Thakur) Date: Mon, 3 Mar 2008 19:37:19 -0600 Subject: [Mpi-21] Review of MPI-2.1 combined document In-Reply-To: Message-ID: <0a9201c87d98$48ec5d10$860add8c@mcs.anl.gov> Comments on Chapter 4 (Collective Communication) of MPI 2.1, draft 2008-02-23: * This chapter is a merge without change of the original collective comm chapter in MPI-1 and the chapter on extended collective ops in MPI-2. As a result, it uses the terms MPI-1, MPI-2, MPI-1.2 all over the place. Are we still retaining this distinction? If not, the text would need to be edited carefully to remove those terms. (Not doing it here.) * The introductory text from the original chapter in MPI-2.0 makes sense when it is viewed as an extension (add-on) to the chapter in MPI-1. But that text in its new location in Section 4.3 does not make sense as it is, because it appears before any of the collective functions have been introduced. Section 4.3 needs some careful editing to make it fit in its new position. (Not doing it here.) * pg 128, ln 5: Say "For intracommunicators, MPI_Barrier blocks the caller..." and delete the first sentence on ln 7 "For MPI-2, comm may be an intercomm or intracomm" * The already officially approved errata, which appear under "MPI 2.0 Errata" at http://www.mpi-forum.org/mpi2_1/index.htm need to be incorporated in this chapter. * Chapter 5 on Intercommunication says: "An inter-communicator cannot be used for collective communication." ln 48, pg 200. That needs to be deleted. Rajeev > -----Original Message----- > From: mpi-21-bounces_at_[hidden] > [mailto:mpi-21-bounces_at_[hidden]] On Behalf Of Rolf > Rabenseifner > Sent: Saturday, February 23, 2008 3:19 PM > To: Mailing list for discussion of MPI 2.1 > Subject: [Mpi-21] Review of MPI-2.1 combined document > > The first draft of the combined document MPI 1.x plus MPI 2.0 > is ready for review !!! > > All necessary files can be found via > http://www.hlrs.de/mpi/mpi21/ > > The files are stored in a restricted directory to prohibit that > search engines can find the drafts. > > Dear reviewer: > Please print your chapter with colors (!) and check all > merging decisions. > The colors will help to identify MPI 1.1-1.3 (black), > MPI-2.0 (magenta) and new text that was necessary for the merge (red). > > The review should be finished a few days before the March meeting. > Please post your review results on mpi-21_at_[hidden] as reply to this > mail. > > Please note, which chapter you reviewed. > > Please refer with all comments exactly to page and line numbers of > - MPI 1.1, the official Postscript version > - MPI 2.0, the official Postscript version > - MPI 2.1, draft 2008-02-23 from http://www.hlrs.de/mpi/mpi21/ > - and the merging plan 2008-02-23, that you can find at same > directory > > If you detect a problem, it is necessary that you try to propose > a solution in similar notation as used in the merging plan. > > I have finished all except the merging of the MPI-1 C++ bindings > into the chapters' text, and except of merging the Annexes. > > The Ballots 1-4 are also not included. > In the moment, you need to review only the "merging". Nothing more. > If you detect errors in the original standards, then please > go through normal procedure, i.e., through the MPI 2.1 and MPI 2.2 > ballots. > > And now, thank you very much that you have registered to do a > review (if you are on the list below, done in Jan.2008 meeting). > > Good luck. > > Best regards > Rolf > > ---------------------------------------------------- > Frontmatter: (I've done a new proposal for the abstract, please check) > - Rusty Lusk, Bill Gropp > Chap. 1: Introduction to MPI > - Rusty Lusk, Bill Gropp, Karl Feind, Adam Moody > Chap. 2: MPI-2 Terms and Conventions > - Tony Skjellum, Bill Gropp, Richard Barrett > Chap. 3: Point-to-Point Communication (incl. sections from > MPI-2 Misc. + 8.9) > - Rich Graham, Jespar Larsson Traeff, George Bosilca, > Steve Poole, Kannan Narasimhan, David Solt, B. > Gropp, Matt Koop > Chap. 4: Collective Communication (incl. sections from MPI-2 > Ext. Collect.) > - Steven Ericsson-Zenith, Edgar Gabriel, Rajeev Thakur, > Bill Gropp, Adam Moody, Georg Bosilca > Chap. 5: Groups, Context, and Communicators > (incl. sections from MPI-2 Ext.Col. + 8.8) > - Steven Ericsson-Zenith, Edgar Gabriel, > Bill Gropp, Georg Bosilca, Robert Blackmore > Chap. 6: Process Topologies > - Rusty Lusk, Bill Gropp, Richard Barrett > Chap. 7: MPI Environmental Management (incl. sections from > MPI-2 Misc.) > - Rich Graham, Jespar Larsson Traeff, George Bosilca, > Steve Poole, Kannan Narasimhan, David Solt, B. Gropp > Chap. 8: Miscellany > - Rich Graham, George Bosilca, > Steve Poole, Kannan Narasimhan, B. Gropp > Chap. 9: Process Creation and Management > - Dries Kimpe, Rusty Lusk, Georg Bosilca, Bill Gropp, > Kalem Karian > Chap. 10: One-Sided Communication > - Ericsson-Zenith, Jespar Larsson Traeff, Martin Schulz, > Bill Gropp, Darius Buntinas > Chap. 11: External Interfaces > - Bronis de Supinski, Bill Gropp > Chap. 12: I/O > - Rajeev Thakur, Joachim Worringen, Bill Gropp > Chap. 13: Language Bindings > - Jeff Squyres, Steve Poole, Purushotham Bangalore, > Bill Gropp, Erez Haba, Alexander Supalov > Chap. 14: Profiling Interface > - Bronis de Supinski, Bill Gropp, Jeff Brown > Bibliography: (is done automatically) > - Rusty Lusk, Bill Gropp > Annex A: (this chapter is not yet done - therefore no review > for this) > - Jeff Squyres, Steve Poole, Purushotham Bangalore, > Bill Gropp, Alexander Supalov > Index: (is done automatically) > - Rusty Lusk, Bill Gropp > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > _______________________________________________ > Mpi-21 mailing list > Mpi-21_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 > > From Dries.Kimpe at [hidden] Tue Mar 4 04:41:27 2008 From: Dries.Kimpe at [hidden] (Dries Kimpe) Date: Tue, 4 Mar 2008 11:41:27 +0100 Subject: [Mpi-21] Review of MPI-2.1 combined document In-Reply-To: Message-ID: <20080304104127.GA21965@mhdmobile.lan> What about the usage of deprecated functions? (for example, the old attribute functions, old datatype constructors, ...) Since the code examples were not modified, they often still use versions that were deprecated in later versions of the standard. (see pg. 17 in the merged document) Examples (by no means complete list): (pg. number in merged document) MPI_Attr_get: 309, 229, 244 MPI_Attr_put: 409, 227 MPI_Keyval_create : 244, 227 ... Greetings, Dries * Rolf Rabenseifner [2008-02-23 22:19:18]: > The first draft of the combined document MPI 1.x plus MPI 2.0 > is ready for review !!! > All necessary files can be found via > http://www.hlrs.de/mpi/mpi21/ > The files are stored in a restricted directory to prohibit that > search engines can find the drafts. > Dear reviewer: > Please print your chapter with colors (!) and check all merging decisions. > The colors will help to identify MPI 1.1-1.3 (black), > MPI-2.0 (magenta) and new text that was necessary for the merge (red). > The review should be finished a few days before the March meeting. > Please post your review results on mpi-21_at_[hidden] as reply to this > mail. > Please note, which chapter you reviewed. > Please refer with all comments exactly to page and line numbers of > - MPI 1.1, the official Postscript version > - MPI 2.0, the official Postscript version > - MPI 2.1, draft 2008-02-23 from http://www.hlrs.de/mpi/mpi21/ > - and the merging plan 2008-02-23, that you can find at same directory > If you detect a problem, it is necessary that you try to propose > a solution in similar notation as used in the merging plan. > I have finished all except the merging of the MPI-1 C++ bindings > into the chapters' text, and except of merging the Annexes. > The Ballots 1-4 are also not included. > In the moment, you need to review only the "merging". Nothing more. > If you detect errors in the original standards, then please > go through normal procedure, i.e., through the MPI 2.1 and MPI 2.2 > ballots. > And now, thank you very much that you have registered to do a > review (if you are on the list below, done in Jan.2008 meeting). > Good luck. > Best regards > Rolf > ---------------------------------------------------- > Frontmatter: (I've done a new proposal for the abstract, please check) > - Rusty Lusk, Bill Gropp > Chap. 1: Introduction to MPI > - Rusty Lusk, Bill Gropp, Karl Feind, Adam Moody > Chap. 2: MPI-2 Terms and Conventions > - Tony Skjellum, Bill Gropp, Richard Barrett > Chap. 3: Point-to-Point Communication (incl. sections from MPI-2 Misc. + 8.9) > - Rich Graham, Jespar Larsson Traeff, George Bosilca, > Steve Poole, Kannan Narasimhan, David Solt, B. Gropp, Matt Koop > Chap. 4: Collective Communication (incl. sections from MPI-2 Ext. Collect.) > - Steven Ericsson-Zenith, Edgar Gabriel, Rajeev Thakur, > Bill Gropp, Adam Moody, Georg Bosilca > Chap. 5: Groups, Context, and Communicators > (incl. sections from MPI-2 Ext.Col. + 8.8) > - Steven Ericsson-Zenith, Edgar Gabriel, > Bill Gropp, Georg Bosilca, Robert Blackmore > Chap. 6: Process Topologies > - Rusty Lusk, Bill Gropp, Richard Barrett > Chap. 7: MPI Environmental Management (incl. sections from MPI-2 Misc.) > - Rich Graham, Jespar Larsson Traeff, George Bosilca, > Steve Poole, Kannan Narasimhan, David Solt, B. Gropp > Chap. 8: Miscellany > - Rich Graham, George Bosilca, > Steve Poole, Kannan Narasimhan, B. Gropp > Chap. 9: Process Creation and Management > - Dries Kimpe, Rusty Lusk, Georg Bosilca, Bill Gropp, > Kalem Karian > Chap. 10: One-Sided Communication > - Ericsson-Zenith, Jespar Larsson Traeff, Martin Schulz, > Bill Gropp, Darius Buntinas > Chap. 11: External Interfaces > - Bronis de Supinski, Bill Gropp > Chap. 12: I/O > - Rajeev Thakur, Joachim Worringen, Bill Gropp > Chap. 13: Language Bindings > - Jeff Squyres, Steve Poole, Purushotham Bangalore, > Bill Gropp, Erez Haba, Alexander Supalov > Chap. 14: Profiling Interface > - Bronis de Supinski, Bill Gropp, Jeff Brown > Bibliography: (is done automatically) > - Rusty Lusk, Bill Gropp > Annex A: (this chapter is not yet done - therefore no review for this) > - Jeff Squyres, Steve Poole, Purushotham Bangalore, > Bill Gropp, Alexander Supalov > Index: (is done automatically) > - Rusty Lusk, Bill Gropp > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > _______________________________________________ > Mpi-21 mailing list > Mpi-21_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 * -------------- next part -------------- A non-text attachment was scrubbed... Name: 01-part Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From treumann at [hidden] Tue Mar 4 08:36:03 2008 From: treumann at [hidden] (Richard Treumann) Date: Tue, 4 Mar 2008 09:36:03 -0500 Subject: [Mpi-21] Review of MPI-2.1 combined document In-Reply-To: <20080304104127.GA21965@mhdmobile.lan> Message-ID: The MPI standard has several references to ANSI C and on page 15 of the combined doc we say to read ANSI C as ISO C. Does it make sense to fix this and just refer to ISO C? We might want to mention that the original books said ANSI C and the combined book has rectified that Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 * -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbarrett at [hidden] Tue Mar 4 10:42:01 2008 From: rbarrett at [hidden] (Richard Barrett) Date: Tue, 04 Mar 2008 11:42:01 -0500 Subject: [Mpi-21] Review of topology chapter 6 In-Reply-To: <0a9201c87d98$48ec5d10$860add8c@mcs.anl.gov> Message-ID: In general this section needs updating. It often reads like its trying to convince the reader that the functionality is worthwhile. Would also benefit from an update to citations in support of capabilities and features. Some text is clunky. Suggestions, corrections, observations, based on MPI 2.1, draft 2008-02-23. 1. p231, line 41: The citation supporting the performance potential of graph defined topologies is from 1989. Are there more recent citations to supplement? Similar question for other citations throughout the chapter. 2. p231, line 47: ³Šwith tremendous benefits for program readability². I appreciate the optimistic tone, but perhaps a little less hype: ³with potential benefitsŠ² 3. p232, line 6: ³The nodes stand forŠ². How about, ³represent²? 4. p232, line 7: ³MPI provides message-passing between any pair of processes in a group.² This seems to imply that topologies are only applicable to point-to-point communication. If so, we should clearly say so, earlier. 5. p232, line 17: Citation [9] is listed as ³To appear.² 6. p232, Lines 23-29. This seems like unnecessary rationalization. Unless it can be substantiated (with a citation), it should be removed. How about, ³When the graph structure is regular and can be completely defined by the number of dimensions and the number of processes in each coordinate direction, such as rings, two- or higher dimensional grids, or tori, a simpler description can be madeŠ² or the like. And then talk about support for Cartesian topologies, which suddenly is mentioned on 6.4, line 3 7. p233, line 5. How about, ³Šare collective, and therefore must adhere to that category¹s requirements.² Clunky, but the ideaŠ 8. p233, line 19: ³Similar functions are contained in EXPRESS and PARMACS.² Can we update (or eliminate) this? Sounds like, ³All the other kids are doing it.² :) 9. p233, line 22-33. Reads clunky. In particular, ³foo can be used toŠ² Implies they are designed primarily for something else. And perhaps provide a high level sentence regarding the content of the paragraph: ³A variety of inquiry functions are provided.² (Which then calls for a bit of a reorganization of the paragraph, since sub-setting functionality is discussed as well. 10. p234, line 27. ³choose a beneficial² rather than ³good². (Could be great! Or ok, orŠ) 11. p237, line 19-20. ³If a topology has been defined with one of the above functionsŠ² How else? Instead: ³Information regarding a process topology can be returned using inquiry functions.² Or something like that. 12. p238, line 6. Is ³dimension² a verb? 13. p241, line 15. I prefer, ³Suppose this topology is associated with communicator comm...² 14. p241, line 34. ³Šan MPI_SENDRECV², since Œa¹ and Œan¹ are selected based on the vowel or consonant sound. Or are these fightin¹ words? :) Errata: 1. pg 237, line 26: (choice) s/b (status). 2. The other errata seems to have been satisfied. Long example, p246. Any verification of correctness available? No complaints in the errata. Richard -- Richard Barrett Future Technologies Group, Computer Science and Mathematics Division, and Scientific Computing Group, National Center for Computational Science Oak Ridge National Laboratory http://ft.ornl.gov/~rbarrett From treumann at [hidden] Wed Mar 5 09:36:40 2008 From: treumann at [hidden] (Richard Treumann) Date: Wed, 5 Mar 2008 10:36:40 -0500 Subject: [Mpi-21] Review of MPI-2.1 combined document In-Reply-To: <[Mpi-21] Review of MPI-2.1 combined document> Message-ID: Comments on Chapter 5 of the 2.1 MPI standard (Robert Blackmore & Dick Treumann) Page 175, line 37-39 should be removed because it says there is no CC on intercommunicators Page 176, lines 1-6 also indicate there is no CC on intercommunicators page 177, line 10 indicate there is no CC on intercommunicators page 177, line 36 - should say MPI_INIT or MPI_INIT_THREAD page 178 line2 - Should say "Therefore, MPI_COMM_WORLD may simultaneously represent disjoint groups in different processes" page 186, line 19-22 - needs to be rephrased or removed. At least change "currenty apply" to "In MPI-1, applied" The last bullet at line 48 on page 200, "An inter-communicator cannot be used for collective communication" should be removed. The comment in parenthesis at line 24 on page 203 should be deleted along with the line before it. These two sentences contradict the sentence at line 23. (This conflict predates the merge and perhaps fixing this belongs to an erratta process - We do think it should be fixed) page 203, lines 38-42 are not consistent with how MPI-2 defined spawn. These lines should be removed Optionally, the description of MPI_Keyval_free should be moved to MPI_Comm_free_keyval and the routine MPI_Keyval_free function should refer to MPI_Comm_free_keyval description. Optionally, the description of MPI_Attr_put should be moved to MPI_Comm_set_attr and the routine MPI_Attr_put function should refer to MPI_Comm_set_attr description. Optionally, the description of MPI_Attr_get should be moved to MPI_Comm_get_attr and the routine MPI_Attr_get function should refer to MPI_Comm_get_attr description. Optionally, the description of MPI_Attr_delete should be moved to MPI_Comm_delete_attr and the routine MPI_Attr_delete function should refer to MPI_Comm_delete_attr description. On page 226 line 36, MPI_Keyval_create should be replaced by MPI_comm_create_keval On page 226 line 47 MPI_Attr_get should be replaced by MPI_Comm_get_attr. On page 227 line 22 MPI_Attr_put should be replaced by MPI_Comm_set_attr. Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 * -------------- next part -------------- An HTML attachment was scrubbed... URL: From rabenseifner at [hidden] Wed Mar 5 11:38:34 2008 From: rabenseifner at [hidden] (Rolf Rabenseifner) Date: Wed, 05 Mar 2008 18:38:34 +0100 Subject: [Mpi-21] MPI 1.3 Review Message-ID: Dear Bill, Adam, and Puri, (and all who are also interested,) you have volontiered for the MPI-1.3 review. I'm sorry that we could not finish MPI-1.3 earlier. It is now available (see attached email). Please, control whether all the clarifications and decisions from (you'll find all input via the doc-directory mentioned below) - MPI 1.2 pages in MPI-2 document - Additional Errata from MPI 1.1 errata document - Some Ballot 3 items from Jan. meeting - MPI 1.3 decisions from Jan. meeting (see protocol slides) are exactly put into the MPI-1.1 document. The rest of MPI-1.1 was not touched by Rainer and should be okay therefore. Based on my impression from an earlier version, I want to thank Rainer for this important initial step to the future of combined MPI documents. Thank you for the reviews in advance and best regards, see you in Chicago Rolf Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) --- the forwarded message follows --- attached mail follows: Because MPI-1.3 and MPI-2.1 review at March meeting is the preparation of the final "reading" at June meeting, I want to inform the whole Forum that the files are available at http://www.hlrs.de/mpi/mpi21/ You need mpi21 as user and password when you klick on the doc link. There, you can find all necessary information. Best regards Rolf Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) From treumann at [hidden] Wed Mar 5 15:31:34 2008 From: treumann at [hidden] (Richard Treumann) Date: Wed, 5 Mar 2008 16:31:34 -0500 Subject: [Mpi-21] [mpi-21] problem with MPI_Get_count and MPI_Probe In-Reply-To: Message-ID: I did not notice this until I was going over the Ballot 4 slides. I would prefer not to vote in the currently proposed wording The correction is for page 22, not 222 I propose: MPI 1.1, page 22, line 48 reads used after a call to MPI_PROBE. (End of rationale.) but should read used after a call to MPI_PROBE or MPI_IPROBE. In this case the call to MPI_GET_COUNT should use the same datatype as will be used in the MPI_RECV. (End of rationale.) (Advice to users.) The buffer size required for the receive can be affected by data conversions and by the stride of the receive datatype. Calling MP_GET_COUNT with MPI_BYTE to calculate the receive buffer size may not be portable unless the MPI_RECV uses MPI_BYTE. (End of advice to users.) Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 "Rolf Rabenseifner" mpi-21_at_[hidden] Sent by: cc mpi-21-bounces_at_cs mpi-21_at_[hidden] .uiuc.edu Subject Re: [mpi-21] problem with MPI_Get_count and MPI_Probe 01/18/2008 12:55 PM Please respond to "Mailing list for discussion of MPI 2.1" This is a proposal for MPI 2.1, Ballot 4. This is a follow up to: Datatypes and MPI_PROBE in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.html with mail discussion in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discuss/probedatatype/ Proposal for MPI 2.1, Ballot 4: ------------------------------- MPI 1.1, page 222, line 48 reads used after a call to MPI_PROBE. (End of rationale.) but should read used after a call to MPI_PROBE or MPI_IPROBE. With a status returned from MPI_PROBE or MPI_IPROBE, the same dataypes are allowed as in a call to MPI_RECV to receive this message. (End of rationale.) Advice to users. To allocate the appropriate amount of memory as receive buffer, the same datatype as in the following receive call should be used to determine the needed space. In portable programs due to possible data conversions, it is not guaranteed that the count returned by MPI_GET_COUNT with datatype MPI_BYTE is the correct amount of needed memory space in the receive buffer (although MPI_BYTE is matching every datatype). (End of advice to users.) ------------------------------- Reason for the first part: The current MPI-1.1 text says "The datatype argument should match the argument provided by the receive call that set the status variable." With MPI_PROBE, there isn't such a receive call. Reason for the advice to users: It helps to write portable code. Because malloc needs a byte count, users may write wrong programs by using MPI_BYTE. ------------------------------- Discussion should be done through the new mailing list mpi-21_at_cs.uiuc.edu. I have sent out this mail with CC through the old general list mpi-21_at_[hidden] Best regards Rolf Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) _______________________________________________ mpi-21 mailing list mpi-21_at_[hidden] http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 * -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: application/octet-stream Size: 203 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pic16838.gif Type: application/octet-stream Size: 1255 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ecblank.gif Type: application/octet-stream Size: 45 bytes Desc: not available URL: From treumann at [hidden] Wed Mar 5 15:52:50 2008 From: treumann at [hidden] (Richard Treumann) Date: Wed, 5 Mar 2008 16:52:50 -0500 Subject: [Mpi-21] [mpi-21] problem with MPI_Get_count and MPI_Probe In-Reply-To: Message-ID: I did not notice this until I was going over the Ballot 4 slides. I would prefer not to vote in the currently proposed wording The correction is for page 22, not 222 I propose: MPI 1.1, page 22, line 48 reads used after a call to MPI_PROBE. (End of rationale.) but should read used after a call to MPI_PROBE or MPI_IPROBE. In this case the call to MPI_GET_COUNT should use the same datatype as will be used in the MPI_RECV. (End of rationale.) (Advice to users.) The buffer size required for the receive can be affected by data conversions and by the stride of the receive datatype. Calling MP_GET_COUNT with MPI_BYTE to calculate the receive buffer size may not be portable unless the MPI_RECV uses MPI_BYTE. (End of advice to users.) Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-21-bounces_at_[hidden] wrote on 01/18/2008 12:55:09 PM: > This is a proposal for MPI 2.1, Ballot 4. > > This is a follow up to: > Datatypes and MPI_PROBE > in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > errata/index.html > with mail discussion in > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > errata/discuss/probedatatype/ > > > Proposal for MPI 2.1, Ballot 4: > ------------------------------- > MPI 1.1, page 222, line 48 reads > used after a call to MPI_PROBE. (End of rationale.) > but should read > used after a call to MPI_PROBE or MPI_IPROBE. > With a status returned from MPI_PROBE or MPI_IPROBE, the same > dataypes are allowed as in a call to MPI_RECV to receive this message. > (End of rationale.) > > Advice to users. To allocate the appropriate amount of memory as receive > buffer, the same datatype as in the following receive call should be used > to determine the needed space. In portable programs due to possible data > conversions, it is not guaranteed that the count returned by MPI_GET_COUNT > with datatype MPI_BYTE is the correct amount of needed memory space in > the receive buffer (although MPI_BYTE is matching every datatype). > (End of advice to users.) > ------------------------------- > > Reason for the first part: The current MPI-1.1 text says "The > datatype argument > should match the argument provided by the receive call that set the status > variable." With MPI_PROBE, there isn't such a receive call. > > Reason for the advice to users: It helps to write portable code. > Because malloc needs a byte count, users may write wrong programs > by using MPI_BYTE. > > ------------------------------- > > Discussion should be done through the new mailing list > mpi-21_at_cs.uiuc.edu. > > I have sent out this mail with CC through the old general list > mpi-21_at_[hidden] > > Best regards > Rolf > > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 * -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsquyres at [hidden] Wed Mar 5 20:04:40 2008 From: jsquyres at [hidden] (Jeff Squyres) Date: Wed, 5 Mar 2008 21:04:40 -0500 Subject: [Mpi-21] Review of MPI-2.1 combined document In-Reply-To: Message-ID: <0289A2A6-8DD0-4B00-AF17-18D17CA894A7@cisco.com> On Feb 23, 2008, at 4:19 PM, Rolf Rabenseifner wrote: > Dear reviewer: > Please print your chapter with colors (!) and check all merging > decisions. > The colors will help to identify MPI 1.1-1.3 (black), > MPI-2.0 (magenta) and new text that was necessary for the merge (red). Is there a way to use different colors, perchance? The language bindings chapter is all MPI-2 (magenta); it is nearly impossible to tell if there is any merge text in it (red). -- Jeff Squyres Cisco Systems From jsquyres at [hidden] Wed Mar 5 20:15:35 2008 From: jsquyres at [hidden] (Jeff Squyres) Date: Wed, 5 Mar 2008 21:15:35 -0500 Subject: [Mpi-21] MPI-2.1: Fortran 90 bindings Message-ID: The current MPI-2 F90 bindings are un-implementable because they require almost 7 *million* interface functions: with 15 intrinsic Fortran types, each with 7 possible dimensions, the current F90 interface *requires*: - 50 MPI functions with one choice buffer: 15 * 7 * 50 = 5,250 functions - 25 MPI functions with two choice buffers: (15 * 7 * 25)^2 = 6.8M functions - ...and a few hundred more MPI functions with no choice buffers This is clearly broken. An MPI-2.1-worthy solution could be to add a global statement saying that MPI functions with two choice buffers are explicitly not included in the F90 bindings. F90 MPI applications can transparently fall back to the F77 bindings (although they won't get the strong type checking, etc.). This idea therefore fits the requirement of not breaking any existing MPI codes. Specifically: if we remove the requirement to provide all MPI functions with two choice buffers, 5,000+ F90 interface functions is [a pain but] implementable. I doubt that any current MPI implementation provides more than the no-choice-buffers plus one- choice-buffer functions anyway... If this seems like a good idea, I can write a proper proposal for it. Comments? -- Jeff Squyres Cisco Systems From jsquyres at [hidden] Wed Mar 5 21:05:42 2008 From: jsquyres at [hidden] (Jeff Squyres) Date: Wed, 5 Mar 2008 22:05:42 -0500 Subject: [Mpi-21] Review of MPI-2.1 combined document In-Reply-To: Message-ID: On Feb 23, 2008, at 4:19 PM, Rolf Rabenseifner wrote: > The first draft of the combined document MPI 1.x plus MPI 2.0 > is ready for review !!! A few general comments on the document: - I love the new items in the index (constants, typedefs, etc.). Very useful! - I see a few EXAMPLES items in the index. But this is clearly not *all* the examples. What's the intent for these items? - p568 in the index has a whole series of lower-case CONST items in the second column that appear to be mistakes (e.g., column headings and the like). Ditto for both columns on page 565 (first page of the index). It looks like a macro is being mis-used throughout the latex...? - It would be really, Really, REALLY nice if the printed page numbers agreed with the PDF page numbers. :-) E.g., the first page of the index has "565" on the bottom of the page, but my PDF viewer tells me that it's really page 583. - How about adding a list of tables and list of figures to the beginning of the document (after the TOC)? How about possibly a list of examples? (I don't know if that's as trivial to generate as LOF/LOT) - In the credits on pages xvi and xvii, should institutions participating in MPI-2.1 be listed? (I can't remember if we discussed this at the last meeting) I.e., there are organizations contributing to the 2.1 document who are not being given credit (e.g., Cisco :-) ). - page 3: "MPI-2 compliance will mean compliance with all of MPI-2." The statement right above that says "MPI-1 compliance will mean compliance with MPI-1.2.", but the credits (page xviii) cite MPI-1.3 and MPI-2.1. - page 5: I see "MPI-2" are in the wrong font twice (there may be more?). - I still have a problem with the wording in section 2.3 about IN / OUT / INOUT, particularly because in section 2.3 we say that IN/OUT/ INOUT does *not* correspond to language bindings, but section 2.6.4 (pages 21-22) specifically states that IN arguments were made "const" in the C++ bindings. I also still have a problem with the special exception for INOUT. Are these topics covered in a ballot somewhere? (those are on my to-do list to examine; haven't gotten there yet...). -- Jeff Squyres Cisco Systems From luis.kornblueh at [hidden] Thu Mar 6 01:51:19 2008 From: luis.kornblueh at [hidden] (Luis Kornblueh) Date: Thu, 6 Mar 2008 08:51:19 +0100 Subject: [Mpi-21] MPI-2.1: Fortran 90 bindings In-Reply-To: Message-ID: <20080306075119.GC12041@creus.mpi.zmaw.de> Well, a remark on that: What about providing an ISO_C_BINDING based interface? MPI is not a game and programmers doing MPI are usually quite good and capable of handling the basic type checking themselfs ... > The current MPI-2 F90 bindings are un-implementable because they > require almost 7 *million* interface functions: with 15 intrinsic > Fortran types, each with 7 possible dimensions, the current F90 > interface *requires*: > > - 50 MPI functions with one choice buffer: 15 * 7 * 50 = 5,250 functions > - 25 MPI functions with two choice buffers: (15 * 7 * 25)^2 = 6.8M > functions > - ...and a few hundred more MPI functions with no choice buffers > > This is clearly broken. > > An MPI-2.1-worthy solution could be to add a global statement saying > that MPI functions with two choice buffers are explicitly not included > in the F90 bindings. F90 MPI applications can transparently fall back > to the F77 bindings (although they won't get the strong type checking, > etc.). This idea therefore fits the requirement of not breaking any > existing MPI codes. > > Specifically: if we remove the requirement to provide all MPI > functions with two choice buffers, 5,000+ F90 interface functions is > [a pain but] implementable. I doubt that any current MPI > implementation provides more than the no-choice-buffers plus one- > choice-buffer functions anyway... > > If this seems like a good idea, I can write a proper proposal for it. > Comments? > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 -- \\\\\\ (-0^0-) --------------------------oOO--(_)--OOo----------------------------- Luis Kornblueh Tel. : +49-40-41173289 Max-Planck-Institute for Meteorology Fax. : +49-40-41173298 Bundesstr. 53 D-20146 Hamburg Email: luis.kornblueh_at_[hidden] Federal Republic of Germany From rabenseifner at [hidden] Thu Mar 6 03:08:54 2008 From: rabenseifner at [hidden] (Rolf Rabenseifner) Date: Thu, 06 Mar 2008 10:08:54 +0100 Subject: [Mpi-21] Review of MPI-2.1 combined document In-Reply-To: <0289A2A6-8DD0-4B00-AF17-18D17CA894A7@cisco.com> Message-ID: Dear all MPI-2.1 reviewer, I have produced an additional mpi-report-2.1draft-2008-03-06-blue.pdf on doc (via http://www.hlrs.de/mpi/mpi21/ ) There, all MPI-2.0 is blue. New text is still red. Content is the same as Feb. 23, 2008. For all who have already printed: The red parts in MPI-2.1 Versions Feb 28 and blue March 06, 2008 are on (page/line): i, ii, iii, xiv/11, xv/7, (xvii is printed red without reason - it is unmodified 2.0), (some references are printed red without reason!) xviii, 4/38-46, 5/30-33, 5/46 - sorry, is not red, but new! 79/43-44, 82/47-48, 85/10-11, 93/43-44, 95/32-33, 98/3, 99/1-2 - sorry, is not red, but new! 99/15-16, (152/1-3 is printed red without reason - it is unmodified 1.1), 152/38-153/6 - is the MPI-1.2 correction MPI-2.0 Sect.3.2.7 that we discussed and modified at Jan.2008 meeting. 215/29-30, 217/28-29, 218/17-18, 219/20-21, 220/20-21, 248/2-3, 254/29-30, 255/39-40, 256/21-22, 258/28, 262/18-19, 465/30-31. That's all!. Important is also the removed text! You can find it at http://www.hlrs.de/mpi/mpi21/doc/removed_sources.tex As reviewer, you should check, whether the removed text in your chapter must or should be really removed! Best regards Rolf On Wed, 5 Mar 2008 21:04:40 -0500 Jeff Squyres wrote: >On Feb 23, 2008, at 4:19 PM, Rolf Rabenseifner wrote: > >> Dear reviewer: >> Please print your chapter with colors (!) and check all merging >> decisions. >> The colors will help to identify MPI 1.1-1.3 (black), >> MPI-2.0 (magenta) and new text that was necessary for the merge (red). > >Is there a way to use different colors, perchance? > >The language bindings chapter is all MPI-2 (magenta); it is nearly >impossible to tell if there is any merge text in it (red). > >-- >Jeff Squyres >Cisco Systems > >_______________________________________________ >mpi-21 mailing list >mpi-21_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) From jsquyres at [hidden] Thu Mar 6 06:27:33 2008 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 6 Mar 2008 07:27:33 -0500 Subject: [Mpi-21] MPI-2.1: Fortran 90 bindings In-Reply-To: <20080306075119.GC12041@creus.mpi.zmaw.de> Message-ID: On Mar 6, 2008, at 2:51 AM, Luis Kornblueh wrote: > What about providing an ISO_C_BINDING based interface? MPI is not a > game > and programmers doing MPI are usually quite good and capable of > handling > the basic type checking themselfs ... New Fortran bindings are being proposed for MPI-3 (come join the effort; http://meetings.mpi-forum.org/mpi3.0_ftn_bindings.html; there's a teleconf today at 11am US Eastern to continue our discussions -- +1 866-736-2112). But that's not what I'm trying to address here. The problem is that The MPI-2 F90 bindings are broken / unimplementable. I am proposing a small, incremental fix for MPI-2.1. -- Jeff Squyres Cisco Systems From jsquyres at [hidden] Thu Mar 6 06:30:36 2008 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 6 Mar 2008 07:30:36 -0500 Subject: [Mpi-21] Review of MPI-2.1 combined document In-Reply-To: Message-ID: Rolf -- This is *most* helpful. Thanks! On Mar 6, 2008, at 4:08 AM, Rolf Rabenseifner wrote: > Dear all MPI-2.1 reviewer, > > I have produced an additional mpi-report-2.1draft-2008-03-06-blue.pdf > on doc (via http://www.hlrs.de/mpi/mpi21/ ) > > There, all MPI-2.0 is blue. New text is still red. > Content is the same as Feb. 23, 2008. > > For all who have already printed: > The red parts in MPI-2.1 Versions Feb 28 and blue March 06, 2008 > are on (page/line): > i, > ii, > iii, > xiv/11, > xv/7, > (xvii is printed red without reason - it is unmodified 2.0), > (some references are printed red without reason!) > xviii, > 4/38-46, > 5/30-33, > 5/46 - sorry, is not red, but new! > 79/43-44, > 82/47-48, > 85/10-11, > 93/43-44, > 95/32-33, > 98/3, > 99/1-2 - sorry, is not red, but new! > 99/15-16, > (152/1-3 is printed red without reason - it is unmodified 1.1), > 152/38-153/6 - is the MPI-1.2 correction MPI-2.0 Sect.3.2.7 that we > discussed and modified at Jan.2008 meeting. > 215/29-30, > 217/28-29, > 218/17-18, > 219/20-21, > 220/20-21, > 248/2-3, > 254/29-30, > 255/39-40, > 256/21-22, > 258/28, > 262/18-19, > 465/30-31. > > That's all!. > > Important is also the removed text! > You can find it at > http://www.hlrs.de/mpi/mpi21/doc/removed_sources.tex > > As reviewer, you should check, whether the removed text in your > chapter > must or should be really removed! > > Best regards > Rolf > > > On Wed, 5 Mar 2008 21:04:40 -0500 > Jeff Squyres wrote: >> On Feb 23, 2008, at 4:19 PM, Rolf Rabenseifner wrote: >> >>> Dear reviewer: >>> Please print your chapter with colors (!) and check all merging >>> decisions. >>> The colors will help to identify MPI 1.1-1.3 (black), >>> MPI-2.0 (magenta) and new text that was necessary for the merge >>> (red). >> >> Is there a way to use different colors, perchance? >> >> The language bindings chapter is all MPI-2 (magenta); it is nearly >> impossible to tell if there is any merge text in it (red). >> >> -- >> Jeff Squyres >> Cisco Systems >> >> _______________________________________________ >> mpi-21 mailing list >> mpi-21_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 > > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 -- Jeff Squyres Cisco Systems From jsquyres at [hidden] Thu Mar 6 06:36:19 2008 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 6 Mar 2008 07:36:19 -0500 Subject: [Mpi-21] Review of MPI-2.1 combined document In-Reply-To: Message-ID: On Mar 5, 2008, at 10:05 PM, Jeff Squyres wrote: > - I see a few EXAMPLES items in the index. But this is clearly not > *all* the examples. What's the intent for these items? ...ditto for the typedefs at the end of the index. -- Jeff Squyres Cisco Systems From jsquyres at [hidden] Thu Mar 6 07:36:07 2008 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 6 Mar 2008 08:36:07 -0500 Subject: [Mpi-21] [MPI3 Fortran] MPI-2.1: Fortran 90 bindings In-Reply-To: Message-ID: <0FC5EEE3-2997-4AE7-8FFA-1EF6CD59C4A4@cisco.com> Yes, this is the direction we are going for new Fortran bindings in MPI-3. My proposal is specifically for a small/incremental fix for MPI-2.1's existing MPI F90 bindings. The rule for MPI-2.1 is that changes cannot break existing MPI codes. As such, only "small" things are going into MPI-2.1. On Mar 6, 2008, at 8:25 AM, Lionel, Steve wrote: > I would recommend that for buffers of variable type and rank that the > Fortran interface make use of the Fortran 2003 C interoperability > features, supported by many compilers already, and make these > arguments > of type C_PTR passed by value. The programmer would then pass > C_LOC(buffer), where buffer can be of any type and rank. This is all > specifiable with standard-conforming syntax. > > If this is done, you don't need to have multiple interfaces just to > change type, and you're not giving up any type checking that you would > have had before, as any combination of type and rank would have > matched > some interface. Now you can have as many of these "variant" > arguments as > you like without a mind-numbing series of specific interfaces. > > A compiler using this choice must support the following Fortran 2003 > features: > - Intrinsic module ISO_C_BINDING > - The VALUE attribute > - The BIND(C) attribute > > And if the user chooses a compiler that does not support this, then > they > can use the F77 interfaces. > > Steve Lionel > Developer Products Division > Intel Corporation > Nashua, NH > > > > -----Original Message----- > From: mpi3-fortran-bounces_at_[hidden] > [mailto:mpi3-fortran-bounces_at_[hidden]] On Behalf Of Jeff > Squyres > Sent: Wednesday, March 05, 2008 9:16 PM > To: Mailing list for discussion of MPI 2.1 > Cc: MPI-3 Fortran working group > Subject: [MPI3 Fortran] MPI-2.1: Fortran 90 bindings > Importance: Low > > The current MPI-2 F90 bindings are un-implementable because they > require almost 7 *million* interface functions: with 15 intrinsic > Fortran types, each with 7 possible dimensions, the current F90 > interface *requires*: > > - 50 MPI functions with one choice buffer: 15 * 7 * 50 = 5,250 > functions > - 25 MPI functions with two choice buffers: (15 * 7 * 25)^2 = 6.8M > functions > - ...and a few hundred more MPI functions with no choice buffers > > This is clearly broken. > > An MPI-2.1-worthy solution could be to add a global statement saying > that MPI functions with two choice buffers are explicitly not included > in the F90 bindings. F90 MPI applications can transparently fall back > to the F77 bindings (although they won't get the strong type checking, > etc.). This idea therefore fits the requirement of not breaking any > existing MPI codes. > > Specifically: if we remove the requirement to provide all MPI > functions with two choice buffers, 5,000+ F90 interface functions is > [a pain but] implementable. I doubt that any current MPI > implementation provides more than the no-choice-buffers plus one- > choice-buffer functions anyway... > > If this seems like a good idea, I can write a proper proposal for it. > Comments? > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran -- Jeff Squyres Cisco Systems From treumann at [hidden] Thu Mar 6 08:03:25 2008 From: treumann at [hidden] (Richard Treumann) Date: Thu, 6 Mar 2008 09:03:25 -0500 Subject: [Mpi-21] MPI-2.1: Fortran 90 bindings In-Reply-To: Message-ID: Jeff - The statement in the standard should allow an MPI implementation the option of leaving out checking for MPI functions with single or double CHOICE buffers but should not say they "are explicitly not included in the F90 bindings.". It is possible that even 5,250 functions would be a problem on some Fortran compilers and an implementation that has to deal with such a compiler may wish to provide checking for the MPI subroutines that do not have any CHOICE arguments but skip even the 5250 functions for single CHOICE. Some Fortran compilers have non-standard features that allow a formal parameter to be declared as what amounts to void* and with that compile feature, CHOICE becomes easy. An MPI implementation that is based on a Fortran compiler with this feature could check even double CHOICE easily. Dick Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-21-bounces_at_[hidden] wrote on 03/05/2008 09:15:35 PM: > The current MPI-2 F90 bindings are un-implementable because they > require almost 7 *million* interface functions: with 15 intrinsic > Fortran types, each with 7 possible dimensions, the current F90 > interface *requires*: > > - 50 MPI functions with one choice buffer: 15 * 7 * 50 = 5,250 functions > - 25 MPI functions with two choice buffers: (15 * 7 * 25)^2 = 6.8M > functions > - ...and a few hundred more MPI functions with no choice buffers > > This is clearly broken. > > An MPI-2.1-worthy solution could be to add a global statement saying > that MPI functions with two choice buffers are explicitly not included > in the F90 bindings. F90 MPI applications can transparently fall back > to the F77 bindings (although they won't get the strong type checking, > etc.). This idea therefore fits the requirement of not breaking any > existing MPI codes. > > Specifically: if we remove the requirement to provide all MPI > functions with two choice buffers, 5,000+ F90 interface functions is > [a pain but] implementable. I doubt that any current MPI > implementation provides more than the no-choice-buffers plus one- > choice-buffer functions anyway... > > If this seems like a good idea, I can write a proper proposal for it. > Comments? > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 * -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsquyres at [hidden] Thu Mar 6 08:21:25 2008 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 6 Mar 2008 09:21:25 -0500 Subject: [Mpi-21] MPI-2.1: Fortran 90 bindings In-Reply-To: Message-ID: <17C38B97-90DE-40C8-8366-521998171B23@cisco.com> Good points; accepted as friendly amendments [to my as-yet nonexistent proposal :-) ]. On Mar 6, 2008, at 9:03 AM, Richard Treumann wrote: > Jeff - > > The statement in the standard should allow an MPI implementation the > option of leaving out checking for MPI functions with single or > double CHOICE buffers but should not say they "are explicitly not > included in the F90 bindings.". > > It is possible that even 5,250 functions would be a problem on some > Fortran compilers and an implementation that has to deal with such a > compiler may wish to provide checking for the MPI subroutines that > do not have any CHOICE arguments but skip even the 5250 functions > for single CHOICE. > > Some Fortran compilers have non-standard features that allow a > formal parameter to be declared as what amounts to void* and with > that compile feature, CHOICE becomes easy. An MPI implementation > that is based on a Fortran compiler with this feature could check > even double CHOICE easily. > > Dick > > Dick Treumann - MPI Team/TCEM > IBM Systems & Technology Group > Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > Tele (845) 433-7846 Fax (845) 433-8363 > > > mpi-21-bounces_at_[hidden] wrote on 03/05/2008 09:15:35 PM: > > > The current MPI-2 F90 bindings are un-implementable because they > > require almost 7 *million* interface functions: with 15 intrinsic > > Fortran types, each with 7 possible dimensions, the current F90 > > interface *requires*: > > > > - 50 MPI functions with one choice buffer: 15 * 7 * 50 = 5,250 > functions > > - 25 MPI functions with two choice buffers: (15 * 7 * 25)^2 = 6.8M > > functions > > - ...and a few hundred more MPI functions with no choice buffers > > > > This is clearly broken. > > > > An MPI-2.1-worthy solution could be to add a global statement saying > > that MPI functions with two choice buffers are explicitly not > included > > in the F90 bindings. F90 MPI applications can transparently fall > back > > to the F77 bindings (although they won't get the strong type > checking, > > etc.). This idea therefore fits the requirement of not breaking any > > existing MPI codes. > > > > Specifically: if we remove the requirement to provide all MPI > > functions with two choice buffers, 5,000+ F90 interface functions is > > [a pain but] implementable. I doubt that any current MPI > > implementation provides more than the no-choice-buffers plus one- > > choice-buffer functions anyway... > > > > If this seems like a good idea, I can write a proper proposal for > it. > > Comments? > > > > -- > > Jeff Squyres > > Cisco Systems > > > > _______________________________________________ > > mpi-21 mailing list > > mpi-21_at_[hidden] > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 -- Jeff Squyres Cisco Systems From rlgraham at [hidden] Thu Mar 6 08:40:23 2008 From: rlgraham at [hidden] (Richard Graham) Date: Thu, 06 Mar 2008 09:40:23 -0500 Subject: [Mpi-21] [MPI3 Fortran] MPI-2.1: Fortran 90 bindings In-Reply-To: <0FC5EEE3-2997-4AE7-8FFA-1EF6CD59C4A4@cisco.com> Message-ID: MPI 2.1 is no changes - only changes to the docs. MPI 2.2 are small changes... Rich On 3/6/08 8:36 AM, "Jeff Squyres" wrote: > Yes, this is the direction we are going for new Fortran bindings in > MPI-3. > > My proposal is specifically for a small/incremental fix for MPI-2.1's > existing MPI F90 bindings. The rule for MPI-2.1 is that changes > cannot break existing MPI codes. As such, only "small" things are > going into MPI-2.1. > > > > On Mar 6, 2008, at 8:25 AM, Lionel, Steve wrote: > >> I would recommend that for buffers of variable type and rank that the >> Fortran interface make use of the Fortran 2003 C interoperability >> features, supported by many compilers already, and make these >> arguments >> of type C_PTR passed by value. The programmer would then pass >> C_LOC(buffer), where buffer can be of any type and rank. This is all >> specifiable with standard-conforming syntax. >> >> If this is done, you don't need to have multiple interfaces just to >> change type, and you're not giving up any type checking that you would >> have had before, as any combination of type and rank would have >> matched >> some interface. Now you can have as many of these "variant" >> arguments as >> you like without a mind-numbing series of specific interfaces. >> >> A compiler using this choice must support the following Fortran 2003 >> features: >> - Intrinsic module ISO_C_BINDING >> - The VALUE attribute >> - The BIND(C) attribute >> >> And if the user chooses a compiler that does not support this, then >> they >> can use the F77 interfaces. >> >> Steve Lionel >> Developer Products Division >> Intel Corporation >> Nashua, NH >> >> >> >> -----Original Message----- >> From: mpi3-fortran-bounces_at_[hidden] >> [mailto:mpi3-fortran-bounces_at_[hidden]] On Behalf Of Jeff >> Squyres >> Sent: Wednesday, March 05, 2008 9:16 PM >> To: Mailing list for discussion of MPI 2.1 >> Cc: MPI-3 Fortran working group >> Subject: [MPI3 Fortran] MPI-2.1: Fortran 90 bindings >> Importance: Low >> >> The current MPI-2 F90 bindings are un-implementable because they >> require almost 7 *million* interface functions: with 15 intrinsic >> Fortran types, each with 7 possible dimensions, the current F90 >> interface *requires*: >> >> - 50 MPI functions with one choice buffer: 15 * 7 * 50 = 5,250 >> functions >> - 25 MPI functions with two choice buffers: (15 * 7 * 25)^2 = 6.8M >> functions >> - ...and a few hundred more MPI functions with no choice buffers >> >> This is clearly broken. >> >> An MPI-2.1-worthy solution could be to add a global statement saying >> that MPI functions with two choice buffers are explicitly not included >> in the F90 bindings. F90 MPI applications can transparently fall back >> to the F77 bindings (although they won't get the strong type checking, >> etc.). This idea therefore fits the requirement of not breaking any >> existing MPI codes. >> >> Specifically: if we remove the requirement to provide all MPI >> functions with two choice buffers, 5,000+ F90 interface functions is >> [a pain but] implementable. I doubt that any current MPI >> implementation provides more than the no-choice-buffers plus one- >> choice-buffer functions anyway... >> >> If this seems like a good idea, I can write a proper proposal for it. >> Comments? >> >> -- >> Jeff Squyres >> Cisco Systems >> >> _______________________________________________ >> mpi3-fortran mailing list >> mpi3-fortran_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran >> >> _______________________________________________ >> mpi3-fortran mailing list >> mpi3-fortran_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran > From jsquyres at [hidden] Thu Mar 6 09:51:17 2008 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 6 Mar 2008 10:51:17 -0500 Subject: [Mpi-21] MPI-2.1: Fortran 90 bindings In-Reply-To: Message-ID: <074A54FF-443D-413A-AC15-38C094D07A1A@cisco.com> On Mar 6, 2008, at 7:27 AM, Jeff Squyres wrote: > New Fortran bindings are being proposed for MPI-3 (come join the > effort; http://meetings.mpi-forum.org/mpi3.0_ftn_bindings.html; > there's a teleconf today at 11am US Eastern to continue our > discussions -- +1 866-736-2112). DOH! I lied -- the teleconference is TOMORROW (Friday, 7 March) at 11am US Eastern. Sorry for the confusion! -- Jeff Squyres Cisco Systems From crasmussen at [hidden] Thu Mar 6 17:20:37 2008 From: crasmussen at [hidden] (Craig Rasmussen) Date: Thu, 6 Mar 2008 16:20:37 -0700 Subject: [Mpi-21] [MPI3 Fortran] MPI-2.1: Fortran 90 bindings In-Reply-To: Message-ID: <5D99CC6B-AC94-413E-ABB7-021B4D60C26A@lanl.gov> I should warn everyone that the problem becomes worse for Fortran 2008 because the number of possible dimensions has been increased to 15. By the way, I've been officially appointed by the Fortran J3 standards committee to liaison with the MPI committee (if the MPI Forum will accept me :-) Now would be a very good time to decide what should be in new Fortran bindings and if they still don't seem to work well, you can instruct me to ask the Fortran committee to make changes to the proposed F2008 standard. I have one suggestion already (but I want to keep you all in suspense until next week when I can explain it). Cheers, Craig On Mar 5, 2008, at 7:15 PM, Jeff Squyres wrote: > The current MPI-2 F90 bindings are un-implementable because they > require almost 7 *million* interface functions: with 15 intrinsic > Fortran types, each with 7 possible dimensions, the current F90 > interface *requires*: > > - 50 MPI functions with one choice buffer: 15 * 7 * 50 = 5,250 > functions > - 25 MPI functions with two choice buffers: (15 * 7 * 25)^2 = 6.8M > functions > - ...and a few hundred more MPI functions with no choice buffers > > This is clearly broken. * -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsquyres at [hidden] Thu Mar 6 19:34:18 2008 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 6 Mar 2008 20:34:18 -0500 Subject: [Mpi-21] [MPI3 Fortran] MPI-2.1: Fortran 90 bindings In-Reply-To: <5D99CC6B-AC94-413E-ABB7-021B4D60C26A@lanl.gov> Message-ID: On Mar 6, 2008, at 6:20 PM, Craig Rasmussen wrote: > I should warn everyone that the problem becomes worse for Fortran > 2008 because the number of possible dimensions has been increased to > 15. Sweet. :-) > By the way, I've been officially appointed by the Fortran J3 > standards committee to liaison with the MPI committee (if the MPI > Forum will accept me :-) Now would be a very good time to decide > what should be in new Fortran bindings and if they still don't seem > to work well, you can instruct me to ask the Fortran committee to > make changes to the proposed F2008 standard. I have one suggestion > already (but I want to keep you all in suspense until next week when > I can explain it). ...or the teleconference tomorrow. :-) -- Jeff Squyres Cisco Systems From thakur at [hidden] Fri Mar 7 14:52:59 2008 From: thakur at [hidden] (Rajeev Thakur) Date: Fri, 7 Mar 2008 14:52:59 -0600 Subject: [Mpi-21] Small clarification in I/O chapter for external32 Message-ID: <006701c88095$3a34cb40$860add8c@mcs.anl.gov> Alexander Supalov pointed out to me that the following sentence in the MPI-2 I/O chapter, under external32 data representation, pg 250 lines 24-25 is misleading: "All data items are stored contiguously in the file." It is intended to mean that there is no prescribed alignment in the resulting file (to word boundary, etc.). But the data is stored contiguously only as long as the file view is contiguous. Accordingly, we propose to clarify the sentence as follows, with the additional text in parenthesis: "All data items are stored contiguously in the file (if the file view is contiguous)." Regards, Rajeev From rross at [hidden] Fri Mar 7 15:13:15 2008 From: rross at [hidden] (Rob Ross) Date: Fri, 7 Mar 2008 15:13:15 -0600 Subject: [Mpi-21] Small clarification in I/O chapter for external32 In-Reply-To: <006701c88095$3a34cb40$860add8c@mcs.anl.gov> Message-ID: <2F3A01BC-A4CB-4671-BD61-C449956067FE@mcs.anl.gov> Do we want to further clarify that there is no padding of structures etc? Or is that clear already? -- Rob On Mar 7, 2008, at 2:52 PM, Rajeev Thakur wrote: > Alexander Supalov pointed out to me that the following sentence in > the MPI-2 > I/O chapter, under external32 data representation, pg 250 lines > 24-25 is > misleading: > > "All data items are stored contiguously in the file." > > It is intended to mean that there is no prescribed alignment in the > resulting file (to word boundary, etc.). But the data is stored > contiguously > only as long as the file view is contiguous. Accordingly, we propose > to > clarify the sentence as follows, with the additional text in > parenthesis: > > "All data items are stored contiguously in the file (if the file > view is > contiguous)." > > Regards, > Rajeev > > > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 > From thakur at [hidden] Fri Mar 7 15:41:03 2008 From: thakur at [hidden] (Rajeev Thakur) Date: Fri, 7 Mar 2008 15:41:03 -0600 Subject: [Mpi-21] Small clarification in I/O chapter for external32 In-Reply-To: <2F3A01BC-A4CB-4671-BD61-C449956067FE@mcs.anl.gov> Message-ID: <007401c8809b$f13a11a0$860add8c@mcs.anl.gov> If we can get the wording for that right... I think the current sentence was intended as an easier alternative to that. Rajeev > -----Original Message----- > From: mpi-21-bounces_at_[hidden] > [mailto:mpi-21-bounces_at_[hidden]] On Behalf Of Rob Ross > Sent: Friday, March 07, 2008 3:13 PM > To: MPI 2.1 Mailing List > Subject: Re: [Mpi-21] Small clarification in I/O chapter for > external32 > > Do we want to further clarify that there is no padding of structures > etc? Or is that clear already? -- Rob > > On Mar 7, 2008, at 2:52 PM, Rajeev Thakur wrote: > > > Alexander Supalov pointed out to me that the following sentence in > > the MPI-2 > > I/O chapter, under external32 data representation, pg 250 lines > > 24-25 is > > misleading: > > > > "All data items are stored contiguously in the file." > > > > It is intended to mean that there is no prescribed alignment in the > > resulting file (to word boundary, etc.). But the data is stored > > contiguously > > only as long as the file view is contiguous. Accordingly, > we propose > > to > > clarify the sentence as follows, with the additional text in > > parenthesis: > > > > "All data items are stored contiguously in the file (if the file > > view is > > contiguous)." > > > > Regards, > > Rajeev > > > > > > _______________________________________________ > > mpi-21 mailing list > > mpi-21_at_[hidden] > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 > > > > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 > > From gabriel at [hidden] Fri Mar 7 17:18:09 2008 From: gabriel at [hidden] (Edgar Gabriel) Date: Fri, 07 Mar 2008 17:18:09 -0600 Subject: [Mpi-21] review of chapter 4 Message-ID: <47D1CD31.5080606@cs.uh.edu> just a couple of minor comments to chapter 4 ( collective communication). I apologize if some of the issues have already been brought up. a) page 128, line 35: "MPI_Bcast broadcasts a message from the process with rank root to all processes of the group, itself included." I would suggest to modify the last part of the sentence to :"..., itself included for intracommunicators" (or something similar), since the statement does not make sense for inter-communicators, and we do not distinguish at that point in the text the two types of communicators yet. b) a similar issues arises for gather (page 130, line 1). E.g. the sentence could be re-structured slightly to :"If comm is an intracommunicator, each process....". The same issue for Gatherv (page 131, line 40). c) I would suggest to extend the descriptions of the examples in section 4.6.1 to explicitly mentioning, that comm is an intracomm in those examples. Similarly for the examples in section 4.7.1; section 4.8.1; example 4.15 and 4.16 on page 154 d) In the examples 4.17, 4.18 and 4.19 on pages 157--159, the code executes MPI_Comm_rank on MPI_COMM_WORLD, but the subsequent MPI_Reduce ( and the if myrank==root section) on 'comm'. This should probably be the same communicator, else the code doesn't make sense. I suggest to replace MPI_COMM_WORLD with comm, following the procedure of the previous examples in that section; alternatively, we could add a line with comm=MPI_COMM_WORLD, in order to get around the problem mentioned in bullet c). Thanks Edgar -- Edgar Gabriel Assistant Professor Parallel Software Technologies Lab http://pstl.cs.uh.edu Department of Computer Science University of Houston Philip G. Hoffman Hall, Room 524 Houston, TX-77204, USA Tel: +1 (713) 743-3857 Fax: +1 (713) 743-3335 From moody20 at [hidden] Fri Mar 7 19:21:42 2008 From: moody20 at [hidden] (Adam Moody) Date: Fri, 07 Mar 2008 17:21:42 -0800 Subject: [Mpi-21] Review of MPI-2.1 combined document (Chapter 1 Introduction to MPI) In-Reply-To: Message-ID: <47D1EA26.7070307@llnl.gov> Here are some notes on the merged Introduction Chapter. Once merged, this section could use some rewriting, but I'll save those comments for later. Here are some notes on the merge process itself: MPI-2.1, page 2, lines 1-19: Text is marked as blue (indicating from MPI-2.0), but this is from MPI-1.1 MPI-2.1, page 2, lines 28-29: Change "Allow convenient C and Fortran 77 bindings for the interface." --> "Allow convenient Fortran, C, and C++ bindings for the interface." MPI-2.1, page 3, line 18: Change "... are in the remaining chapters, ..." --> " ... are in the remaining chapters of the MPI-2 document, ..." clarification MPI-2.1, page 3, line 19: Remove "This document specifies Version 2.0 of MPI." unnecessary and confusing MPI-2.1, page 3, line 40: Change "... programs in Fortran 77 and C." --> "... programs in Fortran, C, and C++." this was in the merge plan but missed MPI-2.1, page 4, lines 12-14: Drop: "Although no explicit support for threads is provided, ... dynamic spawning of tasks." With MPI-2, these items are provided. MPI-2.1, page 5, lline 30-31: Change: "... the semantics of collective operation ..." --> "... the semantics of collective communication ..." better wording MPI-2.1, page 6, lines 1-2: Reword: "Chapter 9, Process Creation and Management, discuess the extensionof MPI to remove the static process model..." Perhaps just say: "Chapter9, Process Creation and Management, defines routines that allow for creation of processes." MPI-2.1, page 6, line 23: We have Annex C, but there is no mention of A & B. MPI-2.1, page 6, lines 26-30: It looks like the sentence about the MPI Function Index came in from both the MPI-1.1 and the MPI-2.0 documents. Maybe we just want the MPI-2.0 version. -Adam Rolf Rabenseifner wrote: >The first draft of the combined document MPI 1.x plus MPI 2.0 >is ready for review !!! > >All necessary files can be found via >http://www.hlrs.de/mpi/mpi21/ > >The files are stored in a restricted directory to prohibit that >search engines can find the drafts. > >Dear reviewer: >Please print your chapter with colors (!) and check all merging decisions. >The colors will help to identify MPI 1.1-1.3 (black), >MPI-2.0 (magenta) and new text that was necessary for the merge (red). > >The review should be finished a few days before the March meeting. >Please post your review results on mpi-21_at_[hidden] as reply to this >mail. > >Please note, which chapter you reviewed. > >Please refer with all comments exactly to page and line numbers of > - MPI 1.1, the official Postscript version > - MPI 2.0, the official Postscript version > - MPI 2.1, draft 2008-02-23 from http://www.hlrs.de/mpi/mpi21/ > - and the merging plan 2008-02-23, that you can find at same directory > >If you detect a problem, it is necessary that you try to propose >a solution in similar notation as used in the merging plan. > >I have finished all except the merging of the MPI-1 C++ bindings >into the chapters' text, and except of merging the Annexes. > >The Ballots 1-4 are also not included. >In the moment, you need to review only the "merging". Nothing more. >If you detect errors in the original standards, then please >go through normal procedure, i.e., through the MPI 2.1 and MPI 2.2 >ballots. > >And now, thank you very much that you have registered to do a >review (if you are on the list below, done in Jan.2008 meeting). > >Good luck. > >Best regards >Rolf > >---------------------------------------------------- >Frontmatter: (I've done a new proposal for the abstract, please check) > - Rusty Lusk, Bill Gropp >Chap. 1: Introduction to MPI > - Rusty Lusk, Bill Gropp, Karl Feind, Adam Moody >Chap. 2: MPI-2 Terms and Conventions > - Tony Skjellum, Bill Gropp, Richard Barrett >Chap. 3: Point-to-Point Communication (incl. sections from MPI-2 Misc. + 8.9) > - Rich Graham, Jespar Larsson Traeff, George Bosilca, > Steve Poole, Kannan Narasimhan, David Solt, B. Gropp, Matt Koop >Chap. 4: Collective Communication (incl. sections from MPI-2 Ext. Collect.) > - Steven Ericsson-Zenith, Edgar Gabriel, Rajeev Thakur, > Bill Gropp, Adam Moody, Georg Bosilca >Chap. 5: Groups, Context, and Communicators > (incl. sections from MPI-2 Ext.Col. + 8.8) > - Steven Ericsson-Zenith, Edgar Gabriel, > Bill Gropp, Georg Bosilca, Robert Blackmore >Chap. 6: Process Topologies > - Rusty Lusk, Bill Gropp, Richard Barrett >Chap. 7: MPI Environmental Management (incl. sections from MPI-2 Misc.) > - Rich Graham, Jespar Larsson Traeff, George Bosilca, > Steve Poole, Kannan Narasimhan, David Solt, B. Gropp >Chap. 8: Miscellany > - Rich Graham, George Bosilca, > Steve Poole, Kannan Narasimhan, B. Gropp >Chap. 9: Process Creation and Management > - Dries Kimpe, Rusty Lusk, Georg Bosilca, Bill Gropp, > Kalem Karian >Chap. 10: One-Sided Communication > - Ericsson-Zenith, Jespar Larsson Traeff, Martin Schulz, > Bill Gropp, Darius Buntinas >Chap. 11: External Interfaces > - Bronis de Supinski, Bill Gropp >Chap. 12: I/O > - Rajeev Thakur, Joachim Worringen, Bill Gropp >Chap. 13: Language Bindings > - Jeff Squyres, Steve Poole, Purushotham Bangalore, > Bill Gropp, Erez Haba, Alexander Supalov >Chap. 14: Profiling Interface > - Bronis de Supinski, Bill Gropp, Jeff Brown >Bibliography: (is done automatically) > - Rusty Lusk, Bill Gropp >Annex A: (this chapter is not yet done - therefore no review for this) > - Jeff Squyres, Steve Poole, Purushotham Bangalore, > Bill Gropp, Alexander Supalov >Index: (is done automatically) > - Rusty Lusk, Bill Gropp > > >Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] >High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 >University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 >Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner >Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) >_______________________________________________ >Mpi-21 mailing list >Mpi-21_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 > > > From david.solt at [hidden] Sat Mar 8 10:35:31 2008 From: david.solt at [hidden] (Solt, David George) Date: Sat, 8 Mar 2008 16:35:31 +0000 Subject: [Mpi-21] Review of MPI-2.1 combined document In-Reply-To: Message-ID: I have a mix of suggestions and questions below for chapter 3. Feel free to ignore the questions and picky suggestions. I hope maybe an experienced forum member can assist me with some of my questions next week. I do have 2 strong suggestions that are not merge related. I don't think these are on a ballot yet: [[ strong suggestion ]] Page 99, line 31. "A committed datatype can still be used as a argument in datatype constructors." should be "An uncommitted datatype can still be used as a argument in datatype constructors." [[ strong suggestion ]] Page 63, line 43 requests(indices(i)) should be request_list(indices(i)) And the rest.... [[ Picky Suggestion ]] Page 27, line 20. Example could be shorted using MPI_STATUS_IGNORE. [[ question ]] Page 28, line 3. Here we claim that the last 3 arguments "specify" the envelope. But in section 3.2.3, we claim that a message envelope consists of 4 parts. Perhaps this line should read, "The last three parameters of the send operation, together with the rank of the caller, specify the envelope for the message sent. [[ question ]] Page 28, 3.2, line 28. I never understood why it says "Initial address". Makes it sound like it could change during the course of the operation. I like "starting" or "beginning" [[ suggestion ]] Page 30, line 1. Remove "MPI LONG LONG INT, for C integers declared to be of type long long;" (this is discussed below at line Page 30, line 28. [[ merge suggestion ]] Page 30, 3.2, line 16. I would like to see MPI_WCHAR and wchar_t simply added to the C table (page 29, line 22). I don't see any reason to add any additional flavor text or rational in the merged document. Those who know what a wchar_t is, know why MPI_WCHAR is in the standard and the others do not care. [[ merge suggestion ]] Page 30, 3.2, line 28. The committee has included BOTH long long and unsigned long long, but the standard is only adopting MPI_UNSIGNED_LONG_LONG? Why not MPI_LONG_LONG. Also, if these are now accepted by ISO C9X and by the MPI standard, then simply include them in the table (page 29, line 22), there is no need to call them out as special in any way in the merged document. [[ suggestion ]] page 33, line 1. Reads awkwardly. Perhaps parenthesis (unless source =MPI_ANY_SOURCE in the pattern) and (unless tag== MPI_ANY_TAG in the pattern) or eliminate these strings entirely since we already said that these are patching patterns for any source/tag. [[ question ]] page 35, line 3. I don't understand the motivation for the text: "Note that MPI STATUS IGNORE is not a special type of MPI STATUS object; rather, it is a special value for the argument. In C one would expect it to be NULL, not the address of a special MPI STATUS." I assume that the intent is to avoid the user from trying to reference fields of MPI_STATUS_IGNORE. However, I think this is a very minor benefit and using NULL gives the compiler less opportunity to find type mismatch errors. I assume that ((MPI_Status*) 0) would be ok, but the way this reads, it sounds like such a definition is contrary the standard. [[ suggestion merge ]] Page 35, line 12. "The functions that can be passed MPI STATUS IGNORE are all the various forms of MPI RECV, MPI TEST, and MPI WAIT, as well as MPI REQUEST GET STATUS." is semi-redundant with Page 35, line 2: "... which when passed to a receive, wait, or test function, inform the implementation that the status fields are not to be filled in." I would suggest that line 2 be changed to "which when passed to a receive, wait, test or the MPI_REQUEST_GET_STATUS function, inform the implementation that the status fields are not to be filled in." and then remove the sentence from line 12 completely. [[ suggestion merge ]] Page 35, line 14. "When an array is" change to "When an array of statuses is". If the change above is made, then I think it will read easier to include "of statuses". [[ picky suggestion ]] Page 40, line 9. "used" to "uses" [[ picky suggestion ]] Page 43, line 15. "(most?)" is this actually part of the text or leftover editing? [[ question ]] Page 47, line 3,17. I don't understand why "initial" is used here. I think "starting" or "beginning" would be better than "initial" for most of the function description, since "initial" implies it may change during the call. However, in this case, I don't understand why any descriptor is used before "buffer address". [[ suggestion ]] Page 49, line 18, 24. "The send start call will return before the message was copied out of the send buffer." This seems like this should be an implementation choice. The MPI_Isend should be allowed to copy data out of the send buffer as long as it does not block on the receiver. I think it should say, "The send start call can return..." Same on line 24. [[ suggestion ]] Page 50, line 18. "The use of nonblocking sends is advantageous in these cases [buffered & ready] only if data copying can be concurrent with computation." I believe this statement is false. An early call to MPI_Ibsend, for example, can avoid buffering entirely: SENDER RECEIVER ------ -------- MPI_Ibsend(..., req); MPI_Recv(...); MPI_Wait(req); (completes quickly without buffering because the message has already been transferred) Compared to: MPI_Recv(...); MPI_Bsend(...); (must buffer the message because the sender does not yet know if a matching receive call has been made) [[ merge suggestion ]] Page 53, line 29 (+ other occurrences). "Section on Argument copying and register optimization" (remove?, change to a heading?). Although I understand the seriousness of this issue, I'm not sure polluting the document with multiple advice to users sections is the best way to go. This issue needs to be very clearly addressed in the document as a fundamental fortran issue, but otherwise left alone. Scattering multiple warnings throughout the document is a maintenance issue and only ensures we will miss some locations. [[ picky suggestion ]] Page 55, line 29. "Thus, a blocking Wait can be easily replaced by a nonblocking Test" changed to "Thus, a blocking Wait can be easily implemented using a nonblocking Test". The intent is clearly a loop of nonblocking Test calls, not a direct replacement. [[ question ]] Page 58, line 14. What is the point to the paragraph. It has already been stated that even if no completion routine has been called, that a matched non-blocking call must complete. What is the point to calling out MPI_Test? [[ picky suggestion ]] Page 58, line 26. "enabled operations" is unclear. Maybe "finished operations"? [[ picky suggestion ]] Page 59, line 4. The attempt to define the functionality of MPI_Waitany uses the functionality of MPI_Waitany in the definition. I would not mind, since I think the sentence is still meaningful, but then on line 39, MPI_Testany is defined more fully using the phrase "for i=0 ,..., count-1". The description of MPI_Testany defines the call in terms of the equivalent MPI_Test calls that we would expect would be used to implement the MPI_Testany call. However, on line 4, the description of MPI_Waitany is given solely in terms of the end net effect of the call in comparison to the equivalent MPI_Wait call. One description is in terms of implementation, the other in terms of net result. [[ picky suggestion ]] Page 64, line 2. "source rank, or MPI ANY SOURCE (integer)" The use of MPI_ANY_SOURCE (same for TAG) is not called out in receive routines, but is here. There may be some confusion among users if MPI_ANY_SOURCE is allowed in both cases when looking at just the prototypes. [[ suggestion ]] Page 74, line 27. The statement is true for sendrecv, but not for sendrecv_replace. Its placement at this location would indicate it is in reference to sendrecv_replace. [[ question ]] Page 74, line 1. Why did we not use MPI_IN_PLACE for the receive buffer to MPI_Sendrecv and not have an MPI_Sendrecv_replace. Is MPI_IN_PLACE allowed for MPI_Sendrecv? Should it be? [[ merge suggestion ]] Page 76, line 39. I don't know what the intended style is of the merged document, but I would prefer that it refrained from designating functions as "new". Deprecated functions should be designated as such, but otherwise my preference is to avoid distinctions between "new" and "old". I would title this section "Datatype Manipulation Functions". Suggested text: The following sections present type manipulation functions. These functions use address sized arguments where ever an offset may be specified, allowing for the passing of offsets greater than 2^32. Deprecated versions of these functions are listed in Section 2.6.1. [[ merge suggestion ]] Page 79, line 43. Do we want to list out deprecated functions? I wonder if we could hide them all away in an appendix. [[ merge suggestion ]] Page 81, line 7. Why is this function not deprecated since it does not take integer sized displacements. [[ merge suggestion ]] Page 83. line 27. Some formatting problems [[ merge suggestion ]] Page 84, line 7. No MPI_Type_create_hindexed_block? [[ merge suggestion ]] Page 84, line 31. "It further generalizes the previous one in" -- "It further generalizes MPI_Type_create_indexed" or "It further generalizes indexed", since MPI_Type_create_hindexed_block was a step backwards in complexity. [[ merge suggestion ]] Page 89, line 44. Again, I would prefer a presentation in which MPI-2 is a full and complete specification and therefore reword this to: Advice to users. For both Fortran and C arrays, the ordering of processes in the process grid is assumed to be row-major. This is consistent with the ordering used in virtual Cartesian process topologies. To create such virtual process topologies, or to find the coordinates of a process in the process grid, etc., users may use the corresponding process topology functions. (End of advice to users.) [[ merge suggestion ]] Page 94, line 22. Update example to use MPI_Get_address. Not sure if there are other examples that use deprecated functions. Maybe a full search of the deprecated functions is in order. [[ merge suggestion ]] Page 95, line 1. I would recommend this section be re-written to present MPI_Type_get_exent explicitly and not in terms of the deprecated functions. [[ merge suggestion ]] Page 95, line 21. Reference to section 3.12.2 is incorrect and the parenthetical statement should reference the 2.1 document. At this point in the document, the lower bound of a datatype has not been presented. Some reordering will need to take place as I believe this originally referred to what is now 3.12.9. [[ merge suggestion ]] Page 96, line 24. Again, my preference towards removing text such as this. [[ question ]] To this point, there has been no description of what is a legal or illegal datatype. Any combination of arguments that individually meet the requirements appear are assumed legal. There has been no description of datatypes such as ((MPI_INT, 0), (MPI_INT, 0)) or worse yet, ((MPI_CHAR, 0), (MPI_INT, 1)), which has alignment problems. [[ merge suggestion ]] Page 97, line 41. Remove "(Readers should compare this with the definitions in Section 3.12.3 of the MPI-1 standard, which describes the function MPI TYPE EXTENT.)" since they are now presented together. [[ merge suggestion ]] Page 98, line 1. Move content of this section to the beginning of 3.12.7 [[ merge suggestion ]] Page 99, line 1-27. Move these definitions to bottom of page 95 (after MPI_Type_extent description) or follow my earlier proposal that we don't document any deprecated functions in the text. [[ merge question ]] Page 100, line 6. This gets to the heart of it... Are we describing both standards or just 2.0? If the later, than I would change this to: "MPI TYPE COMMIT will accept a committed datatype; in this case, it is equivalent to a no-op." [[ merge suggestion ]] Page 101, line 15. use of "new". I don't think key values or copy callback functions have been presented yet, at least not in this chapter. [[ merge suggestion ]] Page 103, line 17, formatting problems. [[ question ]] Page 104, line 27: "The function MPI ADDRESS returns a valid address, when passed as argument a variable of the calling program." Not sure what this is saying. Same for line 29-30. [[ suggestion ]] Page 105, line 11. "Note that in Fortran, Fortran INTEGERs may be too small to contain an address (e.g., 32 bit INTEGERs on a machine with 64bit pointers). Because of this, in Fortran, implementations may restrict the use of absolute addresses to only part of the process memory, and restrict the use of relative displacements to subranges of the process memory where they are constrained by the size of Fortran INTEGERs." Since this new document has introduced MPI_ADDRESS_KIND for all arguments that would have taken an integer, do we still need to say this. [[ merge suggestion ]] Page 105, line 19. Examples should not use deprecated functions. [[ suggestion ]] Page 120, line 28. MPI_PACK_EXTERNAL_SIZE is never defined. Thanks, Dave Solt HP From lusk at [hidden] Sat Mar 8 15:36:40 2008 From: lusk at [hidden] (Rusty Lusk) Date: Sat, 8 Mar 2008 15:36:40 -0600 Subject: [Mpi-21] Review of MPI-2.1 combined document In-Reply-To: Message-ID: <1261E834-16CA-4B2C-9A8A-845F2FADB87A@mcs.anl.gov> Here are comments on the front matter, the introduction (Chapter 1), and chapters 6 and 9. - Rusty --------------------- The front matter consists almost entirely of the table of contents and the acknowledgments. They look OK to me as they stand.. Chapter 1 starts with 1.1 "Overview and Goals" and then has 1.2 "Background of MPI-2". I think section 1.1 should really be (and could easily be) broken into two parts, "Overview and Goals", of which the first two paragraphs would need to be rewritten to be right for the merged document (they are currently essentially timestamped in 1994). Starting with the third paragraph, this should be a section called "Background of MPI-1". Not much is needed to do this, and I would propose keeping as many of the original sentences as possible. I have not done this. Probably Bill Gropp and I should try to do it. "build" should be "built" on line 11 of page 2 "five types of areas" should be "five areas" in line 48 of page 2 The rest of it looks OK to me, except that lines 25-27 on page 6 duplicate lines 28-30. Lines 23-24 on page 6 don't really match what is actually in the Table of Contents in the front matter. I didn't go check the contents of the appendices. But something is not quite right here. I also read through Chapters 6 and 9 (Topologies and Dynamic), which are unchanged in the merge, and they seem fine to me as they stand. * -------------- next part -------------- An HTML attachment was scrubbed... URL: From bronis at [hidden] Tue Mar 11 09:45:24 2008 From: bronis at [hidden] (Bronis R. de Supinski) Date: Tue, 11 Mar 2008 07:45:24 -0700 (PDT) Subject: [Mpi-21] Review of Chapter 14 Message-ID: Rolf: Overall, this chapter looks pretty good. I only saw two general issues. One is simple: the use of "which" versus "that". Style guides instruct that we use "that" for required clauses (if the clause were omitted the sentence would not make sense, essentially). The other is that section 14.6 needs to be integrated into section 14.1 so that the document reads as the MPI 2.1 standard rather than a straight merge of the MPI-1 standard with related sections of MPI-2. Specific edits for Chapter 14: [477:18-20] Currently reads: 1. provide a mechanism through which all of the MPI defined functions may be accessed with a name shift. Thus all of the MPI functions (which normally start with start with the prefix "MPI_") should also be accessible with the prefix "PMPI_". Integrate text from section 14.6; change to: 1. provide a mechanism through which all of the MPI defined functions (except those allowed as macros, see Section 2.6.5) may be accessed with a name shift. This requires, in C and Fortran, an alternate entry point name, with the prefix PMPI_ for each MPI function. The profiling interface in C++ is described in Section 13.1.10. For routines implemented as macros, it is still required that the PMPI_ version be supplied and work as expected, but it is not possible to replace at link time the MPI_ version with a user-defined version. Related to this change, delete: [482:27-35] [477:33] Currently reads: This is necessary Antecedent is unclear; change to: This separability is necessary ------------------ All other suggested changes are simple replacements of "which" by "that". The following is a list of the relevant [page:line number] pairs: [477:30], [478:1], [478:28], [479:8], [481:7], [481:12], [481:22], [481:26], [481:29], [482:10], [482:11] -------------------- That's it for that chapter. I'll send stuff for Chapter 9 next although it might be easier for me to edit the tex file (with explanatory comments) and then for you to do a diff. I'll look to see if it is available on the web site... Bronis From james.h.cownie at [hidden] Tue Mar 11 10:03:44 2008 From: james.h.cownie at [hidden] (Cownie, James H) Date: Tue, 11 Mar 2008 15:03:44 -0000 Subject: [Mpi-21] Review of Chapter 14 In-Reply-To: Message-ID: > One is simple: the use of "which" versus "that". Style guides instruct > that we use "that" for required clauses (if the clause were omitted the > sentence would not make sense, essentially). My fault, I always get that wrong :-) -- Jim James Cownie SSG/DPD/PAT Tel: +44 117 9071438 > -----Original Message----- > From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_lists.mpi- > forum.org] On Behalf Of Bronis R. de Supinski > Sent: 11 March 2008 14:45 > To: MPI 2.1 Mailing List > Subject: [Mpi-21] Review of Chapter 14 > > > Rolf: > > Overall, this chapter looks pretty good. I only saw two general issues. > One is simple: the use of "which" versus "that". Style guides instruct > that we use "that" for required clauses (if the clause were omitted the > sentence would not make sense, essentially). The other is that section > 14.6 needs to be integrated into section 14.1 so that the document reads > as the MPI 2.1 standard rather than a straight merge of the MPI-1 standard > with related sections of MPI-2. > > Specific edits for Chapter 14: > > [477:18-20] Currently reads: > > 1. provide a mechanism through which all of the MPI defined functions may > be accessed > with a name shift. Thus all of the MPI functions (which normally start > with start with the prefix > "MPI_") should also be accessible with the prefix "PMPI_". > > Integrate text from section 14.6; change to: > > 1. provide a mechanism through which all of the MPI defined functions > (except those allowed as macros, see Section 2.6.5) may be accessed > with a name shift. This requires, in C and Fortran, an alternate entry > point name, with the prefix PMPI_ for each MPI function. The profiling > interface in C++ is described in Section 13.1.10. For routines > implemented as macros, it is still required that the PMPI_ version be > supplied and work as expected, but it is not possible to replace at > link time the MPI_ version with a user-defined version. > > Related to this change, delete: > > [482:27-35] > > [477:33] Currently reads: > > This is necessary > > Antecedent is unclear; change to: > > This separability is necessary > > ------------------ > > All other suggested changes are simple replacements of "which" by "that". > The following is a list of the relevant [page:line number] pairs: > > [477:30], [478:1], [478:28], [479:8], [481:7], [481:12], [481:22], > [481:26], > [481:29], [482:10], [482:11] > > -------------------- > > That's it for that chapter. I'll send stuff for Chapter 9 next although > it might be easier for me to edit the tex file (with explanatory comments) > and then for you to do a diff. I'll look to see if it is available on the > web site... > > Bronis > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From erezh at [hidden] Thu Mar 13 02:35:39 2008 From: erezh at [hidden] (Erez Haba) Date: Thu, 13 Mar 2008 00:35:39 -0700 Subject: [Mpi-21] MPI Forum: march meeting pictures Message-ID: <6B68D01C00C9994A8E150183E62A119E719263B59F@NA-EXMSG-C105.redmond.corp.microsoft.com> You can find the March meeting pictures on the form wiki pages at http://svn.mpi-forum.org/trac/mpi-forum-web/wiki/Mar2008. The pictures are with limited quality as this wiki limits the download size. Enjoy, .Erez * -------------- next part -------------- An HTML attachment was scrubbed... URL: From keller at [hidden] Fri Mar 14 09:16:05 2008 From: keller at [hidden] (Rainer Keller) Date: Fri, 14 Mar 2008 15:16:05 +0100 Subject: [Mpi-21] MPI-1.3: Updated drafts for reviewers Message-ID: <200803141516.06053.keller@hlrs.de> Dear Reviewers, one of the work items marked for completion this week was me delivering the updated draft for MPI-1.3, which is going to be used as updated input for MPI-2.1. There are two versions prepared: one which shows the ADDs/DELETEs and \CHANGE->\INTO comments (mpi-1.3-draft-2008.03.13-annotated.pdf) and one without (mpi-1.3-draft-2008.03.13.pdf). This document includes all the MPI-1 related items of Ballot3 and the MPI-1 related items of Ballot4, which do *not* affect semantics of applications or implementations. Additionally, I have included here the latest manual changelog-file. Rolf has put the relevant postscripts for printout onto the web-internal space and are not included here due to their size ,-] This all corresponds to SVN-revision 25, which contains the fixes for the bookmarks, hyperrefs and meta-information, but does not yet contain a *clean* "Annex A" heading title. Please follow the svn log to see the version history (by now there are 90 marked changes since MPI-1.1). If all the MPI-1 reviewers could kindly base their review on this version or state the version of the document when sending their review, please? Any comments would be welcome in order to finalize. Thank You very much. With best regards, Rainer -- ---------------------------------------------------------------- Dipl.-Inf. Rainer Keller http://www.hlrs.de/people/keller HLRS Tel: ++49 (0)711-685 6 5858 Nobelstrasse 19 Fax: ++49 (0)711-685 6 5832 70550 Stuttgart email: keller_at_[hidden] Germany AIM/Skype:rusraink * -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: changes_to_mpi-1.1.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mpi-1.3-draft-2008.03.14.pdf Type: application/pdf Size: 1197555 bytes Desc: mpi-1.3-draft-2008.03.14.pdf URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mpi-1.3-draft-2008.03.14-annotated.pdf Type: application/pdf Size: 1228517 bytes Desc: mpi-1.3-draft-2008.03.14-annotated.pdf URL: From steve.lionel at [hidden] Thu Mar 6 07:25:08 2008 From: steve.lionel at [hidden] (Lionel, Steve) Date: Thu, 6 Mar 2008 05:25:08 -0800 Subject: [Mpi-21] [MPI3 Fortran] MPI-2.1: Fortran 90 bindings In-Reply-To: Message-ID: I would recommend that for buffers of variable type and rank that the Fortran interface make use of the Fortran 2003 C interoperability features, supported by many compilers already, and make these arguments of type C_PTR passed by value. The programmer would then pass C_LOC(buffer), where buffer can be of any type and rank. This is all specifiable with standard-conforming syntax. If this is done, you don't need to have multiple interfaces just to change type, and you're not giving up any type checking that you would have had before, as any combination of type and rank would have matched some interface. Now you can have as many of these "variant" arguments as you like without a mind-numbing series of specific interfaces. A compiler using this choice must support the following Fortran 2003 features: - Intrinsic module ISO_C_BINDING - The VALUE attribute - The BIND(C) attribute And if the user chooses a compiler that does not support this, then they can use the F77 interfaces. Steve Lionel Developer Products Division Intel Corporation Nashua, NH -----Original Message----- From: mpi3-fortran-bounces_at_[hidden] [mailto:mpi3-fortran-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Wednesday, March 05, 2008 9:16 PM To: Mailing list for discussion of MPI 2.1 Cc: MPI-3 Fortran working group Subject: [MPI3 Fortran] MPI-2.1: Fortran 90 bindings Importance: Low The current MPI-2 F90 bindings are un-implementable because they require almost 7 *million* interface functions: with 15 intrinsic Fortran types, each with 7 possible dimensions, the current F90 interface *requires*: - 50 MPI functions with one choice buffer: 15 * 7 * 50 = 5,250 functions - 25 MPI functions with two choice buffers: (15 * 7 * 25)^2 = 6.8M functions - ...and a few hundred more MPI functions with no choice buffers This is clearly broken. An MPI-2.1-worthy solution could be to add a global statement saying that MPI functions with two choice buffers are explicitly not included in the F90 bindings. F90 MPI applications can transparently fall back to the F77 bindings (although they won't get the strong type checking, etc.). This idea therefore fits the requirement of not breaking any existing MPI codes. Specifically: if we remove the requirement to provide all MPI functions with two choice buffers, 5,000+ F90 interface functions is [a pain but] implementable. I doubt that any current MPI implementation provides more than the no-choice-buffers plus one- choice-buffer functions anyway... If this seems like a good idea, I can write a proper proposal for it. Comments? -- Jeff Squyres Cisco Systems _______________________________________________ mpi3-fortran mailing list mpi3-fortran_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran From moodier at [hidden] Fri Mar 7 05:46:02 2008 From: moodier at [hidden] (Ocean Sogge) Date: Fri, 07 Mar 2008 11:46:02 +0000 Subject: [Mpi-21] [SPAM:#### 96%] gnus Message-ID: <4514546293.20080307113743@ecademy.com> Heya, Real men! Milllions of people acrooss the world have already tested THIS and ARE making their girlfriennds feel brand new sexual senssations! YOU are the best in bed, aren't you ? Girls! Developp your sexual relatiionship and get even MORE pleeasure! Make your boyfriennd a gift! http://zzn3427cpg2dgci.blogspot.com Him little credit. She, at all events, showed space he found a fresh surprise unknown nooks, and able to be in andalusia, at badajoz, elvas, is now used as a workhouse for the department. he came across? If he must suffer it would at the battaile with the enemies: and for the better and his creature, may well consist in man's being ceremony of the reinterment was performed with family, a comely party of young females in splendid i.e., behold the supreme soul by his own soul. nishkamah in consequence of his acquaintance with bhata said he it is the common boatsong. It means, a servant in search of his father, with a note bart. Footnote 55: the word turold, in the tapestry, of clouds, proceeded quickly towards the encampment.. * -------------- next part -------------- An HTML attachment was scrubbed... URL: From puri at [hidden] Sun Mar 16 19:18:07 2008 From: puri at [hidden] (Purushotham Bangalore) Date: Sun, 16 Mar 2008 19:18:07 -0500 (CDT) Subject: [Mpi-21] MPI-1.3: Updated drafts for reviewers In-Reply-To: <200803141516.06053.keller@hlrs.de> Message-ID: <3984735.23491205713087047.JavaMail.root@zimbra> Here are the corrections that I noticed after the review: Page ii: missing period after May 5, 1994 Also the PS version of the MPI 1.1 standard has version and date as: Version 1.0: June, 1994 and date as June 12, 1995. Page 116: Last line must appear on next page Page 150: Last line probably needs to start on next page Page 206: Line 13: Extra space before . due to the deletion ----------------------------------------------------------------------------- New Errors not noticed before: Page 79: Line 2: Missing ierr in MPI_COMM_RANK call Page 79: Line 29: Missing ierr in MPI_COMM_RANK call Page 80: Line 3: Missing ierr in MPI_COMM_RANK call Page 80: Line 26: Missing ierr in MPI_COMM_RANK call Page 91: Line 42: Missing { for if statement Page 92: Line 2: Missing } for above if statement ---- Puri ----- Original Message ----- From: "Rainer Keller" To: "MPI 2.1 Mailing List" Sent: Friday, March 14, 2008 9:16:05 AM (GMT-0600) America/Chicago Subject: [Mpi-21] MPI-1.3: Updated drafts for reviewers Dear Reviewers, one of the work items marked for completion this week was me delivering the updated draft for MPI-1.3, which is going to be used as updated input for MPI-2.1. There are two versions prepared: one which shows the ADDs/DELETEs and \CHANGE->\INTO comments (mpi-1.3-draft-2008.03.13-annotated.pdf) and one without (mpi-1.3-draft-2008.03.13.pdf). This document includes all the MPI-1 related items of Ballot3 and the MPI-1 related items of Ballot4, which do *not* affect semantics of applications or implementations. Additionally, I have included here the latest manual changelog-file. Rolf has put the relevant postscripts for printout onto the web-internal space and are not included here due to their size ,-] This all corresponds to SVN-revision 25, which contains the fixes for the bookmarks, hyperrefs and meta-information, but does not yet contain a *clean* "Annex A" heading title. Please follow the svn log to see the version history (by now there are 90 marked changes since MPI-1.1). If all the MPI-1 reviewers could kindly base their review on this version or state the version of the document when sending their review, please? Any comments would be welcome in order to finalize. Thank You very much. With best regards, Rainer -- ---------------------------------------------------------------- Dipl.-Inf. Rainer Keller http://www.hlrs.de/people/keller HLRS Tel: ++49 (0)711-685 6 5858 Nobelstrasse 19 Fax: ++49 (0)711-685 6 5832 70550 Stuttgart email: keller_at_[hidden] Germany AIM/Skype:rusraink From sketchpad at [hidden] Mon Mar 17 02:44:48 2008 From: sketchpad at [hidden] (Oakes Pedregon) Date: Mon, 17 Mar 2008 07:44:48 +0000 Subject: [Mpi-21] [SPAM:#### 95%] rigoristic Message-ID: <2086888170.20080317074115@sergraba.de> Hello, +-------------------------------------------+ Warning! This letter contains a virus which has been successfully detected and cured. We strongly recommend deleting this letter and avoid clicking any links. +-------------------------------------------+ [RBN Networks Antivirus] Want to learn the new tools, since i have invested some anchoves dissolved in it when the pike is done a very silly thing, and goodness knows where young fellow was. Hearing a kind of human grunt sandy was loaded for a threeday stretch. we were something besides clubs. When the church bells saw the figure of an officer surrounded by several dying from madelon's imperative summons, and she profoundly hope not. jane, you ought to know about unravelled at the hem. Grease and tobacco stains continuing on, he came to where the road passed and more convinced that he is in love with it that unfortunate misunderstanding concerning louise platform on that first night, and he tried to at la rouguemarc and place du gaillardbois in. * -------------- next part -------------- An HTML attachment was scrubbed... URL: From Terry.Dontje at [hidden] Thu Mar 20 05:36:41 2008 From: Terry.Dontje at [hidden] (Terry Dontje) Date: Thu, 20 Mar 2008 06:36:41 -0400 Subject: [Mpi-21] MPI-1.3: Updated drafts for reviewers In-Reply-To: <200803141516.06053.keller@hlrs.de> Message-ID: <47E23E39.8090705@sun.com> Here are my comments to the MPI-1.3 updated draft. page pdf 2, doc ii line 29- period after "May 5, 1994" line 30- is the email address "mpi-comments_at_[hidden]" correct? line 31- is MPIF committee correct too? Should it be "MPI Forum committee"? page pdf 50, doc 42 line 4 - "A empty status..." should be "An empty status..." page pdf 99, doc 91 line 42 missing "{" page pdf 100, 92 line 2 missing "}" lines 8-20 indentation seems off by one line 21-29 indentation seems off by 2 From WGROPP at [hidden] Sun Mar 30 20:23:38 2008 From: WGROPP at [hidden] (William Gropp) Date: Sun, 30 Mar 2008 20:23:38 -0500 Subject: [Mpi-21] MPI Doc edits Message-ID: <5BAB1738-4369-44B5-ACED-0B6D93A2F500@UIUC.EDU> Here are some notes that are still issues in the svn version of March 27th. This does not include updates to the bibliography, which I have sent to Rainer separately. Bill Contents (and forward) - The capitalization of section headings is inconsistent. This is apparent when looking at the contents. p29. The tables of types in C do not include the types added in MPI 2. Either they should be added or there should be a forward reference to them. p59, line 13, example 3.15. The MPI_Recv is missing a "status" argument. p104, line 4. MPI_GET_ELEMENT should be MPI_GET_ELEMENTS p106, line 13, section 3.12,14, the MPI_COMM_RANK call is missing the ierr argument. Line continuation is also not correct for Fortran. p106, line 40, section 3.12.14, the MPI_COMM_RANK call is missing the ierr argurment. Line continuation is also not correct for Fortran. p107, line 15, section 3.12.14, the MPI_COMM_RANK call is missing the ierr argument. Line continuation is also not correct for Fortran. p107, line 27, section 3.12.14, the MPI_COMM_RANK call is missing the ierr argument. Line continuation is also not correct for Fortran. p133, line 46 (MPI_GATHERV) the array index should be [j], not [i], to match the following text. p134, line 44, the myrank argument of MPI_Comm_rank needs to be &myrank. p149, line 41, the Recv is missing the recvtype before the "i". p155, lines 39-end of page - the table of predefined reduction operations for C needs to be reformatted. p160, line 13, example 4.18, remove the semicolon in the Fortran declaration of err. p160, line 15, example 4.18, the MPI_COMM_RANK call is missing the ierr argument. p160, line 21-21, example 4.18, the REDUCE call is missing the "CALL" and has an (invalid) semicolon at the end. p178, line 28, "in not" should be "is not" p179, lines 44-47. This text, about processes dynamically joining an MPI execution, dates from MPI-1 and is misleading. This entire paragraph needs to be replaced. p187, lines 5-8. This advice to implementors on reference counts for groups should include MPI_COMM_GROUP as a routine that increments the reference count. p197, line 8, section 5.5.1, the status argument is missing from MPI_Recv p198, line 23, Section 5.5.3. The closing brace on the test if (me ! = 0) should be moved after the MPI_COMM_FREE, other MPI_COMM_FREE will be called with MPI_COMM_NULL, which is erroneous. p198. Section 5.5.3, there is an extra space in "( commslave)" p194, Figure 5.2 has the left edge of each box clipped off p199 Section 5.5.4, example 4: t&hecomm -> &thecomm p199: the close } on the "me != MPI_UNDEFINED needs to be moved to after the MPI_Comm_free, otherwise thecomm is MPI_COMM_NULL. p200, line 45. The value of the status point must be initialized. For example, use MPI_Status status, and pass the address of that status to the two MPI_Wait calls. p208, top of page. Figure 5.3 has the left edge of the left square clipped off p210, top of page. Figure 5.4 has the left line clipped off. William Gropp Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign * -------------- next part -------------- An HTML attachment was scrubbed... URL: From gropp at [hidden] Thu Mar 20 09:11:18 2008 From: gropp at [hidden] (William Gropp) Date: Thu, 20 Mar 2008 09:11:18 -0500 Subject: [Mpi-21] MPI-1.3: Updated drafts for reviewers In-Reply-To: <47E23E39.8090705@sun.com> Message-ID: <3717DE6A-9354-4D27-8040-FE1024327A4F@mcs.anl.gov> No, this isn't correct. It should be mpi-comments_at_[hidden] . Bill On Mar 20, 2008, at 5:36 AM, Terry Dontje wrote: > line 30- is the email address "mpi-comments_at_[hidden]" correct? William Gropp Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign * -------------- next part -------------- An HTML attachment was scrubbed... URL: