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

Re: [Mpi-forum] Updated agenda
by Jeffrey Squyres 28 Feb '12

28 Feb '12

Rich -- It doesn't mention it specifically on the agenda, but we agreed to have (pizza?) Forum/working dinner on Monday night, right? Same thing on Tuesday? On Feb 28, 2012, at 11:30 AM, Graham, Richard L. wrote: > The agenda for next weeks meeting has been updated. I believe I captured all the recent requests, but please check to make sure I have not missed your request. > > Thanks, > Rich > _______________________________________________ > 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

Updated agenda
by Graham, Richard L. 28 Feb '12

28 Feb '12

The agenda for next weeks meeting has been updated. I believe I captured all the recent requests, but please check to make sure I have not missed your request. Thanks, Rich

1 0

Fault Tolerance Readings
by Josh Hursey 27 Feb '12

27 Feb '12

The Fault Tolerance Working Group has a session from 1-6 pm on March 5, 2012 during which we will have a formal reading of two FT related tickets, linked below. User-Level Failure Mitigation: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/323 Clarify MPI_ERRORS_ARE_FATAL scope of abort: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/324 The working group will be providing an overview of the User-Level Failure Mitigation proposal followed by the first reading. Thanks, Josh -- Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey

1 0

Re: [Mpi-forum] Agenda corrections needed - Re: March MPI Forum meeting
by Josh Hursey 27 Feb '12

27 Feb '12

#276 is being held back by the FT working group for rework. #323 is going to be read in its stead. -- Josh On Sun, Feb 26, 2012 at 9:03 PM, Jim Dinan <dinan(a)mcs.anl.gov> wrote: > On 02/26/2012 11:47 AM, Torsten Hoefler wrote: > > 283 - not sure why this is assigned to me here, it's Jim's ticket > > The ticket 283 reading is assigned to Bill on the agenda -- should be > assigned to me. > > I also have to read ticket 0 changes to tickets 286 and 305 before the > first vote. This might be a stretch in the time currently allocated. > > ~Jim. > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > -- Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey

1 0

MPI-3 Fortran implementation now available
by Jeffrey Squyres 27 Feb '12

27 Feb '12

Yay! More information is available here: http://blogs.cisco.com/category/performance/ -- 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] Agenda corrections needed - Re: March MPI Forum meeting
by Jim Dinan 26 Feb '12

26 Feb '12

On 02/26/2012 11:47 AM, Torsten Hoefler wrote: > 283 - not sure why this is assigned to me here, it's Jim's ticket The ticket 283 reading is assigned to Bill on the agenda -- should be assigned to me. I also have to read ticket 0 changes to tickets 286 and 305 before the first vote. This might be a stretch in the time currently allocated. ~Jim.

1 0

Re: [Mpi-forum] Missing array size information in MPI_WAITSOME and MPI_TESTSOME
by Jeff Hammond 26 Feb '12

26 Feb '12

I agree that it isn't very clear, but I would use the following as my guide for what the length of array_of_statuses needs to be: "The error-free execution of MPI_WAITALL(count, array_of_requests, array_of_statuses) has the same effect as the execution of MPI_WAIT(&array_of_request[i], &array_of_statuses[i]), for i=0 ,..., count-1, in some arbitrary order. MPI_WAITALL with an array of length one is equivalent to MPI_WAIT." [top of page 60 in mpi22-report.pdf] Furthermore: "When one or more of the communications completed by MPI_WAITSOME fails, then it is desirable to return specific information on each communication. The arguments outcount, array_of_indices and array_of_statuses will be adjusted to indicate completion of all communications that have succeeded or failed." [bottom of page 61 in mpi22-report.pdf] One has to assume that all communications could succeed or fail prior to a call to MPI_WAITSOME, therefore, one has to provide an array of length incount. It does bother me that "The arguments outcount, array_of_indices and array_of_statuses will be adjusted to indicate completion of all communications that have succeeded or failed," does not scope how the implementation may adjust these arguments. Is it permitted to call realloc and shrink array_of_indices and array_of_statuses? If the arguments are OUT, does one even have to allocate memory for them, or will the implementation test for nullity and allocate the memory internally? So yeah, I think you've identified a problem, but I only read the text twice. Some parts of the standard have to be read at least ten times in a variety of mental states before they can be understood. I found that heavy use of peyote was necessary to understand the RMA chapter :-) Best, Jeff On Sun, Feb 26, 2012 at 12:53 PM, Jeremiah Willcock <jewillco(a)osl.iu.edu> wrote: > The documentation in the MPI 2.2 standard and the latest public 3.0 draft do > not say how long the output arrays array_of_indices and array_of_statuses > should be, and the example there does not show the declarations of the > arrays that it passes in. ï¿½A reader can probably infer that they need to be > at least incount elements long, but that is not obvious from the text. > > -- Jeremiah Willcock > _______________________________________________ > 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/old/index.php/User:Jhammond https://wiki-old.alcf.anl.gov/index.php/User:Jhammond

1 0

Re: [Mpi-forum] Process for chapter committee handling
by William Gropp 26 Feb '12

26 Feb '12

Rolf, I think the document is pretty good, and provides the right balance of process on the approvals (at least chapter votes) and flexibility for the development of both new material and making minor corrections. The ticket system is ok for tracking major issues but is overly heavy for minor fixes. Even requiring color/change bar updates adds significant and frankly unnecessary overhead when applied to things like the examples (resulting, for example, in a defective patch from MPI 2.2 to MPI 3.0 that caused a number of the examples to be skipped by the code checking utility). And most importantly, the tickets have often focused attention on a few lines of text, resulting in mistakes, sometimes serious, when the context is not considered. This is why it is so essential to have the chapters considered as a whole, with the chapter committees, as Rich suggests, working out how they will track their todo list on their own. One way to handle the existing tickets that really should be considered by the chapter committee might be to simply mark it as transferred to the chapter committee. As part of the final chapter vote, the chapter committee should review and provide a summary to the Forum about the changes. Bill On Feb 26, 2012, at 6:43 AM, RICHARD GRAHAM wrote: > Rolf, > All changes that go into the standard must be voted on by the whole forum. For ticket 0 items, this can be at the final chapter vote - it is really up to the chapter committees. Personally, as responsible for the ptp chapter, I plan to bring this forward one or two meetings before the final vote, so that there can be discussion by those that care a lot about detailed wording. Actually, I am going to be removing the ptp chapter ticket-0 items from the agenda for this meeting, and putting these into a single ticket, most likely to be handled at the following meeting - have been on foreign travel for 3 weeks, so have not had much time to work on this over the last month. I do not know if other chapter authors have similar intents. > > As for how each committee handles this, this is really up to them - we do not need to micro-manage how each group wants to operate. I have had people over the years (yes years) send me small changes, and plan to pull these together in the near future (not before the meeting next week), and then will send a note out to all the ptp chapter committee members asking for their comments/reviews/.... > > Rich > > > > Date: Fri, 24 Feb 2012 23:32:18 +0100 > > From: rabenseifner(a)hlrs.de > > To: wgropp(a)uiuc.edu > > CC: mpi-forum(a)lists.mpi-forum.org > > Subject: [Mpi-forum] Process for chapter committee handling > > > > Bill, > > > > I would like to get your opinion about following process problem: > > > > http://meetings.mpi-forum.org/standardization_process_3.pdf > > describes the two processes for > > - "handled by the chapter committee", and > > - handled by "formal reading plus two votes". > > > > The relation of our ticket-system to "formal reading plus two votes" > > is self explaining. > > > > The way of ticket-0 (i.e., grammer, type, formatting) changes is also > > clear: > > - no ticket > > - goes directly into approved > > - will be read one meeting before chapter vote > > (we will search for "ticket0" in the pdf) > > - and is voted in by final chapter vote. > > > > If a ticket-0 content has already a ticket number, the typically > > path may be: > > - The chapter author takes the obvious content directly into > > the approved source trunk as ticket-0, > > - He adds a comment to the ticket that it is taken as ticket-0 > > and already included into the approved trunk, > > - and he withdraws the original ticket. > > Of course, such a ticket should never been withdrawn > > before the ticket content is taken into the approved trunk. > > It can be handled also with the method described below for small corrections. > > > > How are small clarifications handled through our ticket system, > > i.e., those clarifications that should keep there ticket number. > > > > Which is the process for those tickets "handled by the chapter committee"? > > The current way of withdrawing and probably forgetting for ever > > is not a good process. > > > > Should we add two additional values for priority: > > - instead of Scheduled: > > -- Scheduled (for forum) > > -- Scheduled (for chapter committee) > > - instead of Passed > > -- Passed by forum > > -- Passed by chapter committee > > > > Then we have a clear process with two possibilities > > - Scheduled (for forum) > > - Had 1st reading > > - Had 1st vote > > - Passed by forum > > or > > - Scheduled (for chapter committee) > > - Passed by chapter committee > > > > Our rules at > > http://meetings.mpi-forum.org/standardization_process_3.pdf > > require that all changes not yet voted are read before the > > meeting with the chapter-vote: > > "All the minor and medium changes that have not been voted so far." > > > > Should we mark these tickets that are "handled by the chapter > > committee" somehow that we can go through these tickets very simple, > > e.g., with 0.275 instead of 275. > > Then we need only look for all ticket0 to find ticket0 and ticket0.275. > > > > I.e., all tickets in status "Passed by chapter committee" > > must have ticket 0.nnn numbers in the latex source. > > > > All other tickets have their original number in the latex source. > > > > What do you think about? > > > > Best regards > > Rolf > > > > > > ----- Original Message ----- > > > From: "William Gropp" <wgropp(a)illinois.edu> > > > To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > > > Sent: Friday, February 24, 2012 8:23:56 PM > > > Subject: Re: [Mpi-forum] Agenda corrections needed - Re: March MPI Forum meeting > > > > > > 275 is exactly the sort of thing better handled by the chapter > > > committee (unintentionally included Complex with types allowed for > > > Compare and Swap). > > > > > > Bill > > > > > > -- > > 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: Allmandring 30) > > _______________________________________________ > > 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 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

1 0

Missing array size information in MPI_WAITSOME and MPI_TESTSOME
by Jeremiah Willcock 26 Feb '12

26 Feb '12

The documentation in the MPI 2.2 standard and the latest public 3.0 draft do not say how long the output arrays array_of_indices and array_of_statuses should be, and the example there does not show the declarations of the arrays that it passes in. A reader can probably infer that they need to be at least incount elements long, but that is not obvious from the text. -- Jeremiah Willcock

1 0

Re: [Mpi-forum] Agenda corrections needed - Re: March MPI Forum meeting
by Torsten Hoefler 26 Feb '12

26 Feb '12

> Many tickets on the agenda are not scheduled for the meeting > "Chicago 2012/03/05" or are not yet ready. > > > Tickets that may still need work before official formal reading: > ---------------------------------------------------------------- > Torsten Hoefler - 275 283 300 163 264 275 - withdrawn after discussion 283 - not sure why this is assigned to me here, it's Jim's ticket 300 - implemented and attached. I actually think we should remove this ticket and merge it with the ticket 0 items! 163 - well, we discussed this at the last collectives WG call (Christian and I were alone on this call) and decided that we would postpone this to a discussion with more folks (i.e., at the next Forum). That's why it is scheduled with "Forum feedback requested". But at the last Forum, we decided that we didn't have enough time to go through the open items, well ;-). So please add it (and probably all other in this status) to the agenda if possible. 264 - Rich requested to postpone it by one meeting because he needed more time to investigate alternatives. We should have the best possible interface and agreed to postpone. This is set to be reread at the May meeting (not sure if it makes MPI-3.0 or MPI-3.1). I will make sure that we have all (small/trivial) changes ready before the March meeting so we can all decide what to do with it. > Torsten Hoefler - 300 264 163 Remember, I'll not be around on Tuesday. Thanks for your work Rolf! All the Best, Torsten -- bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- Torsten Hoefler | Performance Modeling and Simulation Lead Blue Waters Directorate | University of Illinois (UIUC) 1205 W Clark Street | Urbana, IL, 61801 NCSA Building | +01 (217) 244-7736

1 0