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

Re: [mpiwg-tools] Too strict for flags in MPI_T_pvar_get_info?
by Jeff Squyres (jsquyres) 14 Aug '14

14 Aug '14

Is s/0/false/g s/1/true/g (where relevant, of course) in the Tools chapter more than a ticket-0 change? On Aug 14, 2014, at 2:39 PM, Mohror, Kathryn <mohror1(a)llnl.gov> wrote: > Hi Jeff, > > I see your point too. How do you propose to fix it? Make it clearer why we don't follow the same convention? Or change it to follow the rest of the standard? (The latter doesn't seem like ticket 0 to me.) > > > > -- Kathryn > > Sent with Good (www.good.com) > > > -----Original Message----- > From: Jeff Squyres (jsquyres) [jsquyres(a)cisco.com] > Sent: Thursday, August 14, 2014 10:28 AM Pacific Standard Time > To: MPI Tool WG > Subject: Re: [mpiwg-tools] Too strict for flags in MPI_T_pvar_get_info? > > I think the parts about the C convention/ignoring Fortran is fine. > > But I think Junchao is raising the small-but-valid point that elsewhere in the doc, we say true/false for such things, but here in the tools chapter, we're saying 1/0. So I'd say that this is a valid "consistency" kind of issue. > > I'd further opine that this is a ticket 0 kind of change, and the chapter author should just make the change. > > > > On Aug 14, 2014, at 1:19 PM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: > > > Hi Junchao, > > > > Thanks as always for your sharp eyes. I think though in this case that > > Nathan is correct. Since we only define a C interface for MPI_T and try to > > ignore Fortran altogether, it is okay to use the C convention for true and > > false. > > > > Kathryn > > _________________________________________________________________ > > Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ > > Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, > > USA > > > > > > > > > > > > > > On 8/14/14, 9:49 AM, "Nathan Hjelm" <hjelmn(a)mac.com> wrote: > > > >> > >> On Aug 14, 2014, at 10:35 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > >> > >> > >> > >> > >> It is a minor issue. In the Standard, the description for > >> int MPI_T_pvar_get_info(..., int *readonly, int *continuous, int > >> *atomic) > >> says: > >> Upon return, the argument readonly is set to zero if the variable can > >> be written or reset by the user. It is set to > >> one if the variable can only be read. > >> (Same thing happens to continuous and atomic.) > >> > >> > >> The description mandates an implementation must return 1 as TRUE, which > >> does not follow C's convention. Other parts of MPI use true/false instead > >> of 1/0 in description. Section 2.6.3 make it clear that true means > >> non-zero. > >> > >> > >> > >> > >> > >> How does that not follow C¹s convention? C mandates that the evaluation > >> of a boolean operator (<, >, !, etc) MUST evaluate to either 0 or 1. > >> Returning 0/1 here makes perfect sense. > >> > >> > >> Other parts of MPI probably use true/false because fortran logicals do > >> not use 0/1 for false/true. > >> > >> > >> -Nathan Hjelm > >> > >> > > > > > > _______________________________________________ > > mpiwg-tools mailing list > > mpiwg-tools(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-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: [mpiwg-tools] Too strict for flags in MPI_T_pvar_get_info?
by Mohror, Kathryn 14 Aug '14

14 Aug '14

Hi Jeff, I see your point too. How do you propose to fix it? Make it clearer why we don't follow the same convention? Or change it to follow the rest of the standard? (The latter doesn't seem like ticket 0 to me.) -- Kathryn Sent with Good (www.good.com) -----Original Message----- From: Jeff Squyres (jsquyres) [jsquyres(a)cisco.com<mailto:[email protected]>] Sent: Thursday, August 14, 2014 10:28 AM Pacific Standard Time To: MPI Tool WG Subject: Re: [mpiwg-tools] Too strict for flags in MPI_T_pvar_get_info? I think the parts about the C convention/ignoring Fortran is fine. But I think Junchao is raising the small-but-valid point that elsewhere in the doc, we say true/false for such things, but here in the tools chapter, we're saying 1/0. So I'd say that this is a valid "consistency" kind of issue. I'd further opine that this is a ticket 0 kind of change, and the chapter author should just make the change. On Aug 14, 2014, at 1:19 PM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: > Hi Junchao, > > Thanks as always for your sharp eyes. I think though in this case that > Nathan is correct. Since we only define a C interface for MPI_T and try to > ignore Fortran altogether, it is okay to use the C convention for true and > false. > > Kathryn > _________________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ > Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, > USA > > > > > > > On 8/14/14, 9:49 AM, "Nathan Hjelm" <hjelmn(a)mac.com> wrote: > >> >> On Aug 14, 2014, at 10:35 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: >> >> >> >> >> It is a minor issue. In the Standard, the description for >> int MPI_T_pvar_get_info(..., int *readonly, int *continuous, int >> *atomic) >> says: >> Upon return, the argument readonly is set to zero if the variable can >> be written or reset by the user. It is set to >> one if the variable can only be read. >> (Same thing happens to continuous and atomic.) >> >> >> The description mandates an implementation must return 1 as TRUE, which >> does not follow C's convention. Other parts of MPI use true/false instead >> of 1/0 in description. Section 2.6.3 make it clear that true means >> non-zero. >> >> >> >> >> >> How does that not follow C¹s convention? C mandates that the evaluation >> of a boolean operator (<, >, !, etc) MUST evaluate to either 0 or 1. >> Returning 0/1 here makes perfect sense. >> >> >> Other parts of MPI probably use true/false because fortran logicals do >> not use 0/1 for false/true. >> >> >> -Nathan Hjelm >> >> > > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ _______________________________________________ mpiwg-tools mailing list mpiwg-tools(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0

Re: [mpiwg-tools] Too strict for flags in MPI_T_pvar_get_info?
by Jeff Squyres (jsquyres) 14 Aug '14

14 Aug '14

I think the parts about the C convention/ignoring Fortran is fine. But I think Junchao is raising the small-but-valid point that elsewhere in the doc, we say true/false for such things, but here in the tools chapter, we're saying 1/0. So I'd say that this is a valid "consistency" kind of issue. I'd further opine that this is a ticket 0 kind of change, and the chapter author should just make the change. On Aug 14, 2014, at 1:19 PM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: > Hi Junchao, > > Thanks as always for your sharp eyes. I think though in this case that > Nathan is correct. Since we only define a C interface for MPI_T and try to > ignore Fortran altogether, it is okay to use the C convention for true and > false. > > Kathryn > _________________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ > Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, > USA > > > > > > > On 8/14/14, 9:49 AM, "Nathan Hjelm" <hjelmn(a)mac.com> wrote: > >> >> On Aug 14, 2014, at 10:35 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: >> >> >> >> >> It is a minor issue. In the Standard, the description for >> int MPI_T_pvar_get_info(..., int *readonly, int *continuous, int >> *atomic) >> says: >> Upon return, the argument readonly is set to zero if the variable can >> be written or reset by the user. It is set to >> one if the variable can only be read. >> (Same thing happens to continuous and atomic.) >> >> >> The description mandates an implementation must return 1 as TRUE, which >> does not follow C's convention. Other parts of MPI use true/false instead >> of 1/0 in description. Section 2.6.3 make it clear that true means >> non-zero. >> >> >> >> >> >> How does that not follow C¹s convention? C mandates that the evaluation >> of a boolean operator (<, >, !, etc) MUST evaluate to either 0 or 1. >> Returning 0/1 here makes perfect sense. >> >> >> Other parts of MPI probably use true/false because fortran logicals do >> not use 0/1 for false/true. >> >> >> -Nathan Hjelm >> >> > > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-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: [mpiwg-tools] Too strict for flags in MPI_T_pvar_get_info?
by Kathryn Mohror 14 Aug '14

14 Aug '14

Hi Junchao, Thanks as always for your sharp eyes. I think though in this case that Nathan is correct. Since we only define a C interface for MPI_T and try to ignore Fortran altogether, it is okay to use the C convention for true and false. Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA On 8/14/14, 9:49 AM, "Nathan Hjelm" <hjelmn(a)mac.com> wrote: > >On Aug 14, 2014, at 10:35 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > > > > >It is a minor issue. In the Standard, the description for > int MPI_T_pvar_get_info(..., int *readonly, int *continuous, int >*atomic) >says: > Upon return, the argument readonly is set to zero if the variable can >be written or reset by the user. It is set to >one if the variable can only be read. > (Same thing happens to continuous and atomic.) > > >The description mandates an implementation must return 1 as TRUE, which >does not follow C's convention. Other parts of MPI use true/false instead >of 1/0 in description. Section 2.6.3 make it clear that true means >non-zero. > > > > > >How does that not follow C¹s convention? C mandates that the evaluation >of a boolean operator (<, >, !, etc) MUST evaluate to either 0 or 1. >Returning 0/1 here makes perfect sense. > > >Other parts of MPI probably use true/false because fortran logicals do >not use 0/1 for false/true. > > >-Nathan Hjelm > >

1 0

Re: [mpiwg-tools] Too strict for flags in MPI_T_pvar_get_info?
by Nathan Hjelm 14 Aug '14

14 Aug '14

On Aug 14, 2014, at 10:35 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > > It is a minor issue. In the Standard, the description for > int MPI_T_pvar_get_info(..., int *readonly, int *continuous, int *atomic) > says: > Upon return, the argument readonly is set to zero if the variable can be written or reset by the user. It is set to one if the variable can only be read. > (Same thing happens to continuous and atomic.) > > The description mandates an implementation must return 1 as TRUE, which does not follow C's convention. Other parts of MPI use true/false instead of 1/0 in description. Section 2.6.3 make it clear that true means non-zero. How does that not follow C’s convention? C mandates that the evaluation of a boolean operator (<, >, !, etc) MUST evaluate to either 0 or 1. Returning 0/1 here makes perfect sense. Other parts of MPI probably use true/false because fortran logicals do not use 0/1 for false/true. -Nathan Hjelm

1 0

Too strict for flags in MPI_T_pvar_get_info?
by Junchao Zhang 14 Aug '14

14 Aug '14

It is a minor issue. In the Standard, the description for int MPI_T_pvar_get_info(..., int *readonly, int *continuous, int *atomic) says: Upon return, the argument readonly is set to zero if the variable can be written or reset by the user. It is set to *one* if the variable can only be read. (Same thing happens to continuous and atomic.) The description mandates an implementation must return 1 as TRUE, which does not follow C's convention. Other parts of MPI use true/false instead of 1/0 in description. Section 2.6.3 make it clear that true means non-zero. Thanks. --Junchao Zhang

1 0

Re: [mpiwg-tools] The infernal "things must be identical" text (was: Meeting reminder for April 3 11:00 AM EDT, 8:00 AM PDT)
by Martin Schulz 07 Aug '14

07 Aug '14

Hi Kathryn, all, I am not sure if I can make it today for the call, so here are a few comments on the ticket draft. I’ll also add them to the ticket. Thanks, Martin - Return the same INOUT and OUT integer and enum values from the relevant MPI_T_*_GET_INFO function. Should include datatype values - If sufficiently long string length INOUT parameters are supplied, return the same string valued OUT parameters from the relevant MPI_T_*_GET_INFO function. -> functions - Return a handle to an equivalent MPI object from the relevant MPI_T_*_GET_INFO function. This can be removed, INFO calls don’t return handles - we return only the type of MPI object, which is an integer and that is covered by the above - Similarly, enumerations and categories in connected processes must also obey the above restrictions where applicable What about “for certain parameters” instead of “where applicable” - Table:MPI_T_ENUM_GET_INFO should be removed from the table (we decided to allow different numbers in different processes to support Jeff’s use case) - Table:MPI_T_ENUM_GET_ITEM is a bit strange here, since it is not an GET_INFO call and so doesn’t quite match the text above (minor detail, though) - Table:MPI_T_ENUM_GET_INFO: we should either have value and name here or neither, if we keep name, it should be contents of name to be consistent - Table:MPI_T_CVAR_GET_INFO: needs to include contents of name - Table:MPI_T_PVAR_GET_INFO: needs to include contents of name - Table:MPI_T_CATEGORY_GET_INFO: needs to include contents of name ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ CASC @ Lawrence Livermore National Laboratory, Livermore, USA On 8/4/14, 6:35 PM, "Kathryn Mohror" <kathryn(a)llnl.gov> wrote: >Thanks Michael! > >I¹ve attached a first stab at putting the table back into the document. >Please take a look if you can, and we¹ll discuss it more later this week >during the call. > >Kathryn > >_________________________________________________________________ >Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ >Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, >USA > > > > > > >On 7/25/14, 4:04 AM, "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> wrote: > >>Thanks Michael; that's helpful -- I see it there on page 3. >> >>Perhaps we can blend this table with the current text to get what we >>want...? E.g., text about the same semantics, categories with same >>name/class, ...etc. >> >> >> >>On Jul 25, 2014, at 4:53 AM, Michael Knobloch <m.knobloch(a)fz-juelich.de> >>wrote: >> >>> Hi all, >>> >>> no need to scan the page if you have some structure in your mails ;-). >>> >>> Here's the original mail with the version I've shown yesterday. >>> >>> -Michael >>> >>> -------- Original Message -------- >>> Subject: Re: [mpiwg-tools] Meeting reminder for April 3 11:00 AM >>>EDT, >>> 8:00 AM PDT >>> Date: Fri, 4 Apr 2014 00:35:15 +0200 >>> From: Kathryn Mohror <kathryn(a)llnl.gov> >>> Reply-To: mpiwg-tools(a)lists.mpi-forum.org >>><mpiwg-tools(a)lists.mpi-forum.org> >>> To: mpiwg-tools(a)lists.mpi-forum.org >>><mpiwg-tools(a)lists.mpi-forum.org> >>> >>> >>> >>> Hi everybody, >>> >>> In case you're just *dying* to see what the changes for ticket 383 look >>> like from our discussions today and from Adam's feedback, I have >>> attached the new document. >>> >>> Also, Adam's comments were basically that he didn't understand the >>> meaning of the table, so I changed it up and he likes it now. >>> >>> Kathryn >>> >>> >>> On Apr 3, 2014, at 8:56 AM, Kathryn Mohror <kathryn(a)llnl.gov >>> <mailto:[email protected]>> wrote: >>> >>>> Hi all, >>>> >>>> I put notes from today's meeting on the wiki: >>>> >>>> >>>>https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools/notes-2014- >>>>0 >>>>4-03 >>>> >>>> Kathryn >>>> >>>> On Apr 2, 2014, at 11:50 AM, Kathryn Mohror <kathryn(a)llnl.gov >>>> <mailto:[email protected]>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> This is a reminder of our regularly scheduled call tomorrow at 11:00 >>>>> AM Eastern and 8:00 AM Pacific. As always, the sign in information >>>>> for the call is on the tools >>>>> wiki: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools >>>>> >>>>> I drafted some text for 383 (the 'variables with the same name must >>>>> have same meaning' errata ticket). We can tear it apart on the call. >>>>> The document is attached if you want to look at it in advance. >>>>> >>>>> Talk to you tomorrow! >>>>> Kathryn >>>>> >>>>> >>>>> _________________________________________________________________ >>>>> Kathryn Mohror, kathryn(a)llnl.gov >>>>> <mailto:[email protected]>, http://scalability.llnl.gov/ >>>>> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, >>>>> CA, USA >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> <tools-3.pdf> >>>> >>>> _________________________________________________________________ >>>> Kathryn Mohror, kathryn(a)llnl.gov >>>> <mailto:[email protected]>, http://scalability.llnl.gov/ >>>> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, >>>> CA, USA >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> mpiwg-tools mailing list >>>> mpiwg-tools(a)lists.mpi-forum.org >>>><mailto:[email protected]> >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >>> >>> _________________________________________________________________ >>> Kathryn Mohror, kathryn(a)llnl.gov >>> <mailto:[email protected]>, http://scalability.llnl.gov/ >>> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, >>> CA, USA >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>------------------------------------------------------------------------ >>>- >>>----------------------- >>> >>>------------------------------------------------------------------------ >>>- >>>----------------------- >>> Forschungszentrum Juelich GmbH >>> 52425 Juelich >>> Sitz der Gesellschaft: Juelich >>> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 >>> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher >>> Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), >>> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, >>> Prof. Dr. Sebastian M. Schmidt >>> >>>------------------------------------------------------------------------ >>>- >>>----------------------- >>> >>>------------------------------------------------------------------------ >>>- >>>----------------------- >>> >>> <tools-3.pdf>_______________________________________________ >>> mpiwg-tools mailing list >>> mpiwg-tools(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >> >> >>-- >>Jeff Squyres >>jsquyres(a)cisco.com >>For corporate legal information go to: >>http://www.cisco.com/web/about/doing_business/legal/cri/ >> >>_______________________________________________ >>mpiwg-tools mailing list >>mpiwg-tools(a)lists.mpi-forum.org >>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >

1 0

Meeting reminder: Thursday August 7
by Mohror, Kathryn 06 Aug '14

06 Aug '14

Hi all, This is a reminder of our regularly scheduled meeting for tomorrow at 11 AM EDT, 8 AM PDT. As always, the information to join the meeting is on the wiki: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools Agenda: - Ticket #383 (the ³same name, same meaning² ticket). We need to get this nailed down, so I am hoping that will happen during this call. The current text is attached. - Should there be time left over - Refresh status of outstanding tickets - Discuss directions for tools group since most fixes for MPI-3 additions seem to be winding down Talk to you soon! Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

Re: [mpiwg-tools] The infernal "things must be identical" text (was: Meeting reminder for April 3 11:00 AM EDT, 8:00 AM PDT)
by Kathryn Mohror 04 Aug '14

04 Aug '14

Thanks Michael! I¹ve attached a first stab at putting the table back into the document. Please take a look if you can, and we¹ll discuss it more later this week during the call. Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA On 7/25/14, 4:04 AM, "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> wrote: >Thanks Michael; that's helpful -- I see it there on page 3. > >Perhaps we can blend this table with the current text to get what we >want...? E.g., text about the same semantics, categories with same >name/class, ...etc. > > > >On Jul 25, 2014, at 4:53 AM, Michael Knobloch <m.knobloch(a)fz-juelich.de> >wrote: > >> Hi all, >> >> no need to scan the page if you have some structure in your mails ;-). >> >> Here's the original mail with the version I've shown yesterday. >> >> -Michael >> >> -------- Original Message -------- >> Subject: Re: [mpiwg-tools] Meeting reminder for April 3 11:00 AM >>EDT, >> 8:00 AM PDT >> Date: Fri, 4 Apr 2014 00:35:15 +0200 >> From: Kathryn Mohror <kathryn(a)llnl.gov> >> Reply-To: mpiwg-tools(a)lists.mpi-forum.org >><mpiwg-tools(a)lists.mpi-forum.org> >> To: mpiwg-tools(a)lists.mpi-forum.org >><mpiwg-tools(a)lists.mpi-forum.org> >> >> >> >> Hi everybody, >> >> In case you're just *dying* to see what the changes for ticket 383 look >> like from our discussions today and from Adam's feedback, I have >> attached the new document. >> >> Also, Adam's comments were basically that he didn't understand the >> meaning of the table, so I changed it up and he likes it now. >> >> Kathryn >> >> >> On Apr 3, 2014, at 8:56 AM, Kathryn Mohror <kathryn(a)llnl.gov >> <mailto:[email protected]>> wrote: >> >>> Hi all, >>> >>> I put notes from today's meeting on the wiki: >>> >>> >>>https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools/notes-2014-0 >>>4-03 >>> >>> Kathryn >>> >>> On Apr 2, 2014, at 11:50 AM, Kathryn Mohror <kathryn(a)llnl.gov >>> <mailto:[email protected]>> wrote: >>> >>>> Hi all, >>>> >>>> This is a reminder of our regularly scheduled call tomorrow at 11:00 >>>> AM Eastern and 8:00 AM Pacific. As always, the sign in information >>>> for the call is on the tools >>>> wiki: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools >>>> >>>> I drafted some text for 383 (the 'variables with the same name must >>>> have same meaning' errata ticket). We can tear it apart on the call. >>>> The document is attached if you want to look at it in advance. >>>> >>>> Talk to you tomorrow! >>>> Kathryn >>>> >>>> >>>> _________________________________________________________________ >>>> Kathryn Mohror, kathryn(a)llnl.gov >>>> <mailto:[email protected]>, http://scalability.llnl.gov/ >>>> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, >>>> CA, USA >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> <tools-3.pdf> >>> >>> _________________________________________________________________ >>> Kathryn Mohror, kathryn(a)llnl.gov >>> <mailto:[email protected]>, http://scalability.llnl.gov/ >>> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, >>> CA, USA >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> mpiwg-tools mailing list >>> mpiwg-tools(a)lists.mpi-forum.org >>><mailto:[email protected]> >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >> >> _________________________________________________________________ >> Kathryn Mohror, kathryn(a)llnl.gov >> <mailto:[email protected]>, http://scalability.llnl.gov/ >> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, >> CA, USA >> >> >> >> >> >> >> >> >> >> >> >> >> >>------------------------------------------------------------------------- >>----------------------- >> >>------------------------------------------------------------------------- >>----------------------- >> Forschungszentrum Juelich GmbH >> 52425 Juelich >> Sitz der Gesellschaft: Juelich >> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 >> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher >> Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), >> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, >> Prof. Dr. Sebastian M. Schmidt >> >>------------------------------------------------------------------------- >>----------------------- >> >>------------------------------------------------------------------------- >>----------------------- >> >> <tools-3.pdf>_______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > >-- >Jeff Squyres >jsquyres(a)cisco.com >For corporate legal information go to: >http://www.cisco.com/web/about/doing_business/legal/cri/ > >_______________________________________________ >mpiwg-tools mailing list >mpiwg-tools(a)lists.mpi-forum.org >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0

Re: [mpiwg-tools] Meeting reminder: July 24
by Kathryn Mohror 04 Aug '14

04 Aug '14

Hi all, Here are the notes from the last meeting. I will update the text for the ticket #383 to contain the table this evening or tomorrow and send it out so people have time to look at it before Thursday. https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools/notes-2014-07-2 4 Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA On 7/23/14, 9:16 AM, "Kathryn Mohror" <kathryn(a)llnl.gov> wrote: >Hi all, > >It¹s that time again. We¹ll have our regularly scheduled meeting tomorrow >at 11:00 AM EDT/8:00 AM PDT. As always, the link to join the meeting is on >the wiki: > >https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools > > >Agenda: >- Ticket #383. It seems at the reading at the last meeting that the wrong >text was inadvertently used. Is what is attached to the ticket actually >correct? > - We need to get this fixed and voted in soon, hopefully in the Japan >meeting, so let¹s plan on concentrating on this during the majority of the >call >- Should there be time left over > - Refresh status of outstanding tickets > - Discuss directions for tools group since most fixes for MPI-3 >additions seem to be winding down > >Kathryn > > >_________________________________________________________________ >Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ >Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, >USA > > > > > >_______________________________________________ >mpiwg-tools mailing list >mpiwg-tools(a)lists.mpi-forum.org >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0