October 2010 - mpiwg-tools - mailman3.cels.anl.gov

Re: [Mpi3-tools] New version of the MPIT Document
by Marc-André Hermanns 10 Oct '10

10 Oct '10

Hi Martin, I seemed to have missed the discussion of the snowbird comments. Do you have some notes in electronic form that you could share. It would make it easier to read the new document to see how they relate to the comments. Cheers, Marc-Andre On 08.10.2010, at 23:13, Martin Schulz wrote: > Hi all, > > Attached is the new draft of the MPIT proposal for our discussion > next week in Chicago (during the Tuesday morning WG session). > This ended up being almost a complete rewrite and hence I didn't > use change bars this time - just assume that everything is new :). > > The text now includes the outcome of the discussions we had within > the WG as well as the extensive feedback I got from the tools > community at a workshop in the summer (and that we discussed > a few weeks back). > > A few items remain to be done and those are listed at the > beginning of the chapter. I would like to go over those during > the meeting as well and see if we can resolve them. > > Let me know if you have any questions or any immediate > feedback - otherwise we can address the rest next week. > > Thanks, > > Martin > > PS: I will also post this to the WiKi in a moment and check it > into the SVN repository. > > <mpi-report.pdf> > ________________________________________________________________________ > Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm > CASC @ Lawrence Livermore National Laboratory, Livermore, USA > > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools -- Marc-Andre Hermanns German Research School for Simulation Sciences GmbH c/o Laboratory for Parallel Programming 52056 Aachen | Germany Tel +49 241 80 99753 Fax +49 241 80 6 99753 Web www.grs-sim.de Members: Forschungszentrum Jülich GmbH | RWTH Aachen University Registered in the commercial register of the local court of Düren (Amtsgericht Düren) under registration number HRB 5268 Registered office: Jülich Executive board: Prof. Marek Behr Ph.D. | Dr. Norbert Drewes

1 0

[Mpi3-tools] New version of the MPIT Document
by Martin Schulz 08 Oct '10

08 Oct '10

Hi all, Attached is the new draft of the MPIT proposal for our discussion next week in Chicago (during the Tuesday morning WG session). This ended up being almost a complete rewrite and hence I didn't use change bars this time - just assume that everything is new :). The text now includes the outcome of the discussions we had within the WG as well as the extensive feedback I got from the tools community at a workshop in the summer (and that we discussed a few weeks back). A few items remain to be done and those are listed at the beginning of the chapter. I would like to go over those during the meeting as well and see if we can resolve them. Let me know if you have any questions or any immediate feedback - otherwise we can address the rest next week. Thanks, Martin PS: I will also post this to the WiKi in a moment and check it into the SVN repository. ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [Mpi3-tools] Fwd: [MPI Forum] #228: MPIR Specification - An Official Companion Document for the MPI Standard
by Supalov, Alexander 07 Oct '10

07 Oct '10

Thanks. We might want to add some language to the effect that mild syntactical variations on the current spec are OK (like const vs non-const in item 2), and that it's MPI and tool implementor's job to make sure variables are properly set and read even if VOLATILE expands to nothing. -----Original Message----- From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of John DelSignore Sent: Thursday, October 07, 2010 4:13 PM To: mpi3-tools(a)lists.mpi-forum.org Subject: Re: [Mpi3-tools] Fwd: [MPI Forum] #228: MPIR Specification - An Official Companion Document for the MPI Standard Jeff Squyres wrote: > Martin / John -- > > Can you comment on Alexander's comments? In-line below... > Begin forwarded message: > >> From: "MPI Forum" <mpi-22(a)lists.mpi-forum.org> >> Date: October 7, 2010 7:16:50 AM EDT >> Subject: Re: [MPI Forum] #228: MPIR Specification - An Official Companion Document for the MPI Standard >> >> #228: MPIR Specification - An Official Companion Document for the MPI Standard >> ---------------------------------------------------------+------------------ >> Reporter: schulzm | Owner: jsquyres >> Type: Enhancements to standard | Status: new >> Priority: Had 1st reading | Milestone: 2010/10/11 Chicago, USA >> Version: MPI 3.0 | Keywords: >> Implementation: Unnecessary | Author_bill_gropp: 0 >> Author_rich_graham: 0 | Author_adam_moody: 0 >> Author_torsten_hoefler: 0 | Author_dick_treumann: 0 >> Author_jesper_larsson_traeff: 0 | Author_george_bosilca: 0 >> Author_david_solt: 0 | Author_bronis_de_supinski: 0 >> Author_rajeev_thakur: 0 | Author_jeff_squyres: 0 >> Author_alexander_supalov: 0 | Author_rolf_rabenseifner: 0 >> ---------------------------------------------------------+------------------ >> >> Comment(by asupalov): >> >> We identified three possible issues in the current spec, see below. The MPIR document describes the how the original interface was implemented in MPICH-1 in the mid-1990's, plus modifications and extension that have been made to the interface over the past 10 to 15 years. What I have seen is that various MPI implementations choose implement the MPIR interface slightly differently, according to their own sense of style and to accommodate the various tool-chains (compiler, linker, etc.) they wish to support. So in that sense, there is no one "right way" to implement the interface. >> 1. The proposal requires the VOLATILE macro to be defined (p.15, top). Originally, the MPIR interface was compiled with compilers that did not support the volatile keyword. To accommodate those compilers, the interface did not require that the MPIR variables be declared volatile. So, the interface defined the VOLATILE macro so that an MPI implementation could exclude the volatile keyword if it knew that the compiler and hardware did not require it to properly read and write the MPIR variables. >> What happens if VOLATILE expands to nothing? Either the right thing or the wrong thing. It depends on the compiler, hardware, and debugger tracing interface. All of the compilers/hardware combinations I've dealt with so far seem to properly read/write the MPIR variables from/to memory, probably because: (a) they are all global variable, (b) the debug interface has to be compiled for debugging and is typically not optimized, and (c) the MPI starter process is being traced by the debugger and that causes the caches to be flushed. >> How will the respective >> compiler understand that it should go down to the memory every time a >> variable is queried? Not our problem, but still. :) That's an implementation detail. It's the responsibility of the MPI implementation to make sure that: (a) when an MPIR variable is written by the MPI starter process that the debugger will read that value, and (b) when an MPIR variable is read by the MPI starter process it will read the value that is written by the debugger. In most implementations, nothing special needs to be done, but occasionally variable have to be declared volatile, or other special measures have to be taken to make sure the compiler or linker does not optimize out the variables. For example, some linkers are pretty smart and will optimize out variables that are not both read and written. >> 2. Intel MPI (and most likely MPICH2) has a bit different definition for >> MPIR_PROCDESC table (p.15, bottom). >> >> Our defition: >> typedef struct MPIR_PROCDESC { >> const char *host_name; >> const char *executable_name; >> int pid; >> } MPIR_PROCDESC; That's fine. The debugger needs to know two things about each of the fields: the offset of the field inside the structure, and the length of the field. The type of the host_name and executable_name fields is "pointer to const char" vs. "pointer to char", and the only thing the debugger needs to care about is offset/length of the pointer itself. Unless the debugger is being super paranoid or super stupid, it doesn't need to care about target type of the pointer. A debugger worth its salt won't get tripped up by the "const". >> Proposal: >> typedef struct MPIR_PROCDESC { >> char *host_name; >> char *executable_name; >> int pid; >> } MPIR_PROCDESC; Again, it's not a proposal. It more like recorded history and the state of current practice. >> Our definition seems to be more strict. I don't think this will cause any >> problem, but you may want to review this and allow for the above >> extension, as we'd not like to change the source code unless absolutely >> necessary. I wouldn't call this an extension, I'd call it a variation. Other variations are possible. For example, the order of the fields might be different, or there may be additional fields in the structure. I don't think the Intel MPI or MPICH2 needs to change the definition of the structure, and I don't think that the MPIR document needs to describe every possible variation of how the structure might be defined. >> 3. Same issue for MPIR_debug_state (p. 17, bottom). >> >> Our definition: >> volatile int MPIR_debug_state >> >> Proposal definition: >> int MPIR_debug_state >> >> This may be material, as the MPIR_debug_state is set by the program and >> inspected by the tool. We should probably add VOLATILE to the proposal. I think you're right, the document needs to be updated. I looked back at the original text document that described the interface, and it has: extern VOLATILE int MPIR_debug_state; See: http://www.mcs.anl.gov/research/projects/mpi/mpi-debug/attach.h.html and http://www.mcs.anl.gov/research/projects/mpi/mpi-debug/mpich-attach.txt Cheers, John D. >> -- >> Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/228#comment:3> >> MPI Forum <https://svn.mpi-forum.org/> >> MPI Forum > > _______________________________________________ Mpi3-tools mailing list Mpi3-tools(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools -------------------------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

1 0

Re: [Mpi3-tools] Fwd: [MPI Forum] #228: MPIR Specification - An Official Companion Document for the MPI Standard
by John DelSignore 07 Oct '10

07 Oct '10

Jeff Squyres wrote: > Martin / John -- > > Can you comment on Alexander's comments? In-line below... > Begin forwarded message: > >> From: "MPI Forum" <mpi-22(a)lists.mpi-forum.org> >> Date: October 7, 2010 7:16:50 AM EDT >> Subject: Re: [MPI Forum] #228: MPIR Specification - An Official Companion Document for the MPI Standard >> >> #228: MPIR Specification - An Official Companion Document for the MPI Standard >> ---------------------------------------------------------+------------------ >> Reporter: schulzm | Owner: jsquyres >> Type: Enhancements to standard | Status: new >> Priority: Had 1st reading | Milestone: 2010/10/11 Chicago, USA >> Version: MPI 3.0 | Keywords: >> Implementation: Unnecessary | Author_bill_gropp: 0 >> Author_rich_graham: 0 | Author_adam_moody: 0 >> Author_torsten_hoefler: 0 | Author_dick_treumann: 0 >> Author_jesper_larsson_traeff: 0 | Author_george_bosilca: 0 >> Author_david_solt: 0 | Author_bronis_de_supinski: 0 >> Author_rajeev_thakur: 0 | Author_jeff_squyres: 0 >> Author_alexander_supalov: 0 | Author_rolf_rabenseifner: 0 >> ---------------------------------------------------------+------------------ >> >> Comment(by asupalov): >> >> We identified three possible issues in the current spec, see below. The MPIR document describes the how the original interface was implemented in MPICH-1 in the mid-1990's, plus modifications and extension that have been made to the interface over the past 10 to 15 years. What I have seen is that various MPI implementations choose implement the MPIR interface slightly differently, according to their own sense of style and to accommodate the various tool-chains (compiler, linker, etc.) they wish to support. So in that sense, there is no one "right way" to implement the interface. >> 1. The proposal requires the VOLATILE macro to be defined (p.15, top). Originally, the MPIR interface was compiled with compilers that did not support the volatile keyword. To accommodate those compilers, the interface did not require that the MPIR variables be declared volatile. So, the interface defined the VOLATILE macro so that an MPI implementation could exclude the volatile keyword if it knew that the compiler and hardware did not require it to properly read and write the MPIR variables. >> What happens if VOLATILE expands to nothing? Either the right thing or the wrong thing. It depends on the compiler, hardware, and debugger tracing interface. All of the compilers/hardware combinations I've dealt with so far seem to properly read/write the MPIR variables from/to memory, probably because: (a) they are all global variable, (b) the debug interface has to be compiled for debugging and is typically not optimized, and (c) the MPI starter process is being traced by the debugger and that causes the caches to be flushed. >> How will the respective >> compiler understand that it should go down to the memory every time a >> variable is queried? Not our problem, but still. :) That's an implementation detail. It's the responsibility of the MPI implementation to make sure that: (a) when an MPIR variable is written by the MPI starter process that the debugger will read that value, and (b) when an MPIR variable is read by the MPI starter process it will read the value that is written by the debugger. In most implementations, nothing special needs to be done, but occasionally variable have to be declared volatile, or other special measures have to be taken to make sure the compiler or linker does not optimize out the variables. For example, some linkers are pretty smart and will optimize out variables that are not both read and written. >> 2. Intel MPI (and most likely MPICH2) has a bit different definition for >> MPIR_PROCDESC table (p.15, bottom). >> >> Our defition: >> typedef struct MPIR_PROCDESC { >> const char *host_name; >> const char *executable_name; >> int pid; >> } MPIR_PROCDESC; That's fine. The debugger needs to know two things about each of the fields: the offset of the field inside the structure, and the length of the field. The type of the host_name and executable_name fields is "pointer to const char" vs. "pointer to char", and the only thing the debugger needs to care about is offset/length of the pointer itself. Unless the debugger is being super paranoid or super stupid, it doesn't need to care about target type of the pointer. A debugger worth its salt won't get tripped up by the "const". >> Proposal: >> typedef struct MPIR_PROCDESC { >> char *host_name; >> char *executable_name; >> int pid; >> } MPIR_PROCDESC; Again, it's not a proposal. It more like recorded history and the state of current practice. >> Our definition seems to be more strict. I don't think this will cause any >> problem, but you may want to review this and allow for the above >> extension, as we'd not like to change the source code unless absolutely >> necessary. I wouldn't call this an extension, I'd call it a variation. Other variations are possible. For example, the order of the fields might be different, or there may be additional fields in the structure. I don't think the Intel MPI or MPICH2 needs to change the definition of the structure, and I don't think that the MPIR document needs to describe every possible variation of how the structure might be defined. >> 3. Same issue for MPIR_debug_state (p. 17, bottom). >> >> Our definition: >> volatile int MPIR_debug_state >> >> Proposal definition: >> int MPIR_debug_state >> >> This may be material, as the MPIR_debug_state is set by the program and >> inspected by the tool. We should probably add VOLATILE to the proposal. I think you're right, the document needs to be updated. I looked back at the original text document that described the interface, and it has: extern VOLATILE int MPIR_debug_state; See: http://www.mcs.anl.gov/research/projects/mpi/mpi-debug/attach.h.html and http://www.mcs.anl.gov/research/projects/mpi/mpi-debug/mpich-attach.txt Cheers, John D. >> -- >> Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/228#comment:3> >> MPI Forum <https://svn.mpi-forum.org/> >> MPI Forum > >

1 0

[Mpi3-tools] Fwd: [MPI Forum] #228: MPIR Specification - An Official Companion Document for the MPI Standard
by Jeff Squyres 07 Oct '10

07 Oct '10

Martin / John -- Can you comment on Alexander's comments? Begin forwarded message: > From: "MPI Forum" <mpi-22(a)lists.mpi-forum.org> > Date: October 7, 2010 7:16:50 AM EDT > Subject: Re: [MPI Forum] #228: MPIR Specification - An Official Companion Document for the MPI Standard > > #228: MPIR Specification - An Official Companion Document for the MPI Standard > ---------------------------------------------------------+------------------ > Reporter: schulzm | Owner: jsquyres > Type: Enhancements to standard | Status: new > Priority: Had 1st reading | Milestone: 2010/10/11 Chicago, USA > Version: MPI 3.0 | Keywords: > Implementation: Unnecessary | Author_bill_gropp: 0 > Author_rich_graham: 0 | Author_adam_moody: 0 > Author_torsten_hoefler: 0 | Author_dick_treumann: 0 > Author_jesper_larsson_traeff: 0 | Author_george_bosilca: 0 > Author_david_solt: 0 | Author_bronis_de_supinski: 0 > Author_rajeev_thakur: 0 | Author_jeff_squyres: 0 > Author_alexander_supalov: 0 | Author_rolf_rabenseifner: 0 > ---------------------------------------------------------+------------------ > > Comment(by asupalov): > > We identified three possible issues in the current spec, see below. > > 1. The proposal requires the VOLATILE macro to be defined (p.15, top). > What happens if VOLATILE expands to nothing? How will the respective > compiler understand that it should go down to the memory every time a > variable is queried? Not our problem, but still. :) > > 2. Intel MPI (and most likely MPICH2) has a bit different definition for > MPIR_PROCDESC table (p.15, bottom). > > Our defition: > typedef struct MPIR_PROCDESC { > const char *host_name; > const char *executable_name; > int pid; > } MPIR_PROCDESC; > > Proposal: > typedef struct MPIR_PROCDESC { > char *host_name; > char *executable_name; > int pid; > } MPIR_PROCDESC; > > Our definition seems to be more strict. I don't think this will cause any > problem, but you may want to review this and allow for the above > extension, as we'd not like to change the source code unless absolutely > necessary. > > 3. Same issue for MPIR_debug_state (p. 17, bottom). > > Our definition: > volatile int MPIR_debug_state > > Proposal definition: > int MPIR_debug_state > > This may be material, as the MPIR_debug_state is set by the program and > inspected by the tool. We should probably add VOLATILE to the proposal. > > -- > Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/228#comment:3> > MPI Forum <https://svn.mpi-forum.org/> > 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

[Mpi3-tools] Dialog about MPIT
by Marc-André Hermanns 06 Oct '10

06 Oct '10

Hi all, I contacted Carsten Claus, who presented the MPIT poster at the EuroMPI 2010. While he is currently very involved in other activities as the semester is about to start, he pointed out that this work is carried on by one of his students in a master's thesis (see http://www.lfbs.rwth-aachen.de/content/709) This student (Andreas Kuntze) plans to send me some initial thoughts some time next week. Cheers, Marc-Andre -- Marc-Andre Hermanns German Research School for Simulation Sciences GmbH c/o Laboratory for Parallel Programming 52056 Aachen | Germany Tel +49 241 80 99753 Fax +49 241 80 6 99753 Web www.grs-sim.de Members: Forschungszentrum Jülich GmbH | RWTH Aachen University Registered in the commercial register of the local court of Düren (Amtsgericht Düren) under registration number HRB 5268 Registered office: Jülich Executive board: Prof. Marek Behr Ph.D. | Dr. Norbert Drewes

1 0

[Mpi3-tools] Notes from today and link for next week
by Martin Schulz 04 Oct '10

04 Oct '10

Hi all, Thanks for the good discussion today - the notes are at the usual place on the Wiki. If there is something missing or if there is an additional topic that you would like to suggest for this group, please send email to the list. Talk to you all next week (Jeff has added the respective Webex link to the Wiki - thanks!), Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [Mpi3-tools] TelCon Monday 10/4 & Discussions at the MPI Forum
by Martin Schulz 04 Oct '10

04 Oct '10

Hi Marty, all, The information is on the Wiki in the usual place. It is: Monday, October 4, 2010, 11am US Eastern time / 8am US Pacific time Webex meeting: https://cisco.webex.com/ciscosales/j.php?ED=145066722&UID=0&PW=NZTg4YzQ5ZWN… Webex password: tools Talk to you soon, Martin On Oct 4, 2010, at 7:37 AM, Marty Itzkowitz wrote: > Where's the concall information for today's call? > > Thanks, > Marty > > On 10/2/10 8:13 AM, Martin Schulz wrote: >> >> (resending due to email problems - sorry if you get this twice) >> >> Hi all, >> >> Our next MPI tools TelCon is scheduled for this Monday 10/4 at >> the usual time of 8am PDT, 11am EDT, 5pm MSZ. >> >> Unfortunately, due to a few deadlines and other events I wasn't >> able to finish the new draft for the MPIT interface, yet. Hence, I >> am proposing to move this discussion to the face-to-face meeting >> the following week in Chicago. We have a two hour WG session >> scheduled for Tuesday 10/12 at 9am CDT (one hour earlier than >> usual) and I have asked Rich for a phone line so people can >> call in if they want to. >> >> As for the TelCon, I would propose to still hold it, at least to touch >> base. If anyone wants to bring up a particular topic, please let >> me know. Otherwise, I would like to discuss which next steps we >> should take for this WG. With the MPIR document in the voting >> phase and MPIT on the home stretch (hopefully), we should look >> at which topic(s) we want to attack next and how. >> >> Here is a list of possible topics that come to mind: >> - MPIR-2 >> - Documentation of the message queue interface >> - Documentation and/or standardization of other debugging >> interfaces like handle query or collective completion query >> - Extended MPI_Pcontrol >> >> Also, the FT group is still looking at the idea of adding a >> piggyback layer, which is also interesting for tools. >> >> Please feel free to comment or add to the list. >> >> Thanks and talk to you all on Monday, >> >> Martin >> >> >> ________________________________________________________________________ >> Martin Schulz, schulzm(a)llnl.gov, http://BLOCKEDpeople.llnl.gov/schulzm >> CASC @ Lawrence Livermore National Laboratory, Livermore, USA >> >> >> _______________________________________________ >> Mpi3-tools mailing list >> Mpi3-tools(a)lists.mpi-forum.org >> http://BLOCKEDlists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [Mpi3-tools] TelCon Monday 10/4 & Discussions at the MPI Forum
by Marty Itzkowitz 04 Oct '10

04 Oct '10

Where's the concall information for today's call? Thanks, Marty On 10/2/10 8:13 AM, Martin Schulz wrote: > (resending due to email problems - sorry if you get this twice) > > Hi all, > > Our next MPI tools TelCon is scheduled for this Monday 10/4 at > the usual time of 8am PDT, 11am EDT, 5pm MSZ. > > Unfortunately, due to a few deadlines and other events I wasn't > able to finish the new draft for the MPIT interface, yet. Hence, I > am proposing to move this discussion to the face-to-face meeting > the following week in Chicago. We have a two hour WG session > scheduled for Tuesday 10/12 at 9am CDT (one hour earlier than > usual) and I have asked Rich for a phone line so people can > call in if they want to. > > As for the TelCon, I would propose to still hold it, at least to touch > base. If anyone wants to bring up a particular topic, please let > me know. Otherwise, I would like to discuss which next steps we > should take for this WG. With the MPIR document in the voting > phase and MPIT on the home stretch (hopefully), we should look > at which topic(s) we want to attack next and how. > > Here is a list of possible topics that come to mind: > - MPIR-2 > - Documentation of the message queue interface > - Documentation and/or standardization of other debugging > interfaces like handle query or collective completion query > - Extended MPI_Pcontrol > > Also, the FT group is still looking at the idea of adding a > piggyback layer, which is also interesting for tools. > > Please feel free to comment or add to the list. > > Thanks and talk to you all on Monday, > > Martin > > > ________________________________________________________________________ > Martin Schulz, schulzm(a)llnl.gov <mailto:[email protected]>, > http://people.llnl.gov/schulzm > CASC @ Lawrence Livermore National Laboratory, Livermore, USA > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools

1 0

[Mpi3-tools] TelCon Monday 10/4 & Discussions at the MPI Forum
by Martin Schulz 02 Oct '10

02 Oct '10

(resending due to email problems - sorry if you get this twice) Hi all, Our next MPI tools TelCon is scheduled for this Monday 10/4 at the usual time of 8am PDT, 11am EDT, 5pm MSZ. Unfortunately, due to a few deadlines and other events I wasn't able to finish the new draft for the MPIT interface, yet. Hence, I am proposing to move this discussion to the face-to-face meeting the following week in Chicago. We have a two hour WG session scheduled for Tuesday 10/12 at 9am CDT (one hour earlier than usual) and I have asked Rich for a phone line so people can call in if they want to. As for the TelCon, I would propose to still hold it, at least to touch base. If anyone wants to bring up a particular topic, please let me know. Otherwise, I would like to discuss which next steps we should take for this WG. With the MPIR document in the voting phase and MPIT on the home stretch (hopefully), we should look at which topic(s) we want to attack next and how. Here is a list of possible topics that come to mind: - MPIR-2 - Documentation of the message queue interface - Documentation and/or standardization of other debugging interfaces like handle query or collective completion query - Extended MPI_Pcontrol Also, the FT group is still looking at the idea of adding a piggyback layer, which is also interesting for tools. Please feel free to comment or add to the list. Thanks and talk to you all on Monday, Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0