[mpiwg-tools] proposed text

Kathryn Mohror kathryn at llnl.gov
Thu Nov 20 13:58:37 CST 2014

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
- 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 Mohror, kathryn at llnl.gov, http://scalability.llnl.gov/
Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA,

On 11/20/14, 6:00 AM, "Marc-Andre Hermanns" <m.a.hermanns at grs-sim.de>

>Hi Kathryn,
>you used the <foo>=MPI_T version right?
>What do you think about this:
>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.
>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?
>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 at llnl.gov, http://scalability.llnl.gov/
>> Scalability Team @ Lawrence Livermore National Laboratory, Livermore,
>> USA
>> On 11/19/14, 12:17 PM, "Kathryn Mohror" <kathryn at llnl.gov> wrote:
>>> Thanks Bronis. I like the suggestion of equivalence instead of
>>> 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
>>>>>>> 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
>>>>>>> additional requirements to what "identical" means. That is why I
>>>>>>> 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
>>>>>>> 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
>>>>>> use
>>>>>> the prefix 'quasi' very often. Also, I almost think that it takes
>>>>>> 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
>>>>> 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
>>>>>> 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
>>>>> 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 at grs-sim.de
>>> _______________________________________________
>>> mpiwg-tools mailing list
>>> mpiwg-tools at lists.mpi-forum.org
>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
>> _______________________________________________
>> mpiwg-tools mailing list
>> mpiwg-tools at 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
>Phone: +49 241 80 99753
>Fax: +49 241 80 6 99753
>email: m.a.hermanns at grs-sim.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tools-3.pdf
Type: application/pdf
Size: 328077 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20141120/193c1f8e/attachment-0001.pdf>

More information about the mpiwg-tools mailing list