<HTML>
<HEAD>
<TITLE>Re: [Mpi-21] TODO - AUTHORS of MPI-2.1 - Workplan</TITLE>
</HEAD>
<BODY>
<FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'>2.1 we do expect to have a somewhat short lifetime, depending on what<BR>
happens with MPI 2.2 and 3.0. However, this is the base for future revisions<BR>
of the standard, so I think that it is worth slipping this schedule a bit so<BR>
that we have a firm base to build on. The document will never be perfect,<BR>
and this is not what we should strive for, but we should strive to have it be<BR>
in a form that someone can pick up the document and implement the<BR>
standard correctly.<BR>
<BR>
I will also add that I have talked with some who have committed to do a<BR>
major portion of work for 2.1 who simply do not have the cycles to do this <BR>
for several weeks. I am in the same situation.<BR>
<BR>
Rich<BR>
<BR>
<BR>
On 4/3/08 8:09 AM, "Rolf Rabenseifner" <rabenseifner@hlrs.de> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'>Hi all,<BR>
<BR>
yes, we need a decision as soon as possible.<BR>
<BR>
But first, it may be necessary to remove a wrong argument:<BR>
- The standard will have 6 month lifetime, not more!<BR>
- MPI 2.1 has to major goals:<BR>
- make Ballots 1-4 as part of the official standard,<BR>
- reduce the number of documents to one.<BR>
All rest is nice to have - not a major goal.<BR>
Until next Friday, only secure changes to intoductional text parts<BR>
should be done. More must be moved to MPI-2.2.<BR>
<BR>
To have a monolithic MPI standard document can be added to the agenda<BR>
of MPI-2.2.<BR>
<BR>
Here the official Scope of Effort as defined in January (see protocol):<BR>
<BR>
Scope of Effort:<BR>
- Clarification to the MPI standards document,<BR>
- resulting in a single document describing<BR>
the full MPI 2.1 standard.<BR>
- This includes merging of documents, text corrections, and added<BR>
clarifying text.<BR>
<BR>
All these three goals are achieved!<BR>
Current task is only to clean up small things, mainly (March protocol):<BR>
<BR>
Additional text-merge round with dedicated chapter authors.<BR>
Goal:<BR>
- Remove references to MPI-1 and MPI-2.<BR>
- Substitute by MPI.<BR>
- Necessary modifications to achieve this goal.<BR>
<BR>
MPI-2.2 can do it better in 6 month.<BR>
The MPI-2.2 for this can start about 3 weeks after April meeting.<BR>
<BR>
I hope, you all can live with this decisions.<BR>
(My work time is limited; this is another reason why I cannot<BR>
accept a delay in the delivery of MPI-2.1)<BR>
<BR>
Bronis and George,<BR>
<BR>
my general statements do not answer you initial question:<BR>
If you decide to move parts from Chap.11 to Chap.7,<BR>
then you both mus discuss this. You both are responsible<BR>
for these chapters.<BR>
And you should first convince your reviewers:<BR>
- Chap. 7: Rich, Jesper, Steve, Kannan, David, Bill<BR>
- Chap.11: Bill and Rainer<BR>
My recommendation:<BR>
Express clearly which parts should be moved exactly to wich line<BR>
(all based on page/line numbers as **printed** in Draft Apr. 1, 2008).<BR>
<BR>
Jeff,<BR>
<BR>
The idea of moving significant parts of Chap. 13 into Terms is<BR>
absolutely against the spirit of how this document is written.<BR>
The author tried to have only absolute necessary information<BR>
before the fist MPI example on page 25 (In MPI-1, it was page 16).<BR>
The MPI-2 Forum decided to put all the more detailed information<BR>
into extra sections, and especially binding stuff at the end of<BR>
the standard.<BR>
I put the Profiling behind Binding (this may be a fault).<BR>
<BR>
C and Fortran have the clear advantage that all constants<BR>
have the same name as the language-independently defined name,<BR>
e.g. MPI_COMM_WORLD, MPI_INT, MPI_SUCCESS... .<BR>
<BR>
For MPI-2.1, I would keep it as it is.<BR>
In MPI-2.2, there will be a longer discussion on C++ issues.<BR>
<BR>
Best regards<BR>
Rolf<BR>
<BR>
<BR>
On Thu, 3 Apr 2008 09:28:08 +0100<BR>
"Supalov, Alexander" <alexander.supalov@intel.com> wrote:<BR>
> Hi,<BR>
><BR>
> Whatever the decision will be, we need it now. We're close to the point<BR>
> of no return for the September deadline.<BR>
><BR>
> Best regards.<BR>
><BR>
> Alexander<BR>
><BR>
> -----Original Message-----<BR>
> From: Jesper Larsson Traeff [<a href="mailto:traff@it.neclab.eu]">mailto:traff@it.neclab.eu]</a><BR>
> Sent: Thursday, April 03, 2008 9:26 AM<BR>
> To: Bronis R. de Supinski<BR>
> Cc: Supalov, Alexander; Rolf Rabenseifner; William Gropp; Tony Skjellum;<BR>
> Rich Graham; Adam Moody; Richard Treumann; George Bosilca; David Solt;<BR>
> Rajeev Thakur; Jeff Squyres; MPI 2.1 Mailing List<BR>
> Subject: Re: TODO - AUTHORS of MPI-2.1 - Workplan<BR>
><BR>
><BR>
> Dear All,<BR>
><BR>
> I agree with the comments of Bronis about datatypes - functionality<BR>
> that belongs together should be together in the STANDARD! (which is what<BR>
> we<BR>
> are writing). To me it seems that this 2.1 is somewhat more than the<BR>
> "merge" it was optimistically intended to be. Since this, as Bronis<BR>
> says, will likely be THE STANDARD for years to come, and the entry point<BR>
> for many new users, I think it is important that we get it right the<BR>
> first time, and I believe this is possible (if not, we should abort the<BR>
> attempt). It's good to have strict deadlines, but let's not be fanatical<BR>
><BR>
> about that. I don't see any purpose whatsoever in putting out<BR>
> intermediate<BR>
> versions of 2.1 - as long as we are in limbo, 1.3 and 2.0 will work<BR>
> perfectly, they have all the ballots included<BR>
><BR>
> I will try to send comments on/updates of my chapters (these will,<BR>
> I think/hope, not need so much) tomorrow/monday<BR>
><BR>
> best regards<BR>
><BR>
> Jesper<BR>
><BR>
> On Wed, Apr 02, 2008 at 02:26:13PM -0700, Bronis R. de Supinski wrote:<BR>
> ><BR>
> > All:<BR>
> ><BR>
> > I thoroughly agree with the sentiment that many expressed<BR>
> > that we are better off slipping the release of 2.1 two or<BR>
> > four months more in order to get it right than hurrying to<BR>
> > get it out the door. It is likely to be THE standard for<BR>
> > a fairly long time and having it broken to begin with does<BR>
> > not seem wise.<BR>
> ><BR>
> > Bronis<BR>
> ><BR>
> ><BR>
> > On Wed, 2 Apr 2008, Supalov, Alexander wrote:<BR>
> ><BR>
> > > Hi,<BR>
> > ><BR>
> > > We may want to reduce the number of top level sections in the<BR>
> standard.<BR>
> > > In my opinion that I expressed to Rolf a couple of weeks ago, quite<BR>
> a<BR>
> > > few sections, like the ones mentioned by Bronis, should rather<BR>
> belong to<BR>
> > > a big Miscellany chapter rather than figure up there by themselves.<BR>
> They<BR>
> > > may also be merged/reformed, too.<BR>
> > ><BR>
> > > However, this is going to be a bigger change than envisioned<BR>
> originally.<BR>
> > > I wonder whether we should decide right away whether we can afford<BR>
> this<BR>
> > > now without slipping the planned MPI-2.1 delivery in September. A<BR>
> > > possible way would be to fix small things now and do second pass of<BR>
> > > major edits/reshuffling in MPI-3, or MPI-2.2, for that matter.<BR>
> > ><BR>
> > > Best regards.<BR>
> > ><BR>
> > > Alexander<BR>
> > ><BR>
> > > -----Original Message-----<BR>
> > > From: Bronis R. de Supinski [<a href="mailto:bronis@llnl.gov]">mailto:bronis@llnl.gov]</a><BR>
> > > Sent: Wednesday, April 02, 2008 11:15 PM<BR>
> > > To: Rolf Rabenseifner<BR>
> > > Cc: William Gropp; Tony Skjellum; Rich Graham; Adam Moody; Richard<BR>
> > > Treumann; Jespar Larsson Traeff; George Bosilca; David Solt; Rajeev<BR>
> > > Thakur; Jeff Squyres; Supalov, Alexander; MPI 2.1 Mailing List<BR>
> > > Subject: Re: TODO - AUTHORS of MPI-2.1 - Workplan<BR>
> > ><BR>
> > ><BR>
> > ><BR>
> > > Rolf:<BR>
> > ><BR>
> > > I have not gone through Chapter 11 thoroughly yet but I have<BR>
> > > already noticed some major changes that I would suggest.<BR>
> > ><BR>
> > > First Section 11.6: "Decoding a Datatype" seems out of place<BR>
> > > in the merged document. It would make sense to me to have all<BR>
> > > of the datatype functions together. If we don't make datatypes<BR>
> > > a separate chapter, then this section (11.6) should be moved<BR>
> > > into chapter 3, near section 3.12: "Derived Datatypes". Ideally,<BR>
> > > it would be merged into that section since it is clearly part<BR>
> > > of that functionality.<BR>
> > ><BR>
> > > Second, Section 11.5: "Error Classes, Error Codes, and Error<BR>
> > > Handlers" is strongly related to Section 7.3: "Error Handling",<BR>
> > > and Section 7.4: "Error Codes and Classes". Clearly, these<BR>
> > > sections should be merged. In fact, this overlap makes me ask<BR>
> > > why have we not merged Chapters 7 and 11? What is the difference<BR>
> > > between "Environmental Management" and "External Interfaces"?<BR>
> > ><BR>
> > > I think this question needs to be resolved before I go further<BR>
> > > on working on Chapter 11. Perhaps George and I should coordinate<BR>
> > > merging these chapters after I coordinate moving the datatype<BR>
> > > decoding functionality into chapter 3 with Rich...<BR>
> > ><BR>
> > > Bronis<BR>
> > ><BR>
> > ><BR>
> > ><BR>
> > ><BR>
> > > On Wed, 2 Apr 2008, Bronis R. de Supinski wrote:<BR>
> > ><BR>
> > > ><BR>
> > > > Rolf:<BR>
> > > ><BR>
> > > > I have finished editing chapter 14: Profiling. I have<BR>
> > > > attached the modified prof.tex since I do not yet have<BR>
> > > > write access. More importantly, either there is a problem<BR>
> > > > with the 2.1 macros or I am doing something wrong (I think<BR>
> > > > it is the first but I am not LaTex fluent enough to be<BR>
> > > > certain). Specifically, the first letter of the word<BR>
> > > > following the end markers does not appear in the generated<BR>
> > > > PDF. I would appreciate it if you could look into which it is.<BR>
> > > ><BR>
> > > > Another observation is that the macro does not work around<BR>
> > > > empty sections. In particular, I tried to mark the section<BR>
> > > > that I moved with the macros, with the original text commented<BR>
> > > > out. I tried to do the same for some MPI-1.0 text that was<BR>
> > > > contradictory to or redundant with the text that I moved.<BR>
> > > > Having those empty macro regions caused the compile to fail.<BR>
> > > > It might be nice to have some way to flag the deleted text,<BR>
> > > > with the convention, at least for now, of just commenting<BR>
> > > > it out and not to delete it entirely from the file.<BR>
> > > ><BR>
> > > > Let me know if I am doing things right here and then I will<BR>
> > > > move on to fixing chapter 11: External Interfaces. Thanks,<BR>
> > > ><BR>
> > > > Bronis<BR>
> > > ><BR>
> > > ><BR>
> > > > On Wed, 2 Apr 2008, Rolf Rabenseifner wrote:<BR>
> > > ><BR>
> > > > > Dear Bill, Tony, Rich, Adam, Dick, Jesper, George, David,<BR>
> Bronis,<BR>
> > > > > Rajeev, Jeff, and Alexander,<BR>
> > > > ><BR>
> > > > > you are responsible for one ore more chapters of MPI-2.1 until<BR>
> the<BR>
> > > > > meeting.<BR>
> > > > ><BR>
> > > > > It is a tough schedule:<BR>
> > > > > -----------------------<BR>
> > > > ><BR>
> > > > > * Tues, April 1, my ROUND ONE is finished and the write token<BR>
> is<BR>
> > > > > logically passed to all chapter authors:<BR>
> > > > > - You have read access to the source (via SVN) and the<BR>
> > > pdf.<BR>
> > > > > - You have write access to your local SVN copy.<BR>
> > > > > - You will get write access to the SVN in a few days.<BR>
> > > > > * Fri., April 11, chapter authors have finished ROUND TWO.<BR>
> > > > > - This is a hard deadline (because I've to go on<BR>
> travel)<BR>
> > > > > * Sat., April 12, I will produce mpi-report.pdf as basis for<BR>
> review<BR>
> > > > > (I cannot do later, because April 14-17, I'm on travel)<BR>
> > > > > * Mon.-Thu., April 14-17, strong review by the reviewer group<BR>
> > > > > * Fri., April 18, reviews - if necessary must be included -<BR>
> > > > > by the chapter authors<BR>
> > > > > * Sat., April 19, I will produce final mpi-report.pdf<BR>
> > > > > which is basis for<BR>
> > > > > - final reviews through the reviewer group<BR>
> > > > > - official reading at the April 28-30, 2008 meeting.<BR>
> > > > > (I cannot do later because I'm on travel April 20-26)<BR>
> > > > ><BR>
> > > > > The goals of your work as chapter author:<BR>
> > > > > -----------------------------------------<BR>
> > > > ><BR>
> > > > > - Remove references to MPI-1 and MPI-2.<BR>
> > > > > - Substitute by MPI.<BR>
> > > > > - Necessary modifications to achieve this goal.<BR>
> > > > ><BR>
> > > > > With this, we should have a single MPI-2.1 standard that does<BR>
> > > > > not "know" the MPI-1 or MPI-2 history of individual functions.<BR>
> > > > ><BR>
> > > > > ** This should be mainly a task in the area of<BR>
> > > chapter-introductions.<BR>
> > > > > ** Please, never change the wording of function definitions.<BR>
> > > > ><BR>
> > > > > Exceptions:<BR>
> > > > > - There are routines that are deprecated and that are<BR>
> > > > > already referenced in a consistent way.<BR>
> > > > > My recommendation:<BR>
> > > > > Current wording:<BR>
> > > > > There are *new* function, and existing are now deprecated.<BR>
> > > > > Proposal:<BR>
> > > > > There are functions, and there exist also deprecated<BR>
> functions<BR>
> > > > > with (nearly) same functionality but deprecated due to some<BR>
> > > lack<BR>
> > > > > in the bindings (or functionality)<BR>
> > > > > - There is history information in the frontmatter.<BR>
> > > > > - there is a change-log annex with limited memory (only previous<BR>
> > > version)<BR>
> > > > ><BR>
> > > > > Technical editing rule:<BR>
> > > > > -----------------------<BR>
> > > > ><BR>
> > > > > You must identify all of your changes:<BR>
> > > > ><BR>
> > > > > a) new/modified wording - you are highlighting your new/modified<BR>
> > > wording with:<BR>
> > > > ><BR>
> > > > > \mpiiidotiMergeNEWforSINGLEbegin% MPI-2.1 round-two - begin of<BR>
> > > modification<BR>
> > > > > .... your modified / new wording ....<BR>
> > > > > \mpiiidotiMergeNEWforSINGLEendI% MPI-2.1 round-two - end of<BR>
> > > modification<BR>
> > > > ><BR>
> > > > > b) Moved paragraphs, sentences, ... - you are highlighting the<BR>
> first<BR>
> > > word<BR>
> > > > > of the moved text with:<BR>
> > > > ><BR>
> > > > > \mpiiidotiMergeNEWforSINGLEbegin% MPI-2.1 round-two - begin of<BR>
> > > text-move<BR>
> > > > > First-word<BR>
> > > > > \mpiiidotiMergeNEWforSINGLEendI% MPI-2.1 round-two - ongoing<BR>
> > > text-move<BR>
> > > > > ... rest of the moved text....<BR>
> > > > > % MPI-2.1 round-two - end of text-move<BR>
> > > > ><BR>
> > > > > Caution: These macros work only in black parts of the text.<BR>
> > > > ><BR>
> > > > > In blue parts you must substitute<BR>
> > > > > \mpiiidotiMergeNEWforSINGLEendI%<BR>
> > > > > by<BR>
> > > > > \mpiiidotiMergeNEWforSINGLEendII%<BR>
> > > > ><BR>
> > > > > The highlighting is done with red color.<BR>
> > > > > (There are only a few other sentences from me magenta.<BR>
> > > > > Therefore red should be the best to highlight the round-two<BR>
> > > modifications.)<BR>
> > > > ><BR>
> > > > > Rsponsibilities:<BR>
> > > > > ----------------<BR>
> > > > ><BR>
> > > > > * Frontmatter mpi-report.tex Bill Gropp<BR>
> > > > > * Acknowledgements credits.tex Rich Graham(text) +<BR>
> > > Rolf(emails-auth.)<BR>
> > > > > * 1. Introduction intro.tex Bill Gropp<BR>
> > > > > - 2. Terms terms-2.tex Tony Skjellum<BR>
> > > > > * 3. Point-to-point pt2pt.tex Rich Graham<BR>
> > > > > * 4. Collectives coll.tex Adam Moody<BR>
> > > > > * 5. Groups, etc. context.tex Dick Treumann<BR>
> > > > > - 6. Toplogies topol.tex Jesper Traeff<BR>
> > > > > * 7. Environment inquiry.tex George Bosilca<BR>
> > > > > - 8. Miscellany misc-2.tex Jesper Traeff<BR>
> > > > > - 9. Process Crea... dynamic-2.tex David Solt<BR>
> > > > > - 10. One-sided Comm one-sided-2.tex Jepser Traeff<BR>
> > > > > - 11. External Int. ei-2.tex Bronis de Supinski<BR>
> > > > > - 12. IO io-2.tex Rajeev Thakur<BR>
> > > > > - 13. Lang.Binding binding-2.tex Jeff Squyres<BR>
> > > > > - 14. Profiling prof.tex Bronis de Supinski<BR>
> > > > > - 15. Deprecated deprecated.tex Rolf Rabenseifner<BR>
> > > > > - Annex A Lang.Bind. appLang*.tex, MAKE-APPLANG Alexander<BR>
> Supalov<BR>
> > > > > - Annex B Change-log changes.tex Rolf Rabenseifner<BR>
> > > > > - Bibliography refs.bib Bill Gropp<BR>
> > > > > - Index MAKE-FUNC-INDEX Rolf Rabenseifner<BR>
> > > > ><BR>
> > > > > Legende: - Chapter is mainly taken from MPI-1.1 or MPI-2.0,<BR>
> > > > > only small work expected<BR>
> > > > > * There was a significant merge, or new text, or ...,<BR>
> > > > > more work expected<BR>
> > > > ><BR>
> > > > > I wish you a good start and good luck with your chapter.<BR>
> > > > ><BR>
> > > > > Best regards<BR>
> > > > > Rolf<BR>
> > > > ><BR>
> > > > ><BR>
> > > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email<BR>
> > > rabenseifner@hlrs.de<BR>
> > > > > High Performance Computing Center (HLRS) . phone<BR>
> > > ++49(0)711/685-65530<BR>
> > > > > University of Stuttgart . . . . . . . . .. fax ++49(0)711 /<BR>
> > > 685-65832<BR>
> > > > > Head of Dpmt Parallel Computing . . .<BR>
> > > www.hlrs.de/people/rabenseifner<BR>
> > > > > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring<BR>
> 30)<BR>
> > > > ><BR>
> > ><BR>
> ---------------------------------------------------------------------<BR>
> > > Intel GmbH<BR>
> > > Dornacher Strasse 1<BR>
> > > 85622 Feldkirchen/Muenchen Germany<BR>
> > > Sitz der Gesellschaft: Feldkirchen bei Muenchen<BR>
> > > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer<BR>
> > > Registergericht: Muenchen HRB 47456 Ust.-IdNr.<BR>
> > > VAT Registration No.: DE129385895<BR>
> > > Citibank Frankfurt (BLZ 502 109 00) 600119052<BR>
> > ><BR>
> > > This e-mail and any attachments may contain confidential material<BR>
> for<BR>
> > > the sole use of the intended recipient(s). Any review or<BR>
> distribution<BR>
> > > by others is strictly prohibited. If you are not the intended<BR>
> > > recipient, please contact the sender and delete all copies.<BR>
> > ><BR>
> > ><BR>
> ---------------------------------------------------------------------<BR>
> Intel GmbH<BR>
> Dornacher Strasse 1<BR>
> 85622 Feldkirchen/Muenchen Germany<BR>
> Sitz der Gesellschaft: Feldkirchen bei Muenchen<BR>
> Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer<BR>
> Registergericht: Muenchen HRB 47456 Ust.-IdNr.<BR>
> VAT Registration No.: DE129385895<BR>
> Citibank Frankfurt (BLZ 502 109 00) 600119052<BR>
><BR>
> This e-mail and any attachments may contain confidential material for<BR>
> the sole use of the intended recipient(s). Any review or distribution<BR>
> by others is strictly prohibited. If you are not the intended<BR>
> recipient, please contact the sender and delete all copies.<BR>
><BR>
<BR>
<BR>
<BR>
Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner@hlrs.de<BR>
High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530<BR>
University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832<BR>
Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner<BR>
Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)<BR>
_______________________________________________<BR>
mpi-21 mailing list<BR>
mpi-21@lists.mpi-forum.org<BR>
<a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21</a><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'><BR>
</SPAN></FONT>
</BODY>
</HTML>