[mpiwg-tools] proposed text

Jeff Squyres (jsquyres) jsquyres at cisco.com
Sun Nov 23 05:45:43 CST 2014 

+1

On Nov 22, 2014, at 9:32 PM, Kathryn Mohror <kathryn at llnl.gov> wrote:

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

More information about the mpiwg-tools mailing list