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

Re: [Mpi3-tools] Next MPI-3 Tools WG meeting Monday 8/26 + Schedule fornext meetings
by Dong H. Ahn 09 Aug '10

09 Aug '10

On 8/9/2010 11:19 AM, John DelSignore wrote: > Dong H. Ahn wrote: >> Hi John, >> >> I just looked at the revision and I think this addressed most of the >> issues I've raised except for the MPIR_attach_fifo support. > Sorry, I forgot about MPIR_attach_fifo. I had to scrounge around in my email to find the description. Here's what I have, from an email you sent on 7/9/10: > > ============================================= > ... I would also hope to > cover a recently implemented MPIR extension on OpenRTE/OpenMPI: > MPIR_attach_fifo support. > > ------- > > " > char MPIR_attach_fifo[256]; > > Definition is not required. > > Definition is contained within the address space of the starter process. > > Variable is written by the tool, and read by the starter process. > MPIR_attach_fifo is a null-terminated character string that is written by the tool into the > address space of the starter process. The string is the path name of a FIFO (named pipe). Writing a byte > into this FIFO will cause the starter process to start to monitor MPIR_being_debugged in attach mode. > " > ------- > > As part of LaunchMON/STAT OpenRTE/OpenMPI port, Ralph Castain reproduced > BlueGene's MPIR colocation extension but there was a performance > requirement of orterun that kept orterun from polling on the value > changes of MPIR_being_debugged for attach case by default. So we > addressed it by making orterun open up a FIFO and its comm thread block > on the FIFO along with other TCP channels; when a debugger attaches to > orterun and writes a byte into it, the starter process looks at > MPIR_being_debugger and performs the co-location service. > ============================================= > >> If it is >> missing from this revision because of a lack of technical details, Ralph >> and I should be able to provide them. > Given that I know zilch MPIR_attach_fifo, it would make sense for someone else (not me) to write-up the description and incorporate it into the document. Since it is an extension, I think it should be added in sections 7 and 9. Sections 7.3 and 9.19 seem appropriate places for the additions. Ralph and I will try to draft it before the next call. I think Ralph is more qualified to provide answers below but here is my version. > Finally, I'd like a little clarification on this extension... > > 1) Who creates and owns the FIFO? Is it the starter process? Yes. > On what node is the FIFO created? My concern is this: If the starter process is being debugged remotely (e.g.: totalview -r remotehost mpiexec) does the debugger have to open the FIFO on the remotehost? I'd assume so, which means that the debugger has to extend its remote debugging protocol to execute this "write to FIFO" operation. This wasn't an issue with STAT/LaunchMON because this tool co-locates the launchmon engine to the starter process which knows how to deal with files. BTW, is "write-to-file" not supported for TotalView remote debugging protocol? > 2) Who is responsible for deleting the FIFO? What happens if the debugger forcibly kills the starter process? Is the FIFO leaked? The starter process is responsible for deleting it. As to your second question, I think this kind of cleanup requirement applies not only to this FIFO but also all other resources that the RM holds. The RM should be able to release all of its resources when its starter process is forcibly killed by the controlling debugger. In any case, I was told that oretrun creates a per-session directory where it put all of the file resources, which was also used for managing this FIFO resource. I suspect that orterun can perform the FIFO clean-up in the same fashion it cleans up other files in this directory when forcibly killed by the debugger. > 3) Why didn't you use a socket or a signal instead of a FIFO? With a socket or signal, you don't have lifetime issues. With a signal, you don't have remote debugging issues. We thought about those options but none are well-suited for orterun. Most signals are already taken for this resource manager; a socket could be used, but then one will have to worry about authentication and etc... Best, Dong > Cheers, John D. > > > >> Best, >> Dong >> >> On 8/6/2010 11:58 AM, John DelSignore wrote: >>> Hi, >>> >>> Attached is the most recent draft (8/6/2010) of the MPIR document for discussion during the 8/9 meeting. >>> >>> I updated it to reflect the comments I received in email on the 6/11/2010 draft that I felt warranted changing the document. >>> >>> I also copy and pasted Jeff's mpimsgq_dll_locations description from the Latex file and the MPI website; this is intended as a placeholder until someone (not me) has time to cleanup the text to fit into the document. >>> >>> The "Diffs" document shows the changes relative to the 6/11/2010 draft. >>> >>> Cheers, John D. >>> >>> >>> Jeff Squyres wrote: >>>> On Jul 25, 2010, at 5:23 PM, Martin Schulz wrote: >>>> >>>>> Here is the proposed schedule for the upcoming meetings after tomorrow: >>>>> >>>>> 8/9 - Final discussion of the MPIR document >>>>> 8/23 - Discussion of the completed/integrated MPIT document >>>>> 9/6 - Labor day - no meeting >>>>> 9/16-9/18 - MPI forum meeting in Stuttgart >>>>> First reading of the MPIR document >>>>> 9/20 - Feedback from the MPI forum, MPIT discussions >>>> Webex links for these meetings are now up on the wiki. >>>> >> _______________________________________________ >> Mpi3-tools mailing list >> Mpi3-tools(a)lists.mpi-forum.org >> http://*lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >> > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://*lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >

1 0

Re: [Mpi3-tools] Next MPI-3 Tools WG meeting Monday 8/26 + Schedule fornext meetings
by John DelSignore 09 Aug '10

09 Aug '10

Dong H. Ahn wrote: > Hi John, > > I just looked at the revision and I think this addressed most of the > issues I've raised except for the MPIR_attach_fifo support. Sorry, I forgot about MPIR_attach_fifo. I had to scrounge around in my email to find the description. Here's what I have, from an email you sent on 7/9/10: ============================================= ... I would also hope to cover a recently implemented MPIR extension on OpenRTE/OpenMPI: MPIR_attach_fifo support. ------- " char MPIR_attach_fifo[256]; Definition is not required. Definition is contained within the address space of the starter process. Variable is written by the tool, and read by the starter process. MPIR_attach_fifo is a null-terminated character string that is written by the tool into the address space of the starter process. The string is the path name of a FIFO (named pipe). Writing a byte into this FIFO will cause the starter process to start to monitor MPIR_being_debugged in attach mode. " ------- As part of LaunchMON/STAT OpenRTE/OpenMPI port, Ralph Castain reproduced BlueGene's MPIR colocation extension but there was a performance requirement of orterun that kept orterun from polling on the value changes of MPIR_being_debugged for attach case by default. So we addressed it by making orterun open up a FIFO and its comm thread block on the FIFO along with other TCP channels; when a debugger attaches to orterun and writes a byte into it, the starter process looks at MPIR_being_debugger and performs the co-location service. ============================================= > If it is > missing from this revision because of a lack of technical details, Ralph > and I should be able to provide them. Given that I know zilch MPIR_attach_fifo, it would make sense for someone else (not me) to write-up the description and incorporate it into the document. Since it is an extension, I think it should be added in sections 7 and 9. Sections 7.3 and 9.19 seem appropriate places for the additions. Finally, I'd like a little clarification on this extension... 1) Who creates and owns the FIFO? Is it the starter process? On what node is the FIFO created? My concern is this: If the starter process is being debugged remotely (e.g.: totalview -r remotehost mpiexec) does the debugger have to open the FIFO on the remotehost? I'd assume so, which means that the debugger has to extend its remote debugging protocol to execute this "write to FIFO" operation. 2) Who is responsible for deleting the FIFO? What happens if the debugger forcibly kills the starter process? Is the FIFO leaked? 3) Why didn't you use a socket or a signal instead of a FIFO? With a socket or signal, you don't have lifetime issues. With a signal, you don't have remote debugging issues. Cheers, John D. > Best, > Dong > > On 8/6/2010 11:58 AM, John DelSignore wrote: >> Hi, >> >> Attached is the most recent draft (8/6/2010) of the MPIR document for discussion during the 8/9 meeting. >> >> I updated it to reflect the comments I received in email on the 6/11/2010 draft that I felt warranted changing the document. >> >> I also copy and pasted Jeff's mpimsgq_dll_locations description from the Latex file and the MPI website; this is intended as a placeholder until someone (not me) has time to cleanup the text to fit into the document. >> >> The "Diffs" document shows the changes relative to the 6/11/2010 draft. >> >> Cheers, John D. >> >> >> Jeff Squyres wrote: >>> On Jul 25, 2010, at 5:23 PM, Martin Schulz wrote: >>> >>>> Here is the proposed schedule for the upcoming meetings after tomorrow: >>>> >>>> 8/9 - Final discussion of the MPIR document >>>> 8/23 - Discussion of the completed/integrated MPIT document >>>> 9/6 - Labor day - no meeting >>>> 9/16-9/18 - MPI forum meeting in Stuttgart >>>> First reading of the MPIR document >>>> 9/20 - Feedback from the MPI forum, MPIT discussions >>> Webex links for these meetings are now up on the wiki. >>> > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >

1 0

Re: [Mpi3-tools] Next MPI-3 Tools WG meeting Monday 8/26 + Schedule fornext meetings
by Dong H. Ahn 09 Aug '10

09 Aug '10

Hi John, I just looked at the revision and I think this addressed most of the issues I've raised except for the MPIR_attach_fifo support. If it is missing from this revision because of a lack of technical details, Ralph and I should be able to provide them. Best, Dong On 8/6/2010 11:58 AM, John DelSignore wrote: > Hi, > > Attached is the most recent draft (8/6/2010) of the MPIR document for discussion during the 8/9 meeting. > > I updated it to reflect the comments I received in email on the 6/11/2010 draft that I felt warranted changing the document. > > I also copy and pasted Jeff's mpimsgq_dll_locations description from the Latex file and the MPI website; this is intended as a placeholder until someone (not me) has time to cleanup the text to fit into the document. > > The "Diffs" document shows the changes relative to the 6/11/2010 draft. > > Cheers, John D. > > > Jeff Squyres wrote: >> On Jul 25, 2010, at 5:23 PM, Martin Schulz wrote: >> >>> Here is the proposed schedule for the upcoming meetings after tomorrow: >>> >>> 8/9 - Final discussion of the MPIR document >>> 8/23 - Discussion of the completed/integrated MPIT document >>> 9/6 - Labor day - no meeting >>> 9/16-9/18 - MPI forum meeting in Stuttgart >>> First reading of the MPIR document >>> 9/20 - Feedback from the MPI forum, MPIT discussions >> Webex links for these meetings are now up on the wiki. >>

1 0

Re: [Mpi3-tools] MPIR_PROCDESC
by Jeff Squyres 09 Aug '10

09 Aug '10

Should there be an "advice to implementors" sidenote about this issue in the text? On Aug 9, 2010, at 12:28 PM, John DelSignore wrote: > I was wondering when someone was going notice this... > > Originally, MPIR_PROCDESC was defined as a typedef, so that's what I put into the document. The "typedef struct {...} MPIR_PROCDESC;" style allows MPIR_PROCDESC to be use as a type in both C and C++, but experience taught us that defining MPIR_PROCDESC as a typedef was a mistake. > > The reason it was a mistake is that typedef names have internal linkage, and that might make it difficult, inefficient, or impossible for the debugger to find its definition. But, when defined as a struct, that gives the name external linkage, and that usually means that the name is included in symbol table indexes, such as DWARF's .debug_pubnames, making it easier for the debugger to find the definition by name. > > However, experience has also taught us that looking up MPIR_PROCDESC by name is a losing proposition no matter how it's defined, so we don't do that. Instead, we look up the MPIR_proctable variable, fully resolve the symbols for compilation unit containing the variable, and then look at the type of the variable, which should be a pointer to an MPIR_PROCDESC. The target type of the pointer might be the structure, or the typedef, so we have to peel away any intervening typedefs to get to the structure definition. > > So, I think that the way Open MPI defines MPIR_PROCDESC as a struct is actually *better* than using a typedef, because that makes MPIR_PROCDESC more easily findable by name. But, any experienced debugger developer would know that looking it up by name would be unreliable, and wouldn't do that, so IMHO it doesn't matter how MPIR_PROCDESC is defined. > > Cheers, John D. > > > David Lecomber wrote: > > Hi Jeff and all, > > > > We just noticed that Open MPI doesn't strictly meet the MPIR_PROCDESC > > requirement: it must just due to our forgiving natures that both TTV and > > DDT work with it ;-) > > > > struct MPIR_PROCDESC { > > char *host_name; /* something that can be passed to inet_addr > > */ > > char *executable_name; /* name of binary */ > > int pid; /* process pid */ > > }; > > > > Compare and contrast to John's MPIR doc: > > > > typedef struct { > > char *host_name; > > char *executable_name; > > int pid; > > } MPIR_PROCDESC; > > > > and .. > > > >> [..] > >> MPIR_PROCDESC is a typedef name for an anonymous structure that holds process descriptor > >> information for a single MPI process. The structure must contain three members with the same > >> names and types as specified above. [..] > > > > Ok, tell me I'm being pedantic ;) -- the MPIR_PROCDESC in OMPI is not a > > typedef to an anonymous structure - it is actually a struct - a named > > structure type. Does the spec need relaxing, or is this a 'bug'? > > > > Cheers > > David. > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > -- 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: [Mpi3-tools] MPIR_PROCDESC
by John DelSignore 09 Aug '10

09 Aug '10

I was wondering when someone was going notice this... Originally, MPIR_PROCDESC was defined as a typedef, so that's what I put into the document. The "typedef struct {...} MPIR_PROCDESC;" style allows MPIR_PROCDESC to be use as a type in both C and C++, but experience taught us that defining MPIR_PROCDESC as a typedef was a mistake. The reason it was a mistake is that typedef names have internal linkage, and that might make it difficult, inefficient, or impossible for the debugger to find its definition. But, when defined as a struct, that gives the name external linkage, and that usually means that the name is included in symbol table indexes, such as DWARF's .debug_pubnames, making it easier for the debugger to find the definition by name. However, experience has also taught us that looking up MPIR_PROCDESC by name is a losing proposition no matter how it's defined, so we don't do that. Instead, we look up the MPIR_proctable variable, fully resolve the symbols for compilation unit containing the variable, and then look at the type of the variable, which should be a pointer to an MPIR_PROCDESC. The target type of the pointer might be the structure, or the typedef, so we have to peel away any intervening typedefs to get to the structure definition. So, I think that the way Open MPI defines MPIR_PROCDESC as a struct is actually *better* than using a typedef, because that makes MPIR_PROCDESC more easily findable by name. But, any experienced debugger developer would know that looking it up by name would be unreliable, and wouldn't do that, so IMHO it doesn't matter how MPIR_PROCDESC is defined. Cheers, John D. David Lecomber wrote: > Hi Jeff and all, > > We just noticed that Open MPI doesn't strictly meet the MPIR_PROCDESC > requirement: it must just due to our forgiving natures that both TTV and > DDT work with it ;-) > > struct MPIR_PROCDESC { > char *host_name; /* something that can be passed to inet_addr > */ > char *executable_name; /* name of binary */ > int pid; /* process pid */ > }; > > Compare and contrast to John's MPIR doc: > > typedef struct { > char *host_name; > char *executable_name; > int pid; > } MPIR_PROCDESC; > > and .. > >> [..] >> MPIR_PROCDESC is a typedef name for an anonymous structure that holds process descriptor >> information for a single MPI process. The structure must contain three members with the same >> names and types as specified above. [..] > > Ok, tell me I'm being pedantic ;) -- the MPIR_PROCDESC in OMPI is not a > typedef to an anonymous structure - it is actually a struct - a named > structure type. Does the spec need relaxing, or is this a 'bug'? > > Cheers > David. >

1 0

Re: [Mpi3-tools] Next MPI-3 Tools WG meeting Monday 8/26 + Schedule fornext meetings
by Jeff Squyres 09 Aug '10

09 Aug '10

I waited for 15 mins but no one else showed up. Sorry folks! On Aug 9, 2010, at 11:32 AM, Jeff Squyres wrote: > Sorry -- this meeting was somehow not on my calendar and I just returned from vacation today and am playing catchup. > > I'll join right now to see if anyone else is on... > > > On Aug 9, 2010, at 11:12 AM, Mohror, Kathryn wrote: > >> Hi Bronis, >> >> Martin told me he asked Jeff to lead this meeting. >> >> Kathryn >> >> ------------ >> Kathryn Mohror >> Lawrence Livermore National Lab >> (925)423-2997 >> kathryn(a)llnl.gov >> >>> -----Original Message----- >>> From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:mpi3-tools- >>> bounces(a)lists.mpi-forum.org] On Behalf Of Bronis R. de Supinski >>> Sent: Monday, August 09, 2010 8:11 AM >>> To: mpi3-tools(a)lists.mpi-forum.org >>> Subject: Re: [Mpi3-tools] Next MPI-3 Tools WG meeting Monday 8/26 + >>> Schedule fornext meetings >>> >>> >>> The WebEx Client is not starting correctly for me. >>> Martin is on vacation so unless he made arrangements >>> for someone else to run the call, I would say no... >>> >>> On Mon, 9 Aug 2010, John DelSignore wrote: >>> >>>> Hi, >>>> >>>> I'm the only one on the call. Is it still going to happen? >>>> >>>> Cheers, John D. >>>> >>>> >>>> Jeff Squyres wrote: >>>>> On Jul 25, 2010, at 5:23 PM, Martin Schulz wrote: >>>>> >>>>>> Here is the proposed schedule for the upcoming meetings after >>> tomorrow: >>>>>> >>>>>> 8/9 - Final discussion of the MPIR document >>>>>> 8/23 - Discussion of the completed/integrated MPIT document >>>>>> 9/6 - Labor day - no meeting >>>>>> 9/16-9/18 - MPI forum meeting in Stuttgart >>>>>> First reading of the MPIR document >>>>>> 9/20 - Feedback from the MPI forum, MPIT discussions >>>>> >>>>> Webex links for these meetings are now up on the wiki. >>>>> >>>> _______________________________________________ >>>> Mpi3-tools mailing list >>>> Mpi3-tools(a)lists.mpi-forum.org >>>> http://**lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>>> >>>> >>> _______________________________________________ >>> Mpi3-tools mailing list >>> Mpi3-tools(a)lists.mpi-forum.org >>> http://*lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >> >> >> _______________________________________________ >> Mpi3-tools mailing list >> Mpi3-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >> > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools -- 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] MPIR_PROCDESC
by David Lecomber 09 Aug '10

09 Aug '10

Hi Jeff and all, We just noticed that Open MPI doesn't strictly meet the MPIR_PROCDESC requirement: it must just due to our forgiving natures that both TTV and DDT work with it ;-) struct MPIR_PROCDESC { char *host_name; /* something that can be passed to inet_addr */ char *executable_name; /* name of binary */ int pid; /* process pid */ }; Compare and contrast to John's MPIR doc: typedef struct { char *host_name; char *executable_name; int pid; } MPIR_PROCDESC; and .. > [..] > MPIR_PROCDESC is a typedef name for an anonymous structure that holds process descriptor > information for a single MPI process. The structure must contain three members with the same > names and types as specified above. [..] Ok, tell me I'm being pedantic ;) -- the MPIR_PROCDESC in OMPI is not a typedef to an anonymous structure - it is actually a struct - a named structure type. Does the spec need relaxing, or is this a 'bug'? Cheers David. -- David Lecomber, CTO, Allinea Software +44 7980 863033 Allinea Software Limited: Registered in England and Wales No: 6871298 The Innovation Centre, Warwick Technology Park, Warwick, CV34 6UW, UK

1 0

Re: [Mpi3-tools] Next MPI-3 Tools WG meeting Monday 8/26 + Schedule fornext meetings
by John DelSignore 09 Aug '10

09 Aug '10

It was just Kathryn and me on the call until 20 past, so terminated the call. It should be quick to deal with the MPIR stuff on the 23rd. Cheers, John D. Jeff Squyres wrote: > Sorry -- this meeting was somehow not on my calendar and I just returned from vacation today and am playing catchup. > > I'll join right now to see if anyone else is on... > > > On Aug 9, 2010, at 11:12 AM, Mohror, Kathryn wrote: > >> Hi Bronis, >> >> Martin told me he asked Jeff to lead this meeting. >> >> Kathryn >> >> ------------ >> Kathryn Mohror >> Lawrence Livermore National Lab >> (925)423-2997 >> kathryn(a)llnl.gov >> >>> -----Original Message----- >>> From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:mpi3-tools- >>> bounces(a)lists.mpi-forum.org] On Behalf Of Bronis R. de Supinski >>> Sent: Monday, August 09, 2010 8:11 AM >>> To: mpi3-tools(a)lists.mpi-forum.org >>> Subject: Re: [Mpi3-tools] Next MPI-3 Tools WG meeting Monday 8/26 + >>> Schedule fornext meetings >>> >>> >>> The WebEx Client is not starting correctly for me. >>> Martin is on vacation so unless he made arrangements >>> for someone else to run the call, I would say no... >>> >>> On Mon, 9 Aug 2010, John DelSignore wrote: >>> >>>> Hi, >>>> >>>> I'm the only one on the call. Is it still going to happen? >>>> >>>> Cheers, John D. >>>> >>>> >>>> Jeff Squyres wrote: >>>>> On Jul 25, 2010, at 5:23 PM, Martin Schulz wrote: >>>>> >>>>>> Here is the proposed schedule for the upcoming meetings after >>> tomorrow: >>>>>> 8/9 - Final discussion of the MPIR document >>>>>> 8/23 - Discussion of the completed/integrated MPIT document >>>>>> 9/6 - Labor day - no meeting >>>>>> 9/16-9/18 - MPI forum meeting in Stuttgart >>>>>> First reading of the MPIR document >>>>>> 9/20 - Feedback from the MPI forum, MPIT discussions >>>>> Webex links for these meetings are now up on the wiki. >>>>> >>>> _______________________________________________ >>>> Mpi3-tools mailing list >>>> Mpi3-tools(a)lists.mpi-forum.org >>>> http://**lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >>>> >>>> >>> _______________________________________________ >>> Mpi3-tools mailing list >>> Mpi3-tools(a)lists.mpi-forum.org >>> http://*lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >> >> _______________________________________________ >> Mpi3-tools mailing list >> Mpi3-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools >> > >

1 0

Re: [Mpi3-tools] Next MPI-3 Tools WG meeting Monday 8/26 + Schedule fornext meetings
by Jeff Squyres 09 Aug '10

09 Aug '10

Sorry -- this meeting was somehow not on my calendar and I just returned from vacation today and am playing catchup. I'll join right now to see if anyone else is on... On Aug 9, 2010, at 11:12 AM, Mohror, Kathryn wrote: > Hi Bronis, > > Martin told me he asked Jeff to lead this meeting. > > Kathryn > > ------------ > Kathryn Mohror > Lawrence Livermore National Lab > (925)423-2997 > kathryn(a)llnl.gov > > > -----Original Message----- > > From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:mpi3-tools- > > bounces(a)lists.mpi-forum.org] On Behalf Of Bronis R. de Supinski > > Sent: Monday, August 09, 2010 8:11 AM > > To: mpi3-tools(a)lists.mpi-forum.org > > Subject: Re: [Mpi3-tools] Next MPI-3 Tools WG meeting Monday 8/26 + > > Schedule fornext meetings > > > > > > The WebEx Client is not starting correctly for me. > > Martin is on vacation so unless he made arrangements > > for someone else to run the call, I would say no... > > > > On Mon, 9 Aug 2010, John DelSignore wrote: > > > > > Hi, > > > > > > I'm the only one on the call. Is it still going to happen? > > > > > > Cheers, John D. > > > > > > > > > Jeff Squyres wrote: > > >> On Jul 25, 2010, at 5:23 PM, Martin Schulz wrote: > > >> > > >>> Here is the proposed schedule for the upcoming meetings after > > tomorrow: > > >>> > > >>> 8/9 - Final discussion of the MPIR document > > >>> 8/23 - Discussion of the completed/integrated MPIT document > > >>> 9/6 - Labor day - no meeting > > >>> 9/16-9/18 - MPI forum meeting in Stuttgart > > >>> First reading of the MPIR document > > >>> 9/20 - Feedback from the MPI forum, MPIT discussions > > >> > > >> Webex links for these meetings are now up on the wiki. > > >> > > > _______________________________________________ > > > Mpi3-tools mailing list > > > Mpi3-tools(a)lists.mpi-forum.org > > > http://**lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > > > > > _______________________________________________ > > Mpi3-tools mailing list > > Mpi3-tools(a)lists.mpi-forum.org > > http://*lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > -- 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: [Mpi3-tools] Next MPI-3 Tools WG meeting Monday 8/26 + Schedule fornext meetings
by Mohror, Kathryn 09 Aug '10

09 Aug '10

Hi Bronis, Martin told me he asked Jeff to lead this meeting. Kathryn ------------ Kathryn Mohror Lawrence Livermore National Lab (925)423-2997 kathryn(a)llnl.gov > -----Original Message----- > From: mpi3-tools-bounces(a)lists.mpi-forum.org [mailto:mpi3-tools- > bounces(a)lists.mpi-forum.org] On Behalf Of Bronis R. de Supinski > Sent: Monday, August 09, 2010 8:11 AM > To: mpi3-tools(a)lists.mpi-forum.org > Subject: Re: [Mpi3-tools] Next MPI-3 Tools WG meeting Monday 8/26 + > Schedule fornext meetings > > > The WebEx Client is not starting correctly for me. > Martin is on vacation so unless he made arrangements > for someone else to run the call, I would say no... > > On Mon, 9 Aug 2010, John DelSignore wrote: > > > Hi, > > > > I'm the only one on the call. Is it still going to happen? > > > > Cheers, John D. > > > > > > Jeff Squyres wrote: > >> On Jul 25, 2010, at 5:23 PM, Martin Schulz wrote: > >> > >>> Here is the proposed schedule for the upcoming meetings after > tomorrow: > >>> > >>> 8/9 - Final discussion of the MPIR document > >>> 8/23 - Discussion of the completed/integrated MPIT document > >>> 9/6 - Labor day - no meeting > >>> 9/16-9/18 - MPI forum meeting in Stuttgart > >>> First reading of the MPIR document > >>> 9/20 - Feedback from the MPI forum, MPIT discussions > >> > >> Webex links for these meetings are now up on the wiki. > >> > > _______________________________________________ > > Mpi3-tools mailing list > > Mpi3-tools(a)lists.mpi-forum.org > > http://**lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools > > > > > _______________________________________________ > Mpi3-tools mailing list > Mpi3-tools(a)lists.mpi-forum.org > http://*lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools

1 0