February 2010 - mpi-forum - mailman3.cels.anl.gov

Re: [Mpi-forum] Revised Agenda
by Miron Livny 27 Feb '10

27 Feb '10

Rich, what ever happened to the fault-tolerance ideas? Miron Graham, Richard L. wrote: > A revised agenda for the March 8-10 meeting has been posted. Please let me know if there are working groups that would like to meet, and do not have a slot assigned. > > Thanks, > Rich > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >

1 0

Revised Agenda
by Graham, Richard L. 27 Feb '10

27 Feb '10

A revised agenda for the March 8-10 meeting has been posted. Please let me know if there are working groups that would like to meet, and do not have a slot assigned. Thanks, Rich

1 0

Re: [Mpi-forum] Trivial text reviews
by Bronis R. de Supinski 20 Feb '10

20 Feb '10

Pavan and Rich: The standard has been that they get four reviews. The suggestion at the last forum meeting was to reduce the time that these trivial tickets take for voting, etc. I can see a case for reducing the reviewing bruden as well but I think the right solution is: 1. Ticket creators should try to batch trivial changes (this action is not always possible - you want to submit them so you do not forget them); 2. Batch tickets on trivial changes for voting (this may delay voting on some tickets but should not be a big deal as long as they are applied before draft releases). I think we need to maintain the standard of four reviews in order to make the batching of votes safer. Others can look quickly at issues (and reading can just be "Tickets X, Y,...) and assume that reviews have ensured they are reasonable. It does not reduce the review burden but it helps with the overall concern. I have reviewed your ticket. It is clearly correct. Bronis On Sat, 20 Feb 2010, Graham, Richard L. wrote: > I think so. > > Rich > > > On 2/20/10 8:07 PM, "Pavan Balaji" <balaji(a)mcs.anl.gov> wrote: > > > > Do trivial text changes require 4 reviewers as well? > > Here's an example: https://*svn.mpi-forum.org/trac/mpi-forum-web/ticket/216 > > -- Pavan > > -- > Pavan Balaji > http://*www.*mcs.anl.gov/~balaji > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://*lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://*lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > >

1 0

Re: [Mpi-forum] Trivial text reviews
by Graham, Richard L. 20 Feb '10

20 Feb '10

I think so. Rich On 2/20/10 8:07 PM, "Pavan Balaji" <balaji(a)mcs.anl.gov> wrote: Do trivial text changes require 4 reviewers as well? Here's an example: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/216 -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Trivial text reviews
by Pavan Balaji 20 Feb '10

20 Feb '10

Do trivial text changes require 4 reviewers as well? Here's an example: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/216 -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [Mpi-forum] MPI_2COMPLEX etc
by Richard Treumann 17 Feb '10

17 Feb '10

Bill and members of the Forum I have been in contact with the developers who had included MPI_2COMPLEX and MPI_2DOUBLE_COMPLEX in their open source library. It turns out they had never made any judgement about whether these datatypes were useful or logical. Because their package sits between the MPI implementation and their users, they wanted their offering to be "complete" with respect to what they understood to be in the MPI-2 standard. They are removing MPI_2COMPLEX and MPI_2DOUBLE_COMPLEX immediately. If MPI implementations were to remove these datatypes in a few months, at least the one library I ran across that depends on them would have left that behind. I do not know if there is anyone we would break by removing them decisively but I think it is reasonable to consider doing it. Dick Dick Treumann - MPI Team IBM Systems & Technology Group Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 From: William Gropp <wgropp(a)illinois.edu> To: Main MPI Forum mailing list <mpi-forum(a)lists.mpi-forum.org> Date: 02/16/2010 01:36 PM Subject: Re: [Mpi-forum] MPI_2COMPLEX etc Sent by: mpi-forum-bounces(a)lists.mpi-forum.org I did some searching and I was reminded that *removing* MPI_2COMPLEX was one of the errata items from the MPI-1 specification. The 1.0 Spec had these (see pages 115, line 42 and 209, line 12). An errata removed them. So these were part of MPI, but were withdrawn. An implementation that dates back to 1.0 could be expected to include these (and have forgotten or decided not to withdraw them). These names weren't invented (I fully agree that MPI implementations must not create new names that begin with MPI_). And yes, MPICH/MPICH2 is such an implementation (I've found MPI_2COMPLEX defined in MPICH-1 header files dating back to 1994). We probably left it in for reasons of backward compatibility for any applications written for MPI-1.0. The text in MPI-1.0 doesn't define what is meant by the max or min of a complex value; a tricky question is how to make it reduce to the case of max/min on reals in the case that the imaginary part it zero. Though I don't remember the discussion on the errata, that's probably why we decided to remove MPI_2COMPLEX from MPI 1.1. If there is an application that makes use of them, then perhaps we should consider whether the standard should restore these types and the related operations. Bill On Feb 16, 2010, at 11:07 AM, Richard Treumann wrote: > Some MPI implementations have added new, predefined datatypes that > are not in the MPI Standard. These are the the MIN_LOC/MAX_LOC > operands MPI_2COMPLEX and MPI_2DOUBLE_COMPLEX. There is now at least > one widely used application that depends on MPI_2COMPLEX. That > application does not port to any MPI which lacks the non-standard > MPI_2COMPLEX type. > > I do not recall any discussions about MPI_2COMPLEX but they probably > did occur. Some people seem convinced MPI_2COMPLEX is part of > MPI-2.0. I searched both 2.0 and 2.2 without finding them. > > I think the ambiguity in the meaning of less_than / greater_than > when applied to complex numbers would be a good reason to consider > leaving the datatypes and the associated MIN_LOC & MAX_LOC > operations out of any standard. The idea of returning a location in > a complex number is sort of ugly too but well enough defined to be > acceptable. > > My understanding, going back to MPI 1.1 days, is that MPI > implementations were to avoid inventing names with an MPI_ prefix so > any name with that prefix could be used safely by follow-on MPI Fora > that were extending the standard. > > We do now have these MPI_ names among users and people are assuming > the should be able to use them portably. I think the Forum needs to > take a position and either add them to the standard (with a clear > definition of MPI_LOC and MAX_LOC behavior) or deprecate them. > > Dick > > > Dick Treumann - MPI Team > IBM Systems & Technology Group > Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > Tele (845) 433-7846 Fax (845) 433-8363 > <ATT00001..txt> William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Registration for the March 8-10
by Graham, Richard L. 16 Feb '10

16 Feb '10

Registration for the MPI Forum is now open at https://www.ornl.gov/ccsd_registrations/nccs_mpi_forums/ Cutoff for the hotel block is Feb 27th. Rich

1 0

Re: [Mpi-forum] MPI_2COMPLEX etc
by William Gropp 16 Feb '10

16 Feb '10

I did some searching and I was reminded that *removing* MPI_2COMPLEX was one of the errata items from the MPI-1 specification. The 1.0 Spec had these (see pages 115, line 42 and 209, line 12). An errata removed them. So these were part of MPI, but were withdrawn. An implementation that dates back to 1.0 could be expected to include these (and have forgotten or decided not to withdraw them). These names weren't invented (I fully agree that MPI implementations must not create new names that begin with MPI_). And yes, MPICH/MPICH2 is such an implementation (I've found MPI_2COMPLEX defined in MPICH-1 header files dating back to 1994). We probably left it in for reasons of backward compatibility for any applications written for MPI-1.0. The text in MPI-1.0 doesn't define what is meant by the max or min of a complex value; a tricky question is how to make it reduce to the case of max/min on reals in the case that the imaginary part it zero. Though I don't remember the discussion on the errata, that's probably why we decided to remove MPI_2COMPLEX from MPI 1.1. If there is an application that makes use of them, then perhaps we should consider whether the standard should restore these types and the related operations. Bill On Feb 16, 2010, at 11:07 AM, Richard Treumann wrote: > Some MPI implementations have added new, predefined datatypes that > are not in the MPI Standard. These are the the MIN_LOC/MAX_LOC > operands MPI_2COMPLEX and MPI_2DOUBLE_COMPLEX. There is now at least > one widely used application that depends on MPI_2COMPLEX. That > application does not port to any MPI which lacks the non-standard > MPI_2COMPLEX type. > > I do not recall any discussions about MPI_2COMPLEX but they probably > did occur. Some people seem convinced MPI_2COMPLEX is part of > MPI-2.0. I searched both 2.0 and 2.2 without finding them. > > I think the ambiguity in the meaning of less_than / greater_than > when applied to complex numbers would be a good reason to consider > leaving the datatypes and the associated MIN_LOC & MAX_LOC > operations out of any standard. The idea of returning a location in > a complex number is sort of ugly too but well enough defined to be > acceptable. > > My understanding, going back to MPI 1.1 days, is that MPI > implementations were to avoid inventing names with an MPI_ prefix so > any name with that prefix could be used safely by follow-on MPI Fora > that were extending the standard. > > We do now have these MPI_ names among users and people are assuming > the should be able to use them portably. I think the Forum needs to > take a position and either add them to the standard (with a clear > definition of MPI_LOC and MAX_LOC behavior) or deprecate them. > > Dick > > > Dick Treumann - MPI Team > IBM Systems & Technology Group > Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > Tele (845) 433-7846 Fax (845) 433-8363 > <ATT00001..txt> William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

MPI_2COMPLEX etc
by Richard Treumann 16 Feb '10

16 Feb '10

Some MPI implementations have added new, predefined datatypes that are not in the MPI Standard. These are the the MIN_LOC/MAX_LOC operands MPI_2COMPLEX and MPI_2DOUBLE_COMPLEX. There is now at least one widely used application that depends on MPI_2COMPLEX. That application does not port to any MPI which lacks the non-standard MPI_2COMPLEX type. I do not recall any discussions about MPI_2COMPLEX but they probably did occur. Some people seem convinced MPI_2COMPLEX is part of MPI-2.0. I searched both 2.0 and 2.2 without finding them. I think the ambiguity in the meaning of less_than / greater_than when applied to complex numbers would be a good reason to consider leaving the datatypes and the associated MIN_LOC & MAX_LOC operations out of any standard. The idea of returning a location in a complex number is sort of ugly too but well enough defined to be acceptable. My understanding, going back to MPI 1.1 days, is that MPI implementations were to avoid inventing names with an MPI_ prefix so any name with that prefix could be used safely by follow-on MPI Fora that were extending the standard. We do now have these MPI_ names among users and people are assuming the should be able to use them portably. I think the Forum needs to take a position and either add them to the standard (with a clear definition of MPI_LOC and MAX_LOC behavior) or deprecate them. Dick Dick Treumann - MPI Team IBM Systems & Technology Group Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363

1 0

Re: [Mpi-forum] Merged Nonblocking Collectives into MPI-3 - Please Review!
by Torsten Hoefler 16 Feb '10

16 Feb '10

Hi Rolf, all, > I'm sorry that I could not attend the discussion at last meeting. > Jeff's minutes are not yet available, therefore my opinion may > be in contrary to votes at the meeting - then please tell me. > > My opinion after looking at ticket 254, file chap-coll/coll.tex : > > I strongly disagree with the current state of the latex source. > You reinvented all the old MPI-2.2 markups, i.e., you uncleaned > the tex source of exactly one file: coll.tex. I did not reinvent them, I merged them from the MPI-2.2 document as we agreed on the first vote for NBC. Let me re-state what we decided after Rajeev brought that point up right before the first official vote on NBC last year. We decided to merge the MPI-2.2 changes into the reviewed (and voted on) revision 6 of the NBC document and then merge the document back to the main document. I volunteered to do this. And that's what I did, I used diff tools to merge the MPI-2.2 changes into the NBC document and the merged that one back (I removed the superfluous macros with diff tools). All changes (besided the ireduce_scatter_block of course) were semi-automatic and less error prone than manual changes. > All MPI-2.2 markups are removed to allow the usage of Bills > macros to mark all new MPI-3.0 changes. > I could not find any \MPIupdate{3.0}... or similar markups > in your new source. > > The 73 changes (found be grep'ing "htor") should be done > into "current" coll.tex revision 253 and not into a very old revision. Yes, I agree, but our defined method was different and also allowed for semi-automatic merging. > There is no chance to do the cleaning again on your current > unclean coll.tex revision 254! I volunteer to do the cleanup of the final document with the same method you used (pdftotext and diff) once we decided that the document is complete. > All these 73 changes should be marked with Bill's macros > as ticket {3.0}{109}. I decided to keep the MPI-2.2 macros in order to allow the reviewers to (1) compare revision 6 of the NBC document with MPI-2.2 (see if all 2.2 changes are successfully merged) and compare MPI-2.2 with the MPI-3.0 draft to see if ticket #109 was merged successfully. It is necessary to be able to compare all changes relative to the voted-on NBC document separately. Thus, the MPI-2.2 changes are in the original colors and the MPI-3 changes are b/w. All macros can be removed with pdftotext checking. > If the forum decided to step back to the uncleaned source > then it should be done for all sources and not only > for coll.tex. No, we did not decide to do that and I will clean the document manually once we decided to stick with the PDF. Not to reviewers: this whole discussion does *not* affect the pdf, it only changes source-code and removal and changes of the macros will be checked with pdftotext like Rolf's cleanup was done. > Rich and Jeff, I cannot see any comments on ticket #203, > nor any review from you. > Did you discussed it at the Jan 2010 meeting? Well, btw., as a general comment: we all knew that NBC was coming and that the voted-on chapter based on MPI-2.1. So it was clear that the cleanup would cause a major pain for the merge before it was started. It would have been better to hold it back until the NBC was merged in :). But I guess we don't have a similar situation in the future. I just talked to Rolf on the phone and we agreed that I will do the manual cleanup of chapter 5. Again, this will not change the non-markup PDF at all and so any reviews that we can get before the March meeting would be very helpful. Thanks & All the Best, Torsten -- bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- Torsten Hoefler | Research Associate Blue Waters Directorate | University of Illinois 1205 W Clark Street | Urbana, IL, 61801 NCSA Building | +01 (217) 244-7736

1 0