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

Call today
by Marc-Andre Hermanns 20 Nov '14

20 Nov '14

Hi Kathryn, as I think everyone is busy at SC and no-one replied I guess an "official" call will not really happen today, right? :( Also the existing WebEx is for next week, and I don't know whether Jeff could set something up for us on short notice. I'd expect he's busy with the exhibition and technical program as well. Shall the two of us discuss the text via some other platform to keep things moving (Skype, ...)? 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 20 Nov '14

20 Nov '14

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

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

20 Nov '14

Hi Bronis, thanks for the input on this. I also like the "equivalency" better than my earlier suggestions. Cheers, Marc-Andre On 19.11.14 21:02, Bronis R. de Supinski wrote: > > "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 > -- 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 19 Nov '14

19 Nov '14

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

1 0

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

19 Nov '14

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 >>

1 0

Re: [mpiwg-tools] proposed text
by Bronis R. de Supinski 19 Nov '14

19 Nov '14

"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 > >

1 0

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

19 Nov '14

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

1 0

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

19 Nov '14

Hi Marc-Andre, > >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. 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. Kathryn > >Cheers, >Marc-Andre > >PS: I know (almost) everyone is at SC, but maybe we can find a time for >a call. > >On 18.11.14 22:03, Kathryn Mohror wrote: >> I see what you mean, and that helps. >> >> Do you think then, that all instances of the word "string" in this >>chapter >> (or the tools information interface part of the chapter anyway) need to >>be >> changed to "<foo> string"? >> >> Or can we just say that we refer to them as <foo> strings wherever >> confusion might arise? (That seems a bit dangerous, I think, because who >> knows where confusion could arise for a particular reader?) >> >> Kathryn >> _________________________________________________________________ >> Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ >> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, >>CA, >> USA >> >> >> >> >> >> >> On 11/18/14, 12:41 PM, "Marc-Andre Hermanns" <m.a.hermanns(a)grs-sim.de> >> wrote: >> >>> 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 >>> >> >> >> _______________________________________________ >> 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 Marc-Andre Hermanns 19 Nov '14

19 Nov '14

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. 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"? 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. Cheers, Marc-Andre PS: I know (almost) everyone is at SC, but maybe we can find a time for a call. On 18.11.14 22:03, Kathryn Mohror wrote: > I see what you mean, and that helps. > > Do you think then, that all instances of the word "string" in this chapter > (or the tools information interface part of the chapter anyway) need to be > changed to "<foo> string"? > > Or can we just say that we refer to them as <foo> strings wherever > confusion might arise? (That seems a bit dangerous, I think, because who > knows where confusion could arise for a particular reader?) > > Kathryn > _________________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ > Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, > USA > > > > > > > On 11/18/14, 12:41 PM, "Marc-Andre Hermanns" <m.a.hermanns(a)grs-sim.de> > wrote: > >> 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 >> > > > _______________________________________________ > 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 see what you mean, and that helps. Do you think then, that all instances of the word "string" in this chapter (or the tools information interface part of the chapter anyway) need to be changed to "<foo> string"? Or can we just say that we refer to them as <foo> strings wherever confusion might arise? (That seems a bit dangerous, I think, because who knows where confusion could arise for a particular reader?) Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA On 11/18/14, 12:41 PM, "Marc-Andre Hermanns" <m.a.hermanns(a)grs-sim.de> wrote: >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