- Mpi-21 - mailman3.cels.anl.gov

Chapter 5
by unknown＠example.com 08 Apr '08

08 Apr '08

Rolf - My attempt to check in the file did not work and since I am not familiar with svn I did not try very long to debug the failure. The file is attached to this email. If you can get it into the repository you have the write token. (See attached file: context.tex) Chapter 5 - items needing Forum feedback (references are to April 1 draft) 1) 171:28-29 We point to a couple 15 year old papers to give background on using MPI to write libraries. It seems to me the concepts no longer require this backup. They have been around for long enough to be current practice. Is there a reason to keep the pointers? 2) 192:8-13 Bogus advise about just playing with the reference count to implement MPI_COMM_DUP (I think Rolf has already captured this for MPI 2.2) 3) 202:31-35 The wierd suggestion that intercommunicator groups may not be required to be disjoint should come out. Everything else is pretty clear that they ARE disjoint. As far as I can see this statement falls into the catagory of "We could have made a different choice when we wrote MPI-1". The decision was made that the groups are disjoint so this editorial aside should be removed. 4) The discussion of attribute caching needs significant rework. It has paragraphs from when only communicators supported caching and paragraphs about adding caching support to windows and datatypes. It should be reworded to describe caching as it applies to all three object types and explain who there is no WIN_DUP while there is a TYPE_DUP and a COMM_DUP. (and therefore no attribute copy functions for windows.) 5) Jeff Squires has pointed out a need for explanation of the C++ clone functions on 186:1-5 and to me it looks like a sentence or two from a C++ guru along with a pointer to section 13.1.7 would do. Perhaps add: Please see section ____ page ___ for further discussion about the C++ bindings for Dup() and Clone(). where ____ page ___ is a link to 13.1.7. (I did not want to try to add a LaTex link so I did not do any of this change) The changes I have made are pretty straightforward. 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 *

1 0

Re: [Mpi-21] Newest updates
by unknown＠example.com 08 Apr '08

08 Apr '08

The new indexes are a good idea, but they seem a bit inconsistent: - The examples index is a mix of upper and lower case MPI function names - The MPI constant index has only 1 C++ constant listed - I see weird entries in the MPI constant index, such as: MPI_ERR_... (I'm not abbreviating -- there's actually an "MPI_ERR_..." entry) MPI_Delete_function MPI_Copy_function MPI_Aint ...and others - I'm not sure what the MPI C++ index is; the only item listed that does not have an equivalent in C is MPI::ERRORS_THROW_EXCEPTIONS - The MPI function index has weird entries, similar to the constant index, such as: MPI_ MPI_*_FREE MPI_{TYPE,COMM,WIN}_CREATE_KEYVAL MPI_Comm_delete_attr_function ...and others - The MPI function index also has a mix of upper and lower case MPI function names On Apr 8, 2008, at 11:03 AM, Rolf Rabenseifner wrote: > Please have a look at the last pages of > http://www.hlrs.de/mpi/mpi21/doc/mpi-report.pdf > > At the end, all Index data is now separated into 4 Indexes. > - The entries in the C++ index should be corrected that > they go directly into the const index. > - The Callback index is not complete. > > 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.mpi-forum.org/mailman/listinfo.cgi/mpi-21 -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-21] Rest of MPI-2.1 External interfaces into other chapters.
by unknown＠example.com 08 Apr '08

08 Apr '08

Rolf: Re: > Have already implemented the merge? No. > Decoding a Datatype is already moved to Datatypes. Yes. > Naming Objects, I would move it after 5.7 Caching. Works for me. > And the rest, I expect you have done a nice merge. Not yet. Too busy with the SC deadline, the EuroPVM/MPI deadline and an internal proposal deadline. Frankly, I don't expect to get back to this until next week. > As you know, I would like to get the write-token this evening. > Please svn commit you current status this evening and send > me an email with the files for wich I get the right to write > from you. You've got the token as far as I am concerned. > Any comments on the new Indexes? They look nice. Bronis > > Best regards > Rolf > > > On Thu, 3 Apr 2008 15:19:55 -0400 > George Bosilca <bosilca_at_[hidden]> wrote: > > Bronis, > > > > If the data-type section get moved into the chapter 3 it make sense to merge the leftover of the chapter 11 with chapter 7, as long as we choose a right name. "MPI Environmental Management" is not the right chapter for "Generalized Requests". But of course these are just details. > > > > I'll get in touch with you asap to see how we can coordinate. > > > > Thanks, > > george. > > > > 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) >

1 0

Rest of MPI-2.1 External interfaces into other chapters.
by unknown＠example.com 08 Apr '08

08 Apr '08

Bronis, George, Dick (and Rich), Have already implemented the merge? Decoding a Datatype is already moved to Datatypes. Naming Objects, I would move it after 5.7 Caching. And the rest, I expect you have done a nice merge. As you know, I would like to get the write-token this evening. Please svn commit you current status this evening and send me an email with the files for wich I get the right to write from you. Any comments on the new Indexes? Best regards Rolf On Thu, 3 Apr 2008 15:19:55 -0400 George Bosilca <bosilca_at_[hidden]> wrote: > Bronis, > > If the data-type section get moved into the chapter 3 it make sense to merge the leftover of the chapter 11 with chapter 7, as long as we choose a right name. "MPI Environmental Management" is not the right chapter for "Generalized Requests". But of course these are just details. > > I'll get in touch with you asap to see how we can coordinate. > > Thanks, > george. 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)

1 0

pt2pt chapter - split into 2 chapters?
by unknown＠example.com 08 Apr '08

08 Apr '08

>>> please do not forget to svn commit your current chapter pt2pt.tex and credits.tex source this evening and give me back the write-token. <<< Rich, I'm not sure wether you are doing this already: Chapter 3 to 14 have each 38 pages in average, but Chapter 3 has 100 pages. The last 50 pages are 3.12-3.14, the derived datatypes together with pack and unpack. These 50 pages are independent from normal pt2pt communication, because needed also in all other communication. I would recommend to spilt it into 2 chapters. (It was already proposed from someone else.) If nobody is against, and you have not done already, I would do it tomorrow together with the corrections based on the last reviews. Please do not forget to svn commit and to send me an email, giving me back the allowance to write (write-token). (If you have done nothing, then I need only the email.) ASAP I'll transfer the token back to you. Have you already looked at the new Indexes? My next mail looks at Chapter 11. 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)

1 0

Re: [Mpi-21] Newest updates
by unknown＠example.com 08 Apr '08

08 Apr '08

Please have a look at the last pages of http://www.hlrs.de/mpi/mpi21/doc/mpi-report.pdf At the end, all Index data is now separated into 4 Indexes. - The entries in the C++ index should be corrected that they go directly into the const index. - The Callback index is not complete. 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)

1 0

Newest updates
by unknown＠example.com 08 Apr '08

08 Apr '08

Updated chapters: 6. Process Topologies (by Jesper Traeff) 8. Miscellany (by Jesper Traeff) 10. One-sided (by Jesper Traeff) A. Annex Language Bindings (Jeff's comments implemented) Annex A.4 is now sorted again by the routines names. See http://www.hlrs.de/mpi/mpi21/doc/mpi-report.pdf (should be used only for controling) (Review references should be done normally to Draft Apr. 1, 2008) and http://www.hlrs.de/mpi/mpi21/doc/MPI-2.1draft-2008-02-23-review.txt 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)

1 0

Re: [Mpi-21] MPI-2.1 April 1 document comments
by unknown＠example.com 08 Apr '08

08 Apr '08

Hi Jeff, as with all reviews, I've put it into http://www.hlrs.de/mpi/mpi21/doc/MPI-2.1draft-2008-02-23-review.txt User / Password as usual: mpi21 / mpi21 Most of your proposals in Binding, I commented with R2 to give it back to you for implementing it. Best regards Rolf On Mon, 7 Apr 2008 11:18:32 -0700 Jeff Squyres <jsquyres_at_[hidden]> wrote: > While reading the April 1 MPI-2.1 document for C++ and chapter 13 > issues, I itemized a list of other issues that I found. Some may want > to be pushed off to 2.2 (I have noted all of these with "--> This will > require a vote") -- I leave these up to the Forum to decide -- but > others should be fixed in 2.1. > > Enjoy. > > ----- > > April 7 2008 > Comments on MPI-2.1 April 1, 2008 document > > (notation: pX.Y = page X, line Y) > > Overall > ======= > > - Frontage numbering is still roman numerals -- I thought we agreed to > have the physical and PDF page numbers agree. > > - Some function pointer typedefs are "_function", others are "_fn" > We should be consistent throughout the text. > > Intro chapter > ============= > > - p5.2: Two open source MPI implementations are cited that are no > longer relevant. This entire sentence should be removed. Indeed, > the language in the overall paragraph is forward-looking -- it > should probably be re-worked to be in the present tense. > > - p6.46: Chapter 13 discusses Fortran issues (not Fortran 90 issues), > and also discusses language interoperability issues. > > - p7.11: Looks like a broken LaTeX reference. > > Terms and Conventions > ===================== > > - p9.40-10.10: The C and Fortran language neutral name do not include > the prefix "MPI_", but the C++ bindings include the prefix "MPI::". > Shouldn't the C/Fortran bindings be "MPI_CLASS_ACTION_SUBSET" > (etc.)? > > - p10.35: due to the decision from last meeting (sort out the > IN/OUT/INOUT mess in MPI-2.2), the language should be softened in > this paragraph and the full paragraph following this one (because > they contradict each other). Specifically, I propose changing: > > 10.35: Thus, in C++, IN aguments are either references... > to > Thus, in C++, IN arguments are usually either references... > > - p11.22: "Fortran in this document refers to Fortran 90". For > MPI-2.1, it is probably suitable to leave this, but we might want to > make a statement (footnote or parenthetical) that it is expected to > be updated in future MPI spec revisions. > > > Point-to-Point Communication > ============================ > > - p66.33: Why is the request argument to the C bindings MPI_CANCEL > take a pointer? The language neutral binding is IN, and the C++ > binding is const. This seems to be a contradiction. > --> This cannot be changed easily because every MPI implementation > uses (MPI_Request *) as the type. > > - p83.29: extra space: "( int count," > > - p92.43: mising "const" before "void* location". Adding "const" > will not break any user codes or MPI implementations. > --> This will require a vote. > > - p95.47-48: remove "const" before lb an extent arguments. > Removing "const" will not break any user codes or MPI > implementations. > --> This will require a vote. > > Collective Communications > ========================= > > - p123.32: "relaxed" uses quote marks in the wrong direction > > - p123.27: should say "MPI-1" instead of "MPI-1.2" > > Groups, Contexts, and Communicators > =================================== > > - p186.5: Descriptions for the C++ bindings need to be included here, > since they are different than the C bindings. The text from 13.1.7 > would seem to be sufficient. > > - p214.32: Missing "const" before "void* attribute_val_in" (datatype > callback argument is const) > --> This will require a vote. > > - p214.36: Delete function comm argument should be const (?) > --> This will require a vote. > > - p219.5: Missing "const" before "void* attribute_val_in" (datatype > callback argument is const) > --> This will require a vote. > > - p219.9: Delete function win argument should be const (?) > --> This will require a vote. > > - p221.44: Delete function type argument should be const (?) > --> This will require a vote. > > MPI Environmental Management > ============================ > > - p248.3: Earlier in the document, references are made to v1.3. Is > that not a valid tuple to return from MPI_GET_VERSION? > > - p249.45: Remove duplicate C++ binding > > - p254.21: Remove erroneous MPI::Intracomm::Create C++ binding > > - p255.2: First argument (comm handle reference) to errhandler > function should be const. > --> This will require a vote. > > - p256.27: First argument (win handle reference) to errhandler > function should be const. > --> This will require a vote. > > - p257.41: First argument (file handle reference) to errhandler > function should be const. > --> This will require a vote. > > - p258.39: Delete duplicate C++ binding > > - p259.13: Delete duplicate C++ binding > > - p260.36-43: First letter of description should be capitolized to be > consistent with rest of list. > > - p261.42: Delete duplicate C++ binding > > - p263.21-23: Delete duplicate C++ bindings > > - p264.22: Delete duplicate C++ binding > > - p267.24: Delete duplicate C++ binding > > - p267.42: Delete duplicate C++ binding > > Process Creation and Management > =============================== > > - p288.11: Function should be const. > --> This will require a vote. > > - p288.15: Function should be const. > --> This will require a vote. > > External Interfaces > =================== > > - p344.39: Arguments of query_fn, free_fn, and cancel_fn need to have > *'s. This is a consistency issue (the rest of the standard uses > "*" for function pointer parameters), not a correctness issue -- > works both ways. Should not break any user code or MPI > implementations. > > I/O > === > > - p419.43: datatype argument should be const > > Language Bindings > ================= > > - p437.18: Delete first sentence of paragraph > > - p437.22: Delete "original" > > - p437.24-29: Delete first and last sentences of paragraph > > - p437.29: New last sentence, "See Annex A.4.19 for a function cross > reference." > > - p438.11: Delete "for MPI-1" > > - p438.14-37: Join the two namespaces together and delete the > "Additionally, the following classes defined for MPI-2:" text. > Re-sort the class names as appropriate. > > - p439.2: Delete last sentence ("To maintain ... in [23].") > > - p442: Table 13.1 is redundant with Annex A.1. However, the > following C++ types are missing from Annex A.1: > > MPI::SIGNED_CHAR > MPI::BOOL > MPI::COMPLEX > MPI::DOUBLE_COMPLEX > MPI::LONG_DOUBLE_COMPLES > > - p442: Table 13.2 is redundant with Annex A.1 > > - p445.5-11: These functions are not listed in Annex A > > - p445.36-38: Remove this entire paragraph ("Compilers that do not > support..."). This feature has been a part of C++ since C++98, and > exists in all modern C++ compilers. > > - p446.7-17: Declarations for the MPI::Exceptions class are missing > from Annex A > > - p448.47: Remove trailing "/" from "OUT/" > > - p450.26-44: The bullet list is wholly redundant with section 2.6.2. > > - p456.27-29: VOLATILE is in Fortran 200x; reword first sentence from: > "In the longer term, the attribute VOLATILE is under > consideration for Fortran 2000 and would give the buffer or > variable the properties needed, but it would inhibit > optimization of any code containing the buffer or variable." > to > "The VOLATILE attribute, available in later versions of Fortran, > would give the buffer or variable the properties needed, but it > would inhibit optimization of any code containing the buffer or > variable." > > - p459.11-15: Delete paragraph > > - p462.43-45: Delete paragraph > > - p463.17-18: Delete first sentence; delete "In MPI-2," > > - p467.23: There is an extra space before "MPI_FINALIZE" > > - p468.16-39: None of these functions appear in Annex A (they > should!) > > - p469.41 and 44: These functions do not appear in Annex A (they > should!) > > - p470.46: Change sentence from: > "It is important to note that all C++ objects and their > corresponding C handles..." > to > "It is important to note that all C++ objects with > corresponding C handles..." > I.e., this sentence is referring only to C++ handles that actually > have corresponding C handles (e.g., not > MPI::ERRORS_THROW_EXCEPTIONS). > > Profiling Interface > =================== > > - p481.4: Delete "const" > --> This may require a vote. > > Annex A > ======= > > - p494.15: s/Fortran/Fortran only > > - p494.30: Missing MPI::ERRORS_THROW_EXCEPTIONS > > - p495.18-19 and 33-34: MPI_BYTE and MPI_PACKED are listed in two > separate tables. > > - p495.30: MPI::COMPLEX should be MPI::F_COMPLEX > > - p495.38: Looks like a blank extra 3rd column is in this table > > - p495.bottom: Missing table for "C++ only" datatypes: > MPI::BOOL > MPI::COMPLEX > MPI::DOUBLE_COMPLEX > MPI::LONG_DOUBLE_COMPLEX > MPI::SIGNED_CHAR > > - p496.1: Add ", no Fortran" before the ")" > > - p496.10, s/Fortran/Fortran only/ > > - p496.27-30: Alignment of table entries should be to the left, not > centered. > > - p544.13: Many of the prototypes for Clone() and Dup() are missing > > - p547.all: Many doubles of C++ bindings; likely because of errors in > the chapter text. > > - p554.41: Do we need an empty deprecated functions section? > > - p555.45-46: Forgot to mention MPI_ERRCODES_IGNORE, > MPI_F_STATUSES_IGNORE, and MPI_F_STATUS_IGNORE > > - p556.bottom: Missing prototypes for the MPI::Exceptions class > > -- > 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)

1 0

Re: [Mpi-21] MPI-2.1 April 1 document comments
by unknown＠example.com 07 Apr '08

07 Apr '08

Please do not change any interfaces. All "const" discussion is moved to MPI-2.2. This was a decision of the Forum at March meeting. Best regards Rolf On Mon, 7 Apr 2008 11:32:40 -0700 (PDT) "Bronis R. de Supinski" <bronis_at_[hidden]> wrote: > > Jeff: > > You should send the individual issues to the chapter owners. > > I will try to look over the issues for chapters 11 and 14. > I don't have a strong opinon on either of them and will > certainly delete the "const" in chapter 14 if others agree. > > Bronis > > > > > On Mon, 7 Apr 2008, Jeff Squyres wrote: > > > While reading the April 1 MPI-2.1 document for C++ and chapter 13 > > issues, I itemized a list of other issues that I found. Some may want > > to be pushed off to 2.2 (I have noted all of these with "--> This will > > require a vote") -- I leave these up to the Forum to decide -- but > > others should be fixed in 2.1. > > > > Enjoy. > > > > ----- > > > > April 7 2008 > > Comments on MPI-2.1 April 1, 2008 document > > > > (notation: pX.Y = page X, line Y) > > > > Overall > > ======= > > > > - Frontage numbering is still roman numerals -- I thought we agreed to > > have the physical and PDF page numbers agree. > > > > - Some function pointer typedefs are "_function", others are "_fn" > > We should be consistent throughout the text. > > > > Intro chapter > > ============= > > > > - p5.2: Two open source MPI implementations are cited that are no > > longer relevant. This entire sentence should be removed. Indeed, > > the language in the overall paragraph is forward-looking -- it > > should probably be re-worked to be in the present tense. > > > > - p6.46: Chapter 13 discusses Fortran issues (not Fortran 90 issues), > > and also discusses language interoperability issues. > > > > - p7.11: Looks like a broken LaTeX reference. > > > > Terms and Conventions > > ===================== > > > > - p9.40-10.10: The C and Fortran language neutral name do not include > > the prefix "MPI_", but the C++ bindings include the prefix "MPI::". > > Shouldn't the C/Fortran bindings be "MPI_CLASS_ACTION_SUBSET" > > (etc.)? > > > > - p10.35: due to the decision from last meeting (sort out the > > IN/OUT/INOUT mess in MPI-2.2), the language should be softened in > > this paragraph and the full paragraph following this one (because > > they contradict each other). Specifically, I propose changing: > > > > 10.35: Thus, in C++, IN aguments are either references... > > to > > Thus, in C++, IN arguments are usually either references... > > > > - p11.22: "Fortran in this document refers to Fortran 90". For > > MPI-2.1, it is probably suitable to leave this, but we might want to > > make a statement (footnote or parenthetical) that it is expected to > > be updated in future MPI spec revisions. > > > > > > Point-to-Point Communication > > ============================ > > > > - p66.33: Why is the request argument to the C bindings MPI_CANCEL > > take a pointer? The language neutral binding is IN, and the C++ > > binding is const. This seems to be a contradiction. > > --> This cannot be changed easily because every MPI implementation > > uses (MPI_Request *) as the type. > > > > - p83.29: extra space: "( int count," > > > > - p92.43: mising "const" before "void* location". Adding "const" > > will not break any user codes or MPI implementations. > > --> This will require a vote. > > > > - p95.47-48: remove "const" before lb an extent arguments. > > Removing "const" will not break any user codes or MPI > > implementations. > > --> This will require a vote. > > > > Collective Communications > > ========================= > > > > - p123.32: "relaxed" uses quote marks in the wrong direction > > > > - p123.27: should say "MPI-1" instead of "MPI-1.2" > > > > Groups, Contexts, and Communicators > > =================================== > > > > - p186.5: Descriptions for the C++ bindings need to be included here, > > since they are different than the C bindings. The text from 13.1.7 > > would seem to be sufficient. > > > > - p214.32: Missing "const" before "void* attribute_val_in" (datatype > > callback argument is const) > > --> This will require a vote. > > > > - p214.36: Delete function comm argument should be const (?) > > --> This will require a vote. > > > > - p219.5: Missing "const" before "void* attribute_val_in" (datatype > > callback argument is const) > > --> This will require a vote. > > > > - p219.9: Delete function win argument should be const (?) > > --> This will require a vote. > > > > - p221.44: Delete function type argument should be const (?) > > --> This will require a vote. > > > > MPI Environmental Management > > ============================ > > > > - p248.3: Earlier in the document, references are made to v1.3. Is > > that not a valid tuple to return from MPI_GET_VERSION? > > > > - p249.45: Remove duplicate C++ binding > > > > - p254.21: Remove erroneous MPI::Intracomm::Create C++ binding > > > > - p255.2: First argument (comm handle reference) to errhandler > > function should be const. > > --> This will require a vote. > > > > - p256.27: First argument (win handle reference) to errhandler > > function should be const. > > --> This will require a vote. > > > > - p257.41: First argument (file handle reference) to errhandler > > function should be const. > > --> This will require a vote. > > > > - p258.39: Delete duplicate C++ binding > > > > - p259.13: Delete duplicate C++ binding > > > > - p260.36-43: First letter of description should be capitolized to be > > consistent with rest of list. > > > > - p261.42: Delete duplicate C++ binding > > > > - p263.21-23: Delete duplicate C++ bindings > > > > - p264.22: Delete duplicate C++ binding > > > > - p267.24: Delete duplicate C++ binding > > > > - p267.42: Delete duplicate C++ binding > > > > Process Creation and Management > > =============================== > > > > - p288.11: Function should be const. > > --> This will require a vote. > > > > - p288.15: Function should be const. > > --> This will require a vote. > > > > External Interfaces > > =================== > > > > - p344.39: Arguments of query_fn, free_fn, and cancel_fn need to have > > *'s. This is a consistency issue (the rest of the standard uses > > "*" for function pointer parameters), not a correctness issue -- > > works both ways. Should not break any user code or MPI > > implementations. > > > > I/O > > === > > > > - p419.43: datatype argument should be const > > > > Language Bindings > > ================= > > > > - p437.18: Delete first sentence of paragraph > > > > - p437.22: Delete "original" > > > > - p437.24-29: Delete first and last sentences of paragraph > > > > - p437.29: New last sentence, "See Annex A.4.19 for a function cross > > reference." > > > > - p438.11: Delete "for MPI-1" > > > > - p438.14-37: Join the two namespaces together and delete the > > "Additionally, the following classes defined for MPI-2:" text. > > Re-sort the class names as appropriate. > > > > - p439.2: Delete last sentence ("To maintain ... in [23].") > > > > - p442: Table 13.1 is redundant with Annex A.1. However, the > > following C++ types are missing from Annex A.1: > > > > MPI::SIGNED_CHAR > > MPI::BOOL > > MPI::COMPLEX > > MPI::DOUBLE_COMPLEX > > MPI::LONG_DOUBLE_COMPLES > > > > - p442: Table 13.2 is redundant with Annex A.1 > > > > - p445.5-11: These functions are not listed in Annex A > > > > - p445.36-38: Remove this entire paragraph ("Compilers that do not > > support..."). This feature has been a part of C++ since C++98, and > > exists in all modern C++ compilers. > > > > - p446.7-17: Declarations for the MPI::Exceptions class are missing > > from Annex A > > > > - p448.47: Remove trailing "/" from "OUT/" > > > > - p450.26-44: The bullet list is wholly redundant with section 2.6.2. > > > > - p456.27-29: VOLATILE is in Fortran 200x; reword first sentence from: > > "In the longer term, the attribute VOLATILE is under > > consideration for Fortran 2000 and would give the buffer or > > variable the properties needed, but it would inhibit > > optimization of any code containing the buffer or variable." > > to > > "The VOLATILE attribute, available in later versions of Fortran, > > would give the buffer or variable the properties needed, but it > > would inhibit optimization of any code containing the buffer or > > variable." > > > > - p459.11-15: Delete paragraph > > > > - p462.43-45: Delete paragraph > > > > - p463.17-18: Delete first sentence; delete "In MPI-2," > > > > - p467.23: There is an extra space before "MPI_FINALIZE" > > > > - p468.16-39: None of these functions appear in Annex A (they > > should!) > > > > - p469.41 and 44: These functions do not appear in Annex A (they > > should!) > > > > - p470.46: Change sentence from: > > "It is important to note that all C++ objects and their > > corresponding C handles..." > > to > > "It is important to note that all C++ objects with > > corresponding C handles..." > > I.e., this sentence is referring only to C++ handles that actually > > have corresponding C handles (e.g., not > > MPI::ERRORS_THROW_EXCEPTIONS). > > > > Profiling Interface > > =================== > > > > - p481.4: Delete "const" > > --> This may require a vote. > > > > Annex A > > ======= > > > > - p494.15: s/Fortran/Fortran only > > > > - p494.30: Missing MPI::ERRORS_THROW_EXCEPTIONS > > > > - p495.18-19 and 33-34: MPI_BYTE and MPI_PACKED are listed in two > > separate tables. > > > > - p495.30: MPI::COMPLEX should be MPI::F_COMPLEX > > > > - p495.38: Looks like a blank extra 3rd column is in this table > > > > - p495.bottom: Missing table for "C++ only" datatypes: > > MPI::BOOL > > MPI::COMPLEX > > MPI::DOUBLE_COMPLEX > > MPI::LONG_DOUBLE_COMPLEX > > MPI::SIGNED_CHAR > > > > - p496.1: Add ", no Fortran" before the ")" > > > > - p496.10, s/Fortran/Fortran only/ > > > > - p496.27-30: Alignment of table entries should be to the left, not > > centered. > > > > - p544.13: Many of the prototypes for Clone() and Dup() are missing > > > > - p547.all: Many doubles of C++ bindings; likely because of errors in > > the chapter text. > > > > - p554.41: Do we need an empty deprecated functions section? > > > > - p555.45-46: Forgot to mention MPI_ERRCODES_IGNORE, > > MPI_F_STATUSES_IGNORE, and MPI_F_STATUS_IGNORE > > > > - p556.bottom: Missing prototypes for the MPI::Exceptions class > > > > -- > > 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 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)

1 0

Re: [Mpi-21] MPI-2.1 April 1 document comments
by unknown＠example.com 07 Apr '08

07 Apr '08

Yes it was 10.d on the long list. We keep roman for frontmatter. Now pdf has correct numbering (My acroread under Windows works really fine) (My acroread under Linux is a little bit ugly, it computes and shows also the global numbering :-( ) On Mon, 7 Apr 2008 13:37:20 -0500 William Gropp <gropp_at_[hidden]> wrote: > The numbers do agree - we changed the LaTeX options so that the PDF knows the real numbers, which include roman for front matter. It would be wrong to number the pages sequentially from 1, abandoning long-established practice with documents. And at least on a Mac, both Preview and Acrobat both display the correct page number and will goto that page (including going to "xi"). Before we fixed this, those display programs did not know how the pages were numbered, and just (incorrectly) counted forward from one. Now the document meets standard page numbering conventions, and the PDF display programs are aware of the true page numbers. > > Bill > > On Apr 7, 2008, at 1:18 PM, Jeff Squyres wrote: > > > Overall > > ======= > > > > - Frontage numbering is still roman numerals -- I thought we agreed to > > have the physical and PDF page numbers agree. > > > > William Gropp > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > 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)

1 0