[mpiwg-tools] proposed text

Fri Nov 21 03:56:49 CST 2014

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

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