[mpiwg-tools] proposed text

Sat Nov 22 18:08:17 CST 2014

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