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

Re: [mpiwg-tools] Meeting reminder for tomorrow
by Kathryn Mohror 18 Nov '14

18 Nov '14

Hi all, Some brief notes for the last meeting are up at: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools/notes-2014-11-1 3 Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA On 11/12/14, 3:40 PM, "Mohror, Kathryn" <mohror1(a)llnl.gov> wrote: >Hi all, > >We'll have our regular meeting tomorrow 11am EST, 8am PST. As always, the >call in information is on the wiki: >https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools > >Agenda: > - Everyone's favorite ticket #383, aka the "you know what I mean" ticket > - ticket #394: errata, clarification of watermark variable starting >values > >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

Re: [mpiwg-tools] proposed text
by Marc-Andre Hermanns 18 Nov '14

18 Nov '14

Hi Kathryn, if I understood right its a bit of both. We want to indicate that "our" strings (or their handling) are different from the rest of the standard, hence "MPI_T string" would be a good start. However, as I understand Jeff, it implies that "this is how MPI_T handles strings everywhere" and if we need some other handling of strings in MPI_T, we are then stuck with a name that implies the full scope of MPI_T when it does not provide it. What about "quasi-identical" strings to explicitly name what we want to express. Something along the lines of: Quasi-identical strings in MPI_T are strings that behave as if they are generated by a prefix-copy operation from a common source up to the length provided locally to the call returning the string. With something like this, we could then say, "foo" is a quasi-identical strings as discussed in 14.3.3, wherever we need it, e.g., for name and desc in the respective calls. What do you think? Cheers, Marc-Andre On 18.11.14 21:25, Kathryn Mohror wrote: > I'm a bit lost on the intended meaning behind the name: <foo> strings. > > Do you want <foo> strings to indicate all strings in the MPI tool > information interface that are by our definition in 14.3.3 treated > differently than in the rest of the standard? And then have a concept of > identical <foo> strings and specify what is returned in the user's buffer > for identical <foo> strings? > > > Or is <foo> strings supposed to only indicate strings that if identical, > have a particular defined behavior that determine what is returned into > the user's buffer according to our string conventions in 14.3.3? > > Thanks, > Kathryn > >>>> - so up in 14.3.3, have a definition for "<foo> strings" (someone come >>>> up >>>> with a better name than "<foo>"): >>> >>> MPI_T strings? >> >> Mmm. That would imply that these are the *only* type of strings that are >> used in MPI_T. That may be true today, but I don't know if we want to be >> locked in to that generalization for forever. >> >> How about "MPI_T universal strings"? >> >> -- >> 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 > -- Marc-Andre Hermanns Jülich Aachen Research Alliance, High Performance Computing (JARA-HPC) German Research School for Simulation Sciences GmbH Schinkelstrasse 2 52062 Aachen Germany Phone: +49 241 80 99753 Fax: +49 241 80 6 99753 www.grs-sim.de/parallel email: m.a.hermanns(a)grs-sim.de

1 0

Re: [mpiwg-tools] proposed text
by Kathryn Mohror 18 Nov '14

18 Nov '14

I'm a bit lost on the intended meaning behind the name: <foo> strings. Do you want <foo> strings to indicate all strings in the MPI tool information interface that are by our definition in 14.3.3 treated differently than in the rest of the standard? And then have a concept of identical <foo> strings and specify what is returned in the user's buffer for identical <foo> strings? Or is <foo> strings supposed to only indicate strings that if identical, have a particular defined behavior that determine what is returned into the user's buffer according to our string conventions in 14.3.3? Thanks, Kathryn >>> - so up in 14.3.3, have a definition for "<foo> strings" (someone come >>>up >>> with a better name than "<foo>"): >> >> MPI_T strings? > >Mmm. That would imply that these are the *only* type of strings that are >used in MPI_T. That may be true today, but I don't know if we want to be >locked in to that generalization for forever. > >How about "MPI_T universal strings"? > >-- >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] proposed text
by Jeff Squyres (jsquyres) 14 Nov '14

14 Nov '14

On Nov 13, 2014, at 12:26 PM, Schulz Martin <schulzm(a)llnl.gov> wrote: >> - so up in 14.3.3, have a definition for "<foo> strings" (someone come up >> with a better name than "<foo>"): > > MPI_T strings? Mmm. That would imply that these are the *only* type of strings that are used in MPI_T. That may be true today, but I don't know if we want to be locked in to that generalization for forever. How about "MPI_T universal strings"? -- 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] proposed text
by Schulz Martin 13 Nov '14

13 Nov '14

Hi all, Comments inline below. Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ CASC @ Lawrence Livermore National Laboratory, Livermore, USA On 11/13/14, 9:06 AM, "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> wrote: >Here's what I understand from Martin+me at the end of the call: > >- name and desc are OUT strings, for both control and perf vars. So we >need to have this whole mess apply to all 4 cases. There are actually 6 cases - two more for the categories. >- we keep the idea of separating the two concepts: > 1. the (conceptual) internal value for the string, which will be >identical across connected processes > 2. copying it to an output buffer, where it may be truncated Yes, agreed. >- so up in 14.3.3, have a definition for "<foo> strings" (someone come up >with a better name than "<foo>"): MPI_T strings? > - an MPI implementation behaves if the string is identical across all >connected processes Not sure what you mean with behaves - I think you mean we define what identical means in 14.3.3 (which is trivial) and then say what this means when copied into output buffer. Something like: If two MPI_T strings are identical, the corresponding routine returning the string returns, for any length parameter passed into the routine, an identical content in the string buffer up to the null terminating character. > - when this string is copied to an output buffer, it may be truncated >(e.g., if the user specifies an output buffer length that is too small). > >- Then in the four cases (name/desc for control/perf vars), say that they >are <foo> strings. For example, "desc is a <foo> string (see section >14.3.3)". Yes, this should go into the actual parameter/argument specification of the prototype and then we just say if the name is identical, the following OUT parameters, , and the description has to be identical as well > >Something along these lines... > >-- >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

proposed text
by Jeff Squyres (jsquyres) 13 Nov '14

13 Nov '14

Here's what I understand from Martin+me at the end of the call: - name and desc are OUT strings, for both control and perf vars. So we need to have this whole mess apply to all 4 cases. - we keep the idea of separating the two concepts: 1. the (conceptual) internal value for the string, which will be identical across connected processes 2. copying it to an output buffer, where it may be truncated - so up in 14.3.3, have a definition for "<foo> strings" (someone come up with a better name than "<foo>"): - an MPI implementation behaves if the string is identical across all connected processes - when this string is copied to an output buffer, it may be truncated (e.g., if the user specifies an output buffer length that is too small). - Then in the four cases (name/desc for control/perf vars), say that they are <foo> strings. For example, "desc is a <foo> string (see section 14.3.3)". Something along these lines... -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Meeting reminder for tomorrow
by Mohror, Kathryn 12 Nov '14

12 Nov '14

Hi all, We'll have our regular meeting tomorrow 11am EST, 8am PST. As always, the call in information is on the wiki: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools Agenda: - Everyone's favorite ticket #383, aka the "you know what I mean" ticket - ticket #394: errata, clarification of watermark variable starting values Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

ticket #394: clarification of starting values of watermark variables
by Mohror, Kathryn 12 Nov '14

12 Nov '14

Hi all, I drafted some text to clarify the descriptions of the high and low watermark performance variables. There was a question on what the starting values of the variables were, and hopefully the changed text makes that more clear. I believe this is an errata ticket since it is just clarification. I attached the updated document for comment, and we can discuss it tomorrow on the call. 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] Ticket 383: Variables with the same name ticket
by Kathryn Mohror 11 Nov '14

11 Nov '14

Hi all, I have updated the chapter PDF based on my notes from the last meeting I attended (10/2). The basic change was to make it clear what the contents of desc and desc_len should be in the _get_info routines for control and performance variables across connected processes. I left out changes that we discussed regarding maximum string lengths, because from the email list it looks like you all decided that that issue should be a separate ticket (with which I whole-heartedly agree). So, please have a look at it if you can before our meeting on Thursday. I know you're busy with SC preparations, but it's only two small changes! You have time! :-) Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA On 8/31/14, 3:07 PM, "Schulz Martin" <schulzm(a)llnl.gov> wrote: >Hi Kathryn, > >The text misses the INOUT/OUT instead of just OUT on page 34, line 10, >otherwise this looks good to me. > >Thanks! > >Martin > >________________________________________________________________________ >Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ >CASC @ Lawrence Livermore National Laboratory, Livermore, USA > > > > > >On 8/30/14, 4:44 PM, "Kathryn Mohror" <kathryn(a)llnl.gov> wrote: > >>Hi Martin, >> >>Thanks for the feedback. I incorporated it and attached the new copy. >> >>Anyone else have comments? >> >>Thanks! >>Kathryn >>_________________________________________________________________ >>Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ >>Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, >>USA >> >> >> >> >> >> >>On 8/30/14, 1:22 AM, "Schulz Martin" <schulzm(a)llnl.gov> wrote: >> >>>Hi Kathryn, all, >>> >>>Thanks for putting this together. I think, this looks almost right. Just >>>the string returns are not quite right, I think. What about adding the >>>following: >>> >>> >>>Page 15: >>> >>> >>> >>> >>> >>> >>> >>> >>> If the name of a control variable is the same across connected >>>processes, the following OUT parameters must be identical: verbosity, >>>datatype, enumtype, desc, desc_len, bind, scope. >>>-> >>>If the name of a control variable is the same across connected >>>processes, >>>the following INOUT/OUT parameters must be identical: verbosity, >>>datatype, >>>enumtype, desc, desc_len, bind, scope (assuming identical values are >>>passed in desc_len). >>> >>> >>> >>>Same on page 24: >>>If the name and class of a performance variable are the same across >>>connected processes, >>>the following OUT parameters must be identical: verbosity, varclass, >>>datatype, enumtype, >>>desc, desc_len, bind, readonly, continuous, atomic. >>>-> >>> >>> >>> >>> >>>If the name and class of a performance variable are the same across >>>connected processes, >>>the following INOUT/OUT parameters must be identical: verbosity, >>>varclass, >>>datatype, enumtype, >>>desc, desc_len, bind, readonly, continuous, atomic (assuming identical >>>values are passed in desc_len). >>> >>> >>>Same on page 34 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> If the name of a category is the same across connected processes, >>>the >>>following OUT >>>parameters must be identical: desc, desc_len. >>>-> >>>If the name of a category is the same across connected processes, the >>>following INOUT/OUT >>>parameters must be identical: desc, desc_len (assuming identical values >>>are passed in desc_len). >>> >>> >>>Martin >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>________________________________________________________________________ >>>Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ >>>CASC @ Lawrence Livermore National Laboratory, Livermore, USA >>> >>> >>> >>> >>> >>>On 8/29/14, 6:10 PM, "Kathryn Mohror" <kathryn(a)llnl.gov> wrote: >>> >>>>Hi all, >>>> >>>>Here¹s a draft of the tools chapter with changes for ticket #383 based >>>>on >>>>our last discussion. Let¹s see if we can get this nailed down to read >>>>in >>>>Japan. >>>> >>>>Please see the attached, and keep in mind that the due date for ticket >>>>announcements is MONDAY! >>>> >>>>Thanks, >>>>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 >> > > >_______________________________________________ >mpiwg-tools mailing list >mpiwg-tools(a)lists.mpi-forum.org >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0