[mpiwg-tools] proposed text

Sat Nov 22 07:45:48 CST 2014

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 at 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 at 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 at 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 at 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 at 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 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
> 
> <tools-3.pdf>_______________________________________________
> mpiwg-tools mailing list
> mpiwg-tools at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/