[mpiwg-tools] proposed text

Kathryn Mohror kathryn at llnl.gov
Sat Nov 22 20:32:07 CST 2014 

Uploading the current text in this email.

Comment away!

Kathryn
_________________________________________________________________
Kathryn Mohror, kathryn at llnl.gov, http://scalability.llnl.gov/
Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA,
USA






On 11/22/14, 4:08 PM, "Jeff Squyres (jsquyres)" <jsquyres at cisco.com> wrote:

>Forgot to say: it is not necessary to say that n can be different in
>different processes. That is up to the specification of params for each
>function.  We're only defining equivalent strings here.
>
>Sent from my phone. No type good.
>
>> On Nov 22, 2014, at 5:04 PM, Kathryn Mohror <kathryn at llnl.gov> wrote:
>> 
>> Hi Jeff, 
>> 
>> Thanks for the feedback!
>> 
>> I made all the changes and agree with them for the most part (new
>>document
>> attached). Comments inlined:
>> 
>> 
>>> 
>>> p9:40-p10:1 reads:
>>> 
>>> 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.
>> 
>> "due to a small n length parameter." For some reason the word "small"
>> seems odd to me here. Do we want it to be more formal, and specify that
>> it's the input value of n that causes the truncation and that n could be
>> different on different processes?
>> 
>>> 
>>> Nit picks
>>> =========
>>> 
>>> 1. p7:23-26 reads:
>>> 
>>> 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).
>> 
>> I'm assuming you didn't mean the *** literally but to draw attention to
>> the change. Also, I'm not sure if Bronis will chime in to correct our
>> punctuation here, but I believe because the parenthetical text forms a
>> complete sentence we would need to treat it as such, i.e. With proper
>> capitalization and punctuation. However, I don't know for sure, so if
>> someone does, please speak up!
>> 
>> Thanks for the rest of your comments and the example of why we don't
>>want
>> to include enumerations.
>> 
>> Kathryn
>> 
>>> 
>>> 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/
>>> 
>>> _______________________________________________
>>> 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
>_______________________________________________
>mpiwg-tools mailing list
>mpiwg-tools at lists.mpi-forum.org
>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

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

More information about the mpiwg-tools mailing list