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

Re: [mpiwg-tools] proposed text
by Jeff Squyres (jsquyres) 22 Nov '14

22 Nov '14

In general, this is going in a good direction -- thanks for all the work while we were shanghaied by SC! I have one major suggested change and several nit picks to the version Kathryn sent Nov 21 at 11:48am: Major change ============ p9:40-p10:1 reads: Because the string length argument, n, to these routines influences the number of characters returned, and because the value of n could differ across MPI processes, strings returned from query routines that represent the same entity across connected processes must be equivalent according to the following definition. Strings are equivalent if the MPI implementation behaves as if it has an identical character array in each MPI process for the string in question across connected processes. The contents of the returned string will be identical to that of the internal character array, but possibly truncated at any process that supplies an n value to the query routine that is smaller than the length of the internal character array. I'd change it to be: MPI implementations behave as if they have an internal character array that is copied to the output character array supplied by the user. Such output strings are defined to be equivalent if their notional source internal character arrays are identical (up to and including the null terminator), even if the output string is truncated due to a small n length parameter. Nit picks ========= 1. p7:23-26 reads: Variables and categories across connected processes with equivalent names are required to have the same meaning (For the definition of equivalent as it relates to strings in this section, please refer to Section 14.3.3). I'd change the parenthetical to: Variables and categories across connected processes with equivalent names are required to have the same meaning (***please see the definition of "equivalent" as related to strings in*** Section 14.3.3). 3. p7:27-28 says: For example, variables describing the number of packets sent on heterogeneous network devices should have different names to reflect their potentially different meanings. I'd change it to be: For example, variables describing the number of packets sent on ***different types of*** network devices should have different names to reflect their potentially different meanings. I know that "heterogeneous" means "different types", but that word carries a different connotation here, IMHO -- "heterogeneity" is somewhat of a loaded word in HPC environments (e.g., it's usually applied to processors and brings up a slightly confusing context here -- so let's just avoid it). Enumerations ============ Yes, enumerated values must *not* be defined as equivalent. I have a concrete example why they should not be equivalent: - Remember that I want to use enumerated values to contain information about the underlying network - The network interface used by MPI processes on server A has network address "A.B.C.D", but the NI used by MPI processes on server B has address "W.X.Y.Z". On Nov 21, 2014, at 11:48 AM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: > The updated version is attached. Please comment if you have a chance so we > can get this done by Monday. > > Thank you! > Kathryn > _________________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ > Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, > USA > > > > > > > On 11/21/14, 7:09 AM, "Kathryn Mohror" <kathryn(a)llnl.gov> wrote: > >> Thanks for the feedback Michael and Marc-Andre! I'll make the changes >> later this morning and send them out. >> >> Kathryn >> _________________________________________________________________ >> Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ >> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, >> USA >> >> >> >> >> >> >> On 11/21/14, 2:38 AM, "Marc-Andre Hermanns" <m.a.hermanns(a)grs-sim.de> >> wrote: >> >>> Hi all, >>> >>>> I have an issue with the new text. I'm not sure if I'm missing a >>>> point, but for me the equivalence text is redundant. I fail to see a >>>> difference between (page 9, lines 43ff) >>>> >>>> Strings are equivalent if the MPI implementation behaves as if it has >>>> an identical character array in each MPI process for the string in >>>> question across connected processes. The contents of the returned >>>> string will be identical to that of the internal character array, but >>>> possibly truncated at any process that supplies an n value to the >>>> query routine that is smaller than the length of the internal >>>> character array. >>> >>> I also think this covers all cases. >>> >>> a) a string is equivalent to its internal "source" if it behaves as if >>> being copies from it up the the given length. >>> >>> b) two strings are equivalent when they behave as if the originate from >>> an identical source. >>> >>>> and (page 10, lines 1ff) >>>> >>>> Two strings are equivalent if the internal character array for each >>>> MPI process is identical by a character-by-character comparison, and >>>> in the output buffer, any arbitrary combination of length arguments >>>> result in the same string-prefix up to the smaller of the two lengths. >>>> >>>> So I'll probably would remove the second part (although I still like >>>> the wording). >>>> >>>> Any opinions on that? >>> >>> I talked to Michael on this, and I also think the second part can be >>> omitted. >>> >>>> The rest looks fine so far. >>> >>> dito. >>> >>> Cheers, >>> Marc-Andre >>> -- >>> 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 >>> >> >> >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > <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/

1 0

Re: [mpiwg-tools] OFF-SCHEDULE MEETING
by Kathryn Mohror 21 Nov '14

21 Nov '14

For any who can make the meeting on Monday, here's the webex information: JOIN WEBEX MEETING https://llnl.webex.com/llnl/j.php?MTID=mfc998e9f1f79a7404d42e336b68a3859 Meeting number: 801 603 034 Meeting password: meetme JOIN BY PHONE +1-415-655-0001 US TOLL Access code: 801 603 034 Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA On 11/21/14, 10:03 AM, "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> wrote: >I'm sorry; I will be unable to attend (I'm on vacation all next week). > >Good luck with the text! > > >On Nov 21, 2014, at 10:15 AM, Mohror, Kathryn <mohror1(a)llnl.gov> wrote: > >> Hi all, >> >> Given that we need to announce the tickets we want read at the December >> forum meeting by 2:00 PM PST on Monday the 24th (this coming Monday), >> let's have a meeting for anyone who can join at 8:00 AM PST, 11:00 AM >>EST >> Monday. >> >> If that time doesn't work and you want to give input, let me know. If >> there are enough time conflicts, we can try to move the meeting. >>However, >> this time slot seems to be the best for people's schedules in general. >>(I >> do know this time conflicts with the regular MPI Handles meeting, but I >> think that meeting has been on hold lately? Correct me if I am wrong.) >> >> We'll discuss the final (hopefully) touches on ticket #383 (the "you >>know >> what I mean" ticket). >> >> 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 > > >-- >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] OFF-SCHEDULE MEETING
by Jeff Squyres (jsquyres) 21 Nov '14

21 Nov '14

I'm sorry; I will be unable to attend (I'm on vacation all next week). Good luck with the text! On Nov 21, 2014, at 10:15 AM, Mohror, Kathryn <mohror1(a)llnl.gov> wrote: > Hi all, > > Given that we need to announce the tickets we want read at the December > forum meeting by 2:00 PM PST on Monday the 24th (this coming Monday), > let's have a meeting for anyone who can join at 8:00 AM PST, 11:00 AM EST > Monday. > > If that time doesn't work and you want to give input, let me know. If > there are enough time conflicts, we can try to move the meeting. However, > this time slot seems to be the best for people's schedules in general. (I > do know this time conflicts with the regular MPI Handles meeting, but I > think that meeting has been on hold lately? Correct me if I am wrong.) > > We'll discuss the final (hopefully) touches on ticket #383 (the "you know > what I mean" ticket). > > 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 -- 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 Kathryn Mohror 21 Nov '14

21 Nov '14

The updated version is attached. Please comment if you have a chance so we can get this done by Monday. Thank you! Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA On 11/21/14, 7:09 AM, "Kathryn Mohror" <kathryn(a)llnl.gov> wrote: >Thanks for the feedback Michael and Marc-Andre! I'll make the changes >later this morning and send them out. > >Kathryn >_________________________________________________________________ >Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ >Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, >USA > > > > > > >On 11/21/14, 2:38 AM, "Marc-Andre Hermanns" <m.a.hermanns(a)grs-sim.de> >wrote: > >>Hi all, >> >>> I have an issue with the new text. I'm not sure if I'm missing a >>> point, but for me the equivalence text is redundant. I fail to see a >>> difference between (page 9, lines 43ff) >>> >>> Strings are equivalent if the MPI implementation behaves as if it has >>> an identical character array in each MPI process for the string in >>> question across connected processes. The contents of the returned >>> string will be identical to that of the internal character array, but >>> possibly truncated at any process that supplies an n value to the >>> query routine that is smaller than the length of the internal >>> character array. >> >>I also think this covers all cases. >> >>a) a string is equivalent to its internal "source" if it behaves as if >>being copies from it up the the given length. >> >>b) two strings are equivalent when they behave as if the originate from >>an identical source. >> >>> and (page 10, lines 1ff) >>> >>> Two strings are equivalent if the internal character array for each >>> MPI process is identical by a character-by-character comparison, and >>> in the output buffer, any arbitrary combination of length arguments >>> result in the same string-prefix up to the smaller of the two lengths. >>> >>> So I'll probably would remove the second part (although I still like >>> the wording). >>> >>> Any opinions on that? >> >>I talked to Michael on this, and I also think the second part can be >>omitted. >> >>> The rest looks fine so far. >> >>dito. >> >>Cheers, >>Marc-Andre >>-- >>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 >> > > >_______________________________________________ >mpiwg-tools mailing list >mpiwg-tools(a)lists.mpi-forum.org >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0

OFF-SCHEDULE MEETING
by Mohror, Kathryn 21 Nov '14

21 Nov '14

Hi all, Given that we need to announce the tickets we want read at the December forum meeting by 2:00 PM PST on Monday the 24th (this coming Monday), let's have a meeting for anyone who can join at 8:00 AM PST, 11:00 AM EST Monday. If that time doesn't work and you want to give input, let me know. If there are enough time conflicts, we can try to move the meeting. However, this time slot seems to be the best for people's schedules in general. (I do know this time conflicts with the regular MPI Handles meeting, but I think that meeting has been on hold lately? Correct me if I am wrong.) We'll discuss the final (hopefully) touches on ticket #383 (the "you know what I mean" ticket). Thanks, 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] proposed text
by Kathryn Mohror 21 Nov '14

21 Nov '14

Thanks for the feedback Michael and Marc-Andre! I'll make the changes later this morning and send them out. Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA On 11/21/14, 2:38 AM, "Marc-Andre Hermanns" <m.a.hermanns(a)grs-sim.de> wrote: >Hi all, > >> I have an issue with the new text. I'm not sure if I'm missing a >> point, but for me the equivalence text is redundant. I fail to see a >> difference between (page 9, lines 43ff) >> >> Strings are equivalent if the MPI implementation behaves as if it has >> an identical character array in each MPI process for the string in >> question across connected processes. The contents of the returned >> string will be identical to that of the internal character array, but >> possibly truncated at any process that supplies an n value to the >> query routine that is smaller than the length of the internal >> character array. > >I also think this covers all cases. > >a) a string is equivalent to its internal "source" if it behaves as if >being copies from it up the the given length. > >b) two strings are equivalent when they behave as if the originate from >an identical source. > >> and (page 10, lines 1ff) >> >> Two strings are equivalent if the internal character array for each >> MPI process is identical by a character-by-character comparison, and >> in the output buffer, any arbitrary combination of length arguments >> result in the same string-prefix up to the smaller of the two lengths. >> >> So I'll probably would remove the second part (although I still like >> the wording). >> >> Any opinions on that? > >I talked to Michael on this, and I also think the second part can be >omitted. > >> The rest looks fine so far. > >dito. > >Cheers, >Marc-Andre >-- >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 Marc-Andre Hermanns 21 Nov '14

21 Nov '14

Hi all, > I have an issue with the new text. I'm not sure if I'm missing a > point, but for me the equivalence text is redundant. I fail to see a > difference between (page 9, lines 43ff) > > Strings are equivalent if the MPI implementation behaves as if it has > an identical character array in each MPI process for the string in > question across connected processes. The contents of the returned > string will be identical to that of the internal character array, but > possibly truncated at any process that supplies an n value to the > query routine that is smaller than the length of the internal > character array. I also think this covers all cases. a) a string is equivalent to its internal "source" if it behaves as if being copies from it up the the given length. b) two strings are equivalent when they behave as if the originate from an identical source. > and (page 10, lines 1ff) > > Two strings are equivalent if the internal character array for each > MPI process is identical by a character-by-character comparison, and > in the output buffer, any arbitrary combination of length arguments > result in the same string-prefix up to the smaller of the two lengths. > > So I'll probably would remove the second part (although I still like > the wording). > > Any opinions on that? I talked to Michael on this, and I also think the second part can be omitted. > The rest looks fine so far. dito. Cheers, Marc-Andre -- 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 Michael Knobloch 21 Nov '14

21 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I have an issue with the new text. I'm not sure if I'm missing a point, but for me the equivalence text is redundant. I fail to see a difference between (page 9, lines 43ff) Strings are equivalent if the MPI implementation behaves as if it has an identical character array in each MPI process for the string in question across connected processes. The contents of the returned string will be identical to that of the internal character array, but possibly truncated at any process that supplies an n value to the query routine that is smaller than the length of the internal character array. and (page 10, lines 1ff) Two strings are equivalent if the internal character array for each MPI process is identical by a character-by-character comparison, and in the output buffer, any arbitrary combination of length arguments result in the same string-prefix up to the smaller of the two lengths. So I'll probably would remove the second part (although I still like the wording). Any opinions on that? The rest looks fine so far. - -Michael On 11/20/2014 08:58 PM, Kathryn Mohror wrote: > Hi all, > > Here's the latest text based on the conversation during the > impromptu meeting Marc-Andre, Michael and I had this morning. > > JEFF: The question of whether we want to include enumerations in > the requirements for equivalency. I know you had an argument > against this at some point, but I can't find it in my notes. Thus, > in the attached document, I put a place holder where we might want > to consider adding enumerations marked with "JEFF". > > - We worked out the text such that we don't need to name strings > (as in <foo> strings), but simply refer to the concept of strings > being equivalent. - This simplified the text that needed to go in > the *_get_info routines. > > Marc-Andre and Michael, please let me know if I missed any of your > points! > > > All: for the {pvar,cvar}_get_index routines, do we need to be more > specific about what the contents of 'name' are and what 'matches' > means given the text we have added for 383? > > Kathryn > _________________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ > Scalability Team @ Lawrence Livermore National Laboratory, > Livermore, CA, USA > > > > > > > On 11/20/14, 6:00 AM, "Marc-Andre Hermanns" > <m.a.hermanns(a)grs-sim.de> wrote: > >> Hi Kathryn, >> >> you used the <foo>=MPI_T version right? >> >> What do you think about this: >> >> ---o---o---o---o--- 14.3.3 >> >> ... Several query functions of the MPI_T interface return >> information encoded in C strings. A user of these query routines >> can influence the concrete length of the output through INOUT >> length parameters to these calls, potentially resulting in a >> truncated string. As the INOUT length parameters are allowed to >> vary across different invocations of a call, two strings returned >> by subsequent calls with varying length arguments but otherwise >> identical arguments may not be identical as defined by the result >> of the strcmp family of calls. However, they have to be >> equivalent. In the scope of the MPI_T interface, two strings are >> regarded equivalent, if any arbitrary combination of length >> arguments result in the same string-prefix up to the smaller of >> the two lengths. >> >> ---o---o---o---o--- >> >> This goes back to Michael's initial idea of regarding "pairs of >> strings". Again, some of my prose may be convoluted and I am open >> to any revision. ;-) >> >> And then we don't need the "MPI_T" string at all, as the >> equivalence is all the "specialness" we want from our strings. >> Thus, we can then (at those 6 places) just state: "parameters foo >> and bar have to be equivalent as described in 14.3.3." >> >> What do you think? >> >> Cheers, Marc-Andre >> >> >> On 19.11.14 21:53, Kathryn Mohror wrote: >>> Okay, here's a draft attempting to capture what Jeff and Martin >>> were getting at in the last meeting. I made changes to 14.3.3 >>> and to the text of the get_info routines for name and desc >>> parameters, and to the last paragraph for the routine >>> description. >>> >>> Have at it! >>> >>> Kathryn >>> _________________________________________________________________ >>> >>> Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ >>> Scalability Team @ Lawrence Livermore National Laboratory, >>> Livermore, CA, USA >>> >>> >>> >>> >>> >>> >>> On 11/19/14, 12:17 PM, "Kathryn Mohror" <kathryn(a)llnl.gov> >>> wrote: >>> >>>> Thanks Bronis. I like the suggestion of equivalence instead >>>> of identical. >>>> >>>> Kathryn >>>> >>>> >>>>> >>>>> "quasi-identical" and its variants sounds horrible to me >>>>> without even looking at the context. What do you want to >>>>> require? "functionally equivalent"? I think you need to >>>>> move away from the word "identical" and think instead in >>>>> terms of "equivalence"... >>>>> >>>>> On Wed, 19 Nov 2014, Marc-Andre Hermanns wrote: >>>>> >>>>>> Hi Kathryn, >>>>>> >>>>>>>> I think we don't have to search&replace the word >>>>>>>> string for <foo> string throughout the chapter. I >>>>>>>> think we only need to define <foo> string in 14.3.3 >>>>>>>> and then state for the 6 parameters so far that those >>>>>>>> are foo strings. >>>>>>> >>>>>>> Okay, I'll work on it and try to integrate it cleanly. >>>>>>>> >>>>>>>> By and large <foo> strings are just like other C >>>>>>>> string. We just have additional requirements to what >>>>>>>> "identical" means. That is why I came up with the >>>>>>>> name: "quasi-identical", because they are not >>>>>>>> identical in the normal C string sense (str*cmp). As >>>>>>>> "quasi-identical" is a new kind of string, that >>>>>>>> probably no-one heard in a different context, so has >>>>>>>> no preoccupation on what it could mean, a reader >>>>>>>> should go: "What's that?" and refer to Section >>>>>>>> 14.3.3. >>>>>>>> >>>>>>>> What's the groups take on the name >>>>>>>> "quasi-identical"? >>>>>>> >>>>>>> I'm not totally sold on 'quasi-identical' but possibly >>>>>>> because I don't use the prefix 'quasi' very often. >>>>>>> Also, I almost think that it takes away from the fact >>>>>>> that the internal representation of the strings does >>>>>>> need to be identical, but what is passed to the user >>>>>>> may be different due to truncation. >>>>>> >>>>>> Yes, the "quasi" might be a German thing, although I >>>>>> think is also exists in English. I am open to any other >>>>>> suggestion. >>>>>> >>>>>> For the the quasi just expresses their actual state, we >>>>>> regard them as identical, although the actual strings >>>>>> returned do not have to the identical in the strcmp sense >>>>>> (due to different length). So they are identical and at >>>>>> the same time they are not. That is a little "quasi" to >>>>>> me ;-) >>>>>> >>>>>> What about: >>>>>> >>>>>> prospect-identical? source-identical? >>>>>> >>>>>>> That said, I don't have a replacement suggestion right >>>>>>> this second. >>>>>> >>>>>>>> Should we have an "out-of-order" telco tomorrow to >>>>>>>> discuss this? As we need to finalize our wording by >>>>>>>> Monday in order for 383 to be an errata, I think we >>>>>>>> need to make progress before the weekend. >>>>>>> >>>>>>> I'm not sure if that will work with everyone at SC. It >>>>>>> would coincide with the 10:00 AM technical papers >>>>>>> sessions. I suppose though if people pipe up that they >>>>>>> would be able to join, that would be good and I would >>>>>>> be able to be on the call. Of course, as you say in >>>>>>> your post script, we could pick another time, too. >>>>>> >>>>>> Obviously, I am fine with any earlier time slot, but that >>>>>> would not go well with pacific time. I would have more >>>>>> again after 8 pm CET. Maybe the people at SC suggest a >>>>>> time that fits into the program for them? >>>>>> >>>>>> Cheers, Marc-Andre >>>>>> >>>>>> -- 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 >>>>>> >>>> >>>> >>>> _______________________________________________ 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 >> > > > > _______________________________________________ mpiwg-tools mailing > list mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > - -- Michael Knobloch Institute for Advanced Simulation (IAS) Jülich Supercomputing Centre (JSC) Telefon: +49 2461 61-3546 Telefax: +49 2461 61-6656 E-Mail: m.knobloch(a)fz-juelich.de Internet: http://www.fz-juelich.de/jsc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUbwxdAAoJENAucJeJjnBJDscQALLi5kSZuf23hGqNvTmvdiuL JeG7KC6Z9zmc1SDsQP9cagSuN8hBKwwgDbenxztNmvpofrTAQymkJM4MWj4aW11O fn7fDS0HQL+2eaC282Js6D7bPBl1lkW3WShlqLvC6sFgnkMpTUX9+mGe79f5Mxdt DgJeZQijiZynklku8W1/AH/BMofdAB5lG0kOcsZ9mDWgp9K4Z7o852Bp79NcJ9uV bjOM5wqW6K33KkraCXQ9E5Q7+DH/88BRs7fYRJlTsHE5N0//lsXBP5JkC+QyfH/3 NTdwIkrDEOZo5sV6iRhUN20OJMsEKWMa8Vmp4iHnGzziKXi6FT+9eOlByKdDGGfl R5vgCLcnCQSjLVC3jGSo5rTSsFHksDotDwN4A5PVLPFtdz77aTvqrYTY6UkSSoZC VeLZX1knz10CsRfXSApauddvYBTF8dZqpPLVf2pFbab9iG0MO96fkXWDb9CoLqv8 tG0KF7d9BL4Hh/sb2DW/Kec9hoaPKDtxDGyBXKWbdZH+JlbHzWJoTOpXBaGmlvr6 UCzFEGYxQeCk6qQte6u4ZZ9hpvJCkfZk/6U0ITgsnd0TWNTsn5U/hmddPJzxgq6O A6yo1eFnt2I2kkO68SWxLTv8LV0QOPQP7aWwG5fMY0Wlorxuyler5cBENJeO9p8q WRhfjiORy5llDppH92Zh =zHJ1 -----END PGP SIGNATURE----- ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------

1 0

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

20 Nov '14

Hi all, Here's the latest text based on the conversation during the impromptu meeting Marc-Andre, Michael and I had this morning. JEFF: The question of whether we want to include enumerations in the requirements for equivalency. I know you had an argument against this at some point, but I can't find it in my notes. Thus, in the attached document, I put a place holder where we might want to consider adding enumerations marked with "JEFF". - We worked out the text such that we don't need to name strings (as in <foo> strings), but simply refer to the concept of strings being equivalent. - This simplified the text that needed to go in the *_get_info routines. Marc-Andre and Michael, please let me know if I missed any of your points! All: for the {pvar,cvar}_get_index routines, do we need to be more specific about what the contents of 'name' are and what 'matches' means given the text we have added for 383? Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA On 11/20/14, 6:00 AM, "Marc-Andre Hermanns" <m.a.hermanns(a)grs-sim.de> wrote: >Hi Kathryn, > >you used the <foo>=MPI_T version right? > >What do you think about this: > >---o---o---o---o--- >14.3.3 > >... >Several query functions of the MPI_T interface return information >encoded in C strings. A user of these query routines can influence the >concrete length of the output through INOUT length parameters to these >calls, potentially resulting in a truncated string. As the INOUT length >parameters are allowed to vary across different invocations of a call, >two strings returned by subsequent calls with varying length arguments >but otherwise identical arguments may not be identical as defined by the >result of the strcmp family of calls. However, they have to be >equivalent. In the scope of the MPI_T interface, two strings are >regarded equivalent, if any arbitrary combination of length arguments >result in the same string-prefix up to the smaller of the two lengths. > >---o---o---o---o--- > >This goes back to Michael's initial idea of regarding "pairs of >strings". Again, some of my prose may be convoluted and I am open to any >revision. ;-) > >And then we don't need the "MPI_T" string at all, as the equivalence is >all the "specialness" we want from our strings. Thus, we can then (at >those 6 places) just state: "parameters foo and bar have to be >equivalent as described in 14.3.3." > >What do you think? > >Cheers, >Marc-Andre > > >On 19.11.14 21:53, Kathryn Mohror wrote: >> Okay, here's a draft attempting to capture what Jeff and Martin were >> getting at in the last meeting. I made changes to 14.3.3 and to the text >> of the get_info routines for name and desc parameters, and to the last >> paragraph for the routine description. >> >> Have at it! >> >> Kathryn >> _________________________________________________________________ >> Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ >> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, >>CA, >> USA >> >> >> >> >> >> >> On 11/19/14, 12:17 PM, "Kathryn Mohror" <kathryn(a)llnl.gov> wrote: >> >>> Thanks Bronis. I like the suggestion of equivalence instead of >>>identical. >>> >>> Kathryn >>> >>> >>>> >>>> "quasi-identical" and its variants sounds horrible to >>>> me without even looking at the context. What do you >>>> want to require? "functionally equivalent"? I think >>>> you need to move away from the word "identical" and >>>> think instead in terms of "equivalence"... >>>> >>>> On Wed, 19 Nov 2014, Marc-Andre Hermanns wrote: >>>> >>>>> Hi Kathryn, >>>>> >>>>>>> I think we don't have to search&replace the word string for <foo> >>>>>>> string >>>>>>> throughout the chapter. I think we only need to define <foo> string >>>>>>> in >>>>>>> 14.3.3 and then state for the 6 parameters so far that those are >>>>>>>foo >>>>>>> strings. >>>>>> >>>>>> Okay, I'll work on it and try to integrate it cleanly. >>>>>>> >>>>>>> By and large <foo> strings are just like other C string. We just >>>>>>>have >>>>>>> additional requirements to what "identical" means. That is why I >>>>>>>came >>>>>>> up >>>>>>> with the name: "quasi-identical", because they are not identical in >>>>>>> the >>>>>>> normal C string sense (str*cmp). As "quasi-identical" is a new kind >>>>>>> of >>>>>>> string, that probably no-one heard in a different context, so has >>>>>>>no >>>>>>> preoccupation on what it could mean, a reader should go: "What's >>>>>>> that?" >>>>>>> and refer to Section 14.3.3. >>>>>>> >>>>>>> What's the groups take on the name "quasi-identical"? >>>>>> >>>>>> I'm not totally sold on 'quasi-identical' but possibly because I >>>>>>don't >>>>>> use >>>>>> the prefix 'quasi' very often. Also, I almost think that it takes >>>>>>away >>>>>> from the fact that the internal representation of the strings does >>>>>> need to >>>>>> be identical, but what is passed to the user may be different due to >>>>>> truncation. >>>>> >>>>> Yes, the "quasi" might be a German thing, although I think is also >>>>> exists in English. I am open to any other suggestion. >>>>> >>>>> For the the quasi just expresses their actual state, we regard them >>>>>as >>>>> identical, although the actual strings returned do not have to the >>>>> identical in the strcmp sense (due to different length). So they are >>>>> identical and at the same time they are not. That is a little "quasi" >>>>> to >>>>> me ;-) >>>>> >>>>> What about: >>>>> >>>>> prospect-identical? >>>>> source-identical? >>>>> >>>>>> That said, I don't have a replacement suggestion right this second. >>>>> >>>>>>> Should we have an "out-of-order" telco tomorrow to discuss this? As >>>>>>> we >>>>>>> need to finalize our wording by Monday in order for 383 to be an >>>>>>> errata, >>>>>>> I think we need to make progress before the weekend. >>>>>> >>>>>> I'm not sure if that will work with everyone at SC. It would >>>>>>coincide >>>>>> with >>>>>> the 10:00 AM technical papers sessions. I suppose though if people >>>>>> pipe up >>>>>> that they would be able to join, that would be good and I would be >>>>>> able to >>>>>> be on the call. Of course, as you say in your post script, we could >>>>>> pick >>>>>> another time, too. >>>>> >>>>> Obviously, I am fine with any earlier time slot, but that would not >>>>>go >>>>> well with pacific time. I would have more again after 8 pm CET. Maybe >>>>> the people at SC suggest a time that fits into the program for them? >>>>> >>>>> Cheers, >>>>> Marc-Andre >>>>> >>>>> -- >>>>> 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 >>>>> >>> >>> >>> _______________________________________________ >>> 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

WebEx meeting invitation: MPI Tools WG
by Kathryn M. Mohror 20 Nov '14

20 Nov '14

Hello, Kathryn M. Mohror invites you to join this WebEx meeting. MPI Tools WG Thursday, November 20, 2014 8:00 am | Pacific Standard Time (San Francisco, GMT-08:00) | 1 hr JOIN WEBEX MEETING https://llnl.webex.com/llnl/j.php?MTID=m3200fda7658073f4a14293afe5393eee Meeting number: 802 496 211 Meeting password: meetme JOIN BY PHONE +1-415-655-0001 US TOLL Access code: 802 496 211 Add this meeting to your calendar: https://llnl.webex.com/llnl/j.php?MTID=mdeacdb74d03ec27179910a9f5600cc81 Can't join the meeting? Contact support here: https://llnl.webex.com/llnl/mc IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session.

1 0