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

Re: [Mpi-forum] MPI-3 svn branch does not build
by Rajeev Thakur 05 Dec '12

05 Dec '12

The exact ticket numbers corresponding to each change may not be useful, but I find it useful to see all changed text in a different color. Rajeev On Dec 5, 2012, at 7:44 PM, William Gropp wrote: > I'll say it again: the markup approach that we used for MPI 2.1 and 2.2 was never appropriate to 3.0 and it was, in my opinion, a mistake that has cost us time and accuracy, since it often obscures the overall picture of the changes in preference for micro updates. The issue is not so much whether we should strip out the markup, its whether we want to continue with the current failed approach (strip out the 3.0 markup, then insert 3.1 markup that will have the same problems), or return to the update-by-chapter approach that worked for 1.0 and 2.0. > > Bill > > William Gropp > Director, Parallel Computing Institute > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > On Dec 5, 2012, at 7:09 PM, Jeff Squyres wrote: > >> Is it time to strip all the MPI-3.0 change markup? >> >> On Dec 5, 2012, at 4:37 PM, William Gropp wrote: >> >>> This is a known problem - the overuse of change markers is the problem. The general make target builds the most marked up version of the standard, which at this point is unbuildable. As that includes only the document for review and editing, this hasn't been fixed or changed. >>> >>> I will once again put in my plea for sensible edits and markup in the chapters, not the mark-every-single-change-to-whitespace-or-commas approach that we have been taking. Chapter committees should be formed, they should update a chapter, then provide a diff. Anyone who reflows text, thus making the diff harder, should be expelled. >>> >>> Bill >>> >>> William Gropp >>> Director, Parallel Computing Institute >>> Deputy Director for Research >>> Institute for Advanced Computing Applications and Technologies >>> Paul and Cynthia Saylor Professor of Computer Science >>> University of Illinois Urbana-Champaign >>> >>> >>> >>> On Dec 5, 2012, at 4:46 PM, Pavan Balaji wrote: >>> >>>> >>>> I tried building this branch: >>>> >>>> https://svn.mpi-forum.org/svn/mpi-forum-docs/approved/MPI-3.0/ >>>> >>>> When I do "make", it doesn't build correctly. "make cleandoc" works fine. >>>> >>>> Should we be using a copy of this branch for future changes (e.g., >>>> errata, etc.)? >>>> >>>> -- 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 >> >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

No MPI forum meeting tomorrow 12/5
by Schulz, Martin 05 Dec '12

05 Dec '12

Hi all, FYI for people who left early today: we had only one small agenda item left for tomorrow and we decided to postpone this until a later date/email. Hence, there will be no official meeting tomorrow, but Jeff mentioned that the room is available (and accessible from the outside without badging) in case people would like to use the space. Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [Mpi-forum] MPI-3 svn branch does not build
by William Gropp 05 Dec '12

05 Dec '12

I'll say it again: the markup approach that we used for MPI 2.1 and 2.2 was never appropriate to 3.0 and it was, in my opinion, a mistake that has cost us time and accuracy, since it often obscures the overall picture of the changes in preference for micro updates. The issue is not so much whether we should strip out the markup, its whether we want to continue with the current failed approach (strip out the 3.0 markup, then insert 3.1 markup that will have the same problems), or return to the update-by-chapter approach that worked for 1.0 and 2.0. Bill William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign On Dec 5, 2012, at 7:09 PM, Jeff Squyres wrote: > Is it time to strip all the MPI-3.0 change markup? > > On Dec 5, 2012, at 4:37 PM, William Gropp wrote: > >> This is a known problem - the overuse of change markers is the problem. The general make target builds the most marked up version of the standard, which at this point is unbuildable. As that includes only the document for review and editing, this hasn't been fixed or changed. >> >> I will once again put in my plea for sensible edits and markup in the chapters, not the mark-every-single-change-to-whitespace-or-commas approach that we have been taking. Chapter committees should be formed, they should update a chapter, then provide a diff. Anyone who reflows text, thus making the diff harder, should be expelled. >> >> Bill >> >> William Gropp >> Director, Parallel Computing Institute >> Deputy Director for Research >> Institute for Advanced Computing Applications and Technologies >> Paul and Cynthia Saylor Professor of Computer Science >> University of Illinois Urbana-Champaign >> >> >> >> On Dec 5, 2012, at 4:46 PM, Pavan Balaji wrote: >> >>> >>> I tried building this branch: >>> >>> https://svn.mpi-forum.org/svn/mpi-forum-docs/approved/MPI-3.0/ >>> >>> When I do "make", it doesn't build correctly. "make cleandoc" works fine. >>> >>> Should we be using a copy of this branch for future changes (e.g., >>> errata, etc.)? >>> >>> -- 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 > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] MPI-3 svn branch does not build
by Pavan Balaji 05 Dec '12

05 Dec '12

On 12/05/2012 07:09 PM US Central Time, Jeff Squyres wrote: > Is it time to strip all the MPI-3.0 change markup? This was the real intent of my question -- how do we markup changes to bring to the Forum or discuss in the working group? -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [Mpi-forum] MPI-3 svn branch does not build
by Jeff Squyres 05 Dec '12

05 Dec '12

Is it time to strip all the MPI-3.0 change markup? On Dec 5, 2012, at 4:37 PM, William Gropp wrote: > This is a known problem - the overuse of change markers is the problem. The general make target builds the most marked up version of the standard, which at this point is unbuildable. As that includes only the document for review and editing, this hasn't been fixed or changed. > > I will once again put in my plea for sensible edits and markup in the chapters, not the mark-every-single-change-to-whitespace-or-commas approach that we have been taking. Chapter committees should be formed, they should update a chapter, then provide a diff. Anyone who reflows text, thus making the diff harder, should be expelled. > > Bill > > William Gropp > Director, Parallel Computing Institute > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > On Dec 5, 2012, at 4:46 PM, Pavan Balaji wrote: > >> >> I tried building this branch: >> >> https://svn.mpi-forum.org/svn/mpi-forum-docs/approved/MPI-3.0/ >> >> When I do "make", it doesn't build correctly. "make cleandoc" works fine. >> >> Should we be using a copy of this branch for future changes (e.g., >> errata, etc.)? >> >> -- 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 -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [Mpi-forum] MPI-3 svn branch does not build
by William Gropp 05 Dec '12

05 Dec '12

This is a known problem - the overuse of change markers is the problem. The general make target builds the most marked up version of the standard, which at this point is unbuildable. As that includes only the document for review and editing, this hasn't been fixed or changed. I will once again put in my plea for sensible edits and markup in the chapters, not the mark-every-single-change-to-whitespace-or-commas approach that we have been taking. Chapter committees should be formed, they should update a chapter, then provide a diff. Anyone who reflows text, thus making the diff harder, should be expelled. Bill William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign On Dec 5, 2012, at 4:46 PM, Pavan Balaji wrote: > > I tried building this branch: > > https://svn.mpi-forum.org/svn/mpi-forum-docs/approved/MPI-3.0/ > > When I do "make", it doesn't build correctly. "make cleandoc" works fine. > > Should we be using a copy of this branch for future changes (e.g., > errata, etc.)? > > -- 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

Location and Dates for Future MPI Forum Meetings
by Schulz, Martin 05 Dec '12

05 Dec '12

Hi all, We had a very lengthy discussion on future MPI forum meetings at the current forum in San Jose yesterday and today. Based on the input that Jeff collected after the meeting in Vienna and due to conflicts with related conferences, we decided on the following schedule, which is now also listed on the web page: March 11 - 14, 2013 Chicago, IL, USA (hosted by Microsoft) mid Monday to mid Thursday Reason: the poll from last September (as well as the discussion in the room) showed a strong preference to keep this meeting in US and have only one meeting not in the US coupled with EuroMPI June 4 - 7, 2013 San Jose, CA, USA (hosted by Cisco) mid Tuesday to mid Friday Reason: as discussed on the mailing list earlier to avoid conflict with ICS; moved to Tuesday-Friday to make combined travel with ICS easier September 11 - 13, 2013 Madrid, Spain (in conjunction with Euro MPI 2013) full day Wednesday-Friday Reason: keep connection to EuroMPI, meeting is before EuroMPI based on preference of EuroMPI organizers December 9 - 12, 2013 Chicago, IL, USA - tentative mid Monday to mid Thursday we are waiting for confirmation if we have the rooms in Chicago, also we are waiting on feedback whether anyone is aware of any conflicts - the idea is to finalize this in the next 1-2 weeks (hence, if you see any conflicts, please mention them soon) After that, the plan is to continue with four meetings per year alternating between San Jose and Chicago, but keep the September meeting with the MPI conference. Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [Mpi-forum] MPI-3 svn branch does not build
by Jeff Hammond 05 Dec '12

05 Dec '12

"make allversions" jeff On Wed, Dec 5, 2012 at 2:46 PM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: > > I tried building this branch: > > https://svn.mpi-forum.org/svn/mpi-forum-docs/approved/MPI-3.0/ > > When I do "make", it doesn't build correctly. "make cleandoc" works fine. > > Should we be using a copy of this branch for future changes (e.g., > errata, etc.)? > > -- 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 -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

MPI-3 svn branch does not build
by Pavan Balaji 05 Dec '12

05 Dec '12

I tried building this branch: https://svn.mpi-forum.org/svn/mpi-forum-docs/approved/MPI-3.0/ When I do "make", it doesn't build correctly. "make cleandoc" works fine. Should we be using a copy of this branch for future changes (e.g., errata, etc.)? -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [Mpi-forum] Errata handling
by Jeff Hammond 05 Dec '12

05 Dec '12

Errata do not, by definition, require a new printing [http://en.wikipedia.org/wiki/Erratum] I cannot recount the proper citation, but I believe that it has been stated that the printed standard is not official. I totally love the book and when errata are approved, I will print them, fold them in half and put them inside of the jacket of the book, which is _exactly_ what is meant by errata. The approval of errata should not in any way invalidate your (Rolf's) printing effort and people should not view them as mutually exclusive concepts. Best, Jeff On Wed, Dec 5, 2012 at 2:04 PM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > Additionally, I must say that an MPI-3.0.1 would be directly > against the final result of the discussion from last meeting. > We said that a standard must have a meaningful stability > of at least two years. > I do not want to reopen this discussion, but based on exactly > this result, our center decided to take the risk to print > the MPI-3.0 and to sell it at costs as a service for the > whole MPI community. > We had to print all books for the next two years and to pay them. > Print-on-demand has shown that it does not work with 852 > pages in hardcover. > > An MPI-3.0.1 would completely kill this service combined with > a significant loss. > Result: Errata should never touch the numbering of our standard. > > I hope that the whole Forum supports our print service > and does not continue with this errata numbering discussion. > > Best regards > Rolf > > Sorry Tony, > > but in the past we did errata without incrementing anything, > and it worked. > Errata change the original document because there is a bug > that must be fixed. Only this bug is fixed. > Errata never change the title page of a document, > and MPI-3.0 from Sep 21, 2012 is part of the title page > and this is not a bug, therefore not changed by errata. > > If an implementor did not detect an inconsistency and > implemented something that is wrong, then it is a bug in his > software and it needs to be fixed, latest when the > errata is voted in, better when the inconsistency is > reolved by the chapter committee and published in a ticket. > The software is always MPI-3.0 compliant, but with some bugs. > > Please keep it simple! > > Best regards > Rolf > > ----- Original Message ----- >> From: "Anthony Skjellum" <tony(a)cis.uab.edu> >> To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >> Sent: Wednesday, December 5, 2012 6:42:07 PM >> Subject: Re: [Mpi-forum] Errata handling >> We need to increment the third digit of the standard each time errata >> are accepted in this way. >> "3.0 + errata compliant" is too vague. >> >> >> ----- Original Message ----- >> From: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> >> To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> >> Sent: Wednesday, December 5, 2012 11:23:56 AM >> Subject: [Mpi-forum] Errata handling >> >> Dear all, >> >> I detected that there seems to be a discussion. >> >From my viewpoint based on experience since MPI-2.0, >> the processing should be very simple and clear: >> >> - only important errata are published, not the typos. >> - important is that the interface was definitely inconsistent >> or obviously wrong. >> - enough review by committee members, i.e., it is clear that >> the correction is correct. >> - real reading in the forum, because it is about the interface. >> - single reading + vote for corrections of inconsistencies. >> >> Errata should pass always in the next meeting after they >> were detected. >> >> Errata are voted and "3.0 compiant" always means 3.0+errata compliant. >> Errata are for obvious bugs and inconsistencies. >> >> Reason: >> - Being compliant to a bug is stupied and must be corrected >> as soon as detected. >> (Example: It was never intented that you are MPI-2.2 compliant >> when having BOOL with 4 bytes in the external32 datarep.) >> - Being compliant to an inconsistency is impossible, >> because MPI-3.0 says A and not-A; >> you can never be compliant to both A and not-A. >> >> There should be only ONE errata document, which is >> updated after each meeting if new errata are added. >> The errata should be sorted by page and linenumbers in MPI-3.0. >> >> By this, there are older versions (visible at the date) >> of the errata document, but only the newest is binding. >> >> If we want to have the history in, we can add for each >> erratum the following parantheses: >> >> "(detected in ticket #nnn on May 1, 2099, voted in on Jun 16, 2099)". >> >> Because we always should try to circulate errata in a ticket, >> all implementors have early access to the information. >> It should be voted in in the same meeting as it was read. >> That's enough. This should need 30-60 minutes in a forum meeting. >> That's fast compared to a lot of emailing or email-voting. >> >> That's the way we did it in the past for all corrections >> in the voted Fortran interface - and it worked. >> >> My strong recommendation: >> - Do it simple and effective! >> - And start it now! >> - Use the meeting time for content of the MPI standard >> and not for complicating the errata process. >> >> Best regards >> Rolf >> >> -- >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de >> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 >> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 >> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner >> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Room 1.307) >> _______________________________________________ >> 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 > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Room 1.307) > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0