November 2014 - mpiwg-tools - mailman3.cels.anl.gov

Re: [mpiwg-tools] No call tomorrow
by Schulz Martin 26 Nov '14

26 Nov '14

I¹ll be traveling up to the MPI forum and won¹t have a chance to call-in. I think at this point, it¹s the best to discuss this at the forum (in the WG) and then present a summary of (what is really only a rough draft of a proposal) to the group in a TelCon afterwards. Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ CASC @ Lawrence Livermore National Laboratory, Livermore, USA On 11/26/14, 12:33 PM, "Marc-Andre Hermanns" <m.a.hermanns(a)grs-sim.de> wrote: >Dear all, > >Kathryn told me that tomorrow is a public holiday in the US, so we'll >skip the meeting tomorrow. > >As the December meeting is in two weeks, should we have another call >before that (i.e., next week)? I think we are fine on the tickets, but >what about the dormant but scheduled PMPI-2 proposal? Is there a need to >discuss this before the meeting? > >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(a)grs-sim.de >

1 0

No call tomorrow
by Marc-Andre Hermanns 26 Nov '14

26 Nov '14

Dear all, Kathryn told me that tomorrow is a public holiday in the US, so we'll skip the meeting tomorrow. As the December meeting is in two weeks, should we have another call before that (i.e., next week)? I think we are fine on the tickets, but what about the dormant but scheduled PMPI-2 proposal? Is there a need to discuss this before the meeting? 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(a)grs-sim.de

1 0

Re: [mpiwg-tools] proposed text
by Kathryn Mohror 24 Nov '14

24 Nov '14

Thanks to everyone who helped craft the text for #383. Let's hope that this is the final iteration! I announced the ticket to the Forum mailing list. We have until 2pm PST to make changes, so speak up now if you see something that is incorrect. Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA On 11/24/14, 5:27 AM, "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> wrote: >I'm out on vacation this week and can't easily join a Webex or >participate deeply. So if you're convinced that you can make the enum var >*names* be equivalent and not its *values*, then I'll be happy. > >Regardless, I think you all understand my example/concern, so if it's not >an issue, great. :) > >I'll leave it to you folks to figure out. > >Sent from my phone. No type good. > >> On Nov 24, 2014, at 6:33 AM, Michael Knobloch >><m.knobloch(a)fz-juelich.de> wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi all, >> >> here I have to disagree with Jeff - only the important part highlighted: >> >>> On 11/22/2014 02:45 PM, Jeff Squyres (jsquyres) wrote: >>> >>> 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". >> >> No one wants enumerated values to be equivalent - just the names of >> enum items iff the corresponding enums are equivalent - and I think >> that was clear from the text Kathryn sent around. So if I understand >> your example correctly we have on both processes an enum >> "network_info" with variable name "network_address" with the value >> "A.B.C.D" on process A and "W.X.Y.Z" on process B. And I think this is >> covered by our definition of having semantically the same behavior. >> >> Am I'm missing a point here? >> >> - -Michael >> - -- >> 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(a)fz-juelich.de >> Internet: http://www.fz-juelich.de/jsc >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1 >> >> iQIcBAEBAgAGBQJUcxdkAAoJENAucJeJjnBJ0OsP/0mr1o1W4Jjmr98SJ43g9i2M >> IEd6zHMf8cceS0UA9pitmg/fdMXLTGsI/HH6WIAZuznPP4cINqNPB+i2EVYKJLOn >> saqPKwjQINQzoJZCxrNtFh7nntJlol5JCnqXt6DH1WtHy0Z3qR6B8YTDGUgPSCpN >> Z6D///9e00WAC2EcY6djQCmRra0cGmdfz5ui9WmwUcNnzZGEynKT97pqvgcfFBhQ >> RtdsbbO3zpWPBS8pHtQyf/Lz117eVAhqCgoIsehwiLBXJvbP7XNpmjCRBJM6miMJ >> 0nfvLBMlZ80HRq5dBi20XwqQNEDkYSyD15XNvDNAVq6yvXksMUxqenwnbSgj2puA >> Ti+RU3SmndkHo4hLhO6RiEHSbn0w5Bdckmvbj1IqqAelkIB/NH2X+yCsNNv7aCvB >> jxYcnPdWa4sw+QfbEkjP1eqhvYeEWKMuwvrVOr1Ns4C/S95WiwiMCXw4f5dmUn5q >> u6+PjZRuJVLMc0u1PBx0UmWO5Kmt0xu3C9D4X/1g5BhP2gBvydk0y7IvqeJYqQxh >> 5+bzy0Vjzr6Ly/pp+pjP51xPeZq2q1GlzAp1l4gFnqi6zSpQDrMpnuZSxM/KuBLS >> P3BisCJDBP4woy4nNCnRZZnPsWjhqwDpdb73RQ2tSaOK1bXt0oJRZkyJJkGc9CWR >> R58VxGZvH9B2ppqBEUGj >> =WPBk >> -----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 >> >>------------------------------------------------------------------------- >>----------------------- >> >>------------------------------------------------------------------------- >>----------------------- >> >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >_______________________________________________ >mpiwg-tools mailing list >mpiwg-tools(a)lists.mpi-forum.org >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0

Re: [mpiwg-tools] proposed text
by Jeff Squyres (jsquyres) 24 Nov '14

24 Nov '14

I'm out on vacation this week and can't easily join a Webex or participate deeply. So if you're convinced that you can make the enum var *names* be equivalent and not its *values*, then I'll be happy. Regardless, I think you all understand my example/concern, so if it's not an issue, great. :) I'll leave it to you folks to figure out. Sent from my phone. No type good. > On Nov 24, 2014, at 6:33 AM, Michael Knobloch <m.knobloch(a)fz-juelich.de> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, > > here I have to disagree with Jeff - only the important part highlighted: > >> On 11/22/2014 02:45 PM, Jeff Squyres (jsquyres) wrote: >> >> 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". > > No one wants enumerated values to be equivalent - just the names of > enum items iff the corresponding enums are equivalent - and I think > that was clear from the text Kathryn sent around. So if I understand > your example correctly we have on both processes an enum > "network_info" with variable name "network_address" with the value > "A.B.C.D" on process A and "W.X.Y.Z" on process B. And I think this is > covered by our definition of having semantically the same behavior. > > Am I'm missing a point here? > > - -Michael > - -- > 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(a)fz-juelich.de > Internet: http://www.fz-juelich.de/jsc > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQIcBAEBAgAGBQJUcxdkAAoJENAucJeJjnBJ0OsP/0mr1o1W4Jjmr98SJ43g9i2M > IEd6zHMf8cceS0UA9pitmg/fdMXLTGsI/HH6WIAZuznPP4cINqNPB+i2EVYKJLOn > saqPKwjQINQzoJZCxrNtFh7nntJlol5JCnqXt6DH1WtHy0Z3qR6B8YTDGUgPSCpN > Z6D///9e00WAC2EcY6djQCmRra0cGmdfz5ui9WmwUcNnzZGEynKT97pqvgcfFBhQ > RtdsbbO3zpWPBS8pHtQyf/Lz117eVAhqCgoIsehwiLBXJvbP7XNpmjCRBJM6miMJ > 0nfvLBMlZ80HRq5dBi20XwqQNEDkYSyD15XNvDNAVq6yvXksMUxqenwnbSgj2puA > Ti+RU3SmndkHo4hLhO6RiEHSbn0w5Bdckmvbj1IqqAelkIB/NH2X+yCsNNv7aCvB > jxYcnPdWa4sw+QfbEkjP1eqhvYeEWKMuwvrVOr1Ns4C/S95WiwiMCXw4f5dmUn5q > u6+PjZRuJVLMc0u1PBx0UmWO5Kmt0xu3C9D4X/1g5BhP2gBvydk0y7IvqeJYqQxh > 5+bzy0Vjzr6Ly/pp+pjP51xPeZq2q1GlzAp1l4gFnqi6zSpQDrMpnuZSxM/KuBLS > P3BisCJDBP4woy4nNCnRZZnPsWjhqwDpdb73RQ2tSaOK1bXt0oJRZkyJJkGc9CWR > R58VxGZvH9B2ppqBEUGj > =WPBk > -----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 > ------------------------------------------------------------------------------------------------ > ------------------------------------------------------------------------------------------------ > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0

Re: [mpiwg-tools] proposed text
by Michael Knobloch 24 Nov '14

24 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, here I have to disagree with Jeff - only the important part highlighted: On 11/22/2014 02:45 PM, Jeff Squyres (jsquyres) wrote: > > 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". > No one wants enumerated values to be equivalent - just the names of enum items iff the corresponding enums are equivalent - and I think that was clear from the text Kathryn sent around. So if I understand your example correctly we have on both processes an enum "network_info" with variable name "network_address" with the value "A.B.C.D" on process A and "W.X.Y.Z" on process B. And I think this is covered by our definition of having semantically the same behavior. Am I'm missing a point here? - -Michael - -- 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(a)fz-juelich.de Internet: http://www.fz-juelich.de/jsc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUcxdkAAoJENAucJeJjnBJ0OsP/0mr1o1W4Jjmr98SJ43g9i2M IEd6zHMf8cceS0UA9pitmg/fdMXLTGsI/HH6WIAZuznPP4cINqNPB+i2EVYKJLOn saqPKwjQINQzoJZCxrNtFh7nntJlol5JCnqXt6DH1WtHy0Z3qR6B8YTDGUgPSCpN Z6D///9e00WAC2EcY6djQCmRra0cGmdfz5ui9WmwUcNnzZGEynKT97pqvgcfFBhQ RtdsbbO3zpWPBS8pHtQyf/Lz117eVAhqCgoIsehwiLBXJvbP7XNpmjCRBJM6miMJ 0nfvLBMlZ80HRq5dBi20XwqQNEDkYSyD15XNvDNAVq6yvXksMUxqenwnbSgj2puA Ti+RU3SmndkHo4hLhO6RiEHSbn0w5Bdckmvbj1IqqAelkIB/NH2X+yCsNNv7aCvB jxYcnPdWa4sw+QfbEkjP1eqhvYeEWKMuwvrVOr1Ns4C/S95WiwiMCXw4f5dmUn5q u6+PjZRuJVLMc0u1PBx0UmWO5Kmt0xu3C9D4X/1g5BhP2gBvydk0y7IvqeJYqQxh 5+bzy0Vjzr6Ly/pp+pjP51xPeZq2q1GlzAp1l4gFnqi6zSpQDrMpnuZSxM/KuBLS P3BisCJDBP4woy4nNCnRZZnPsWjhqwDpdb73RQ2tSaOK1bXt0oJRZkyJJkGc9CWR R58VxGZvH9B2ppqBEUGj =WPBk -----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 ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------

1 0

Re: [mpiwg-tools] proposed text
by Jeff Squyres (jsquyres) 23 Nov '14

23 Nov '14

+1 On Nov 22, 2014, at 9:32 PM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: > Uploading the current text in this email. > > Comment away! > > Kathryn > _________________________________________________________________ > Kathryn Mohror, kathryn(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)grs-sim.de >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mpiwg-tools mailing list >>>>>> mpiwg-tools(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >>>>> >>>>> <tools-3.pdf>_______________________________________________ >>>>> mpiwg-tools mailing list >>>>> mpiwg-tools(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >>>> >>>> >>>> -- >>>> Jeff Squyres >>>> jsquyres(a)cisco.com >>>> For corporate legal information go to: >>>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>>> >>>> _______________________________________________ >>>> mpiwg-tools mailing list >>>> mpiwg-tools(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >>> >>> <tools-3.pdf> >>> _______________________________________________ >>> mpiwg-tools mailing list >>> mpiwg-tools(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > <tools-3.pdf>_______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [mpiwg-tools] proposed text
by Kathryn Mohror 22 Nov '14

22 Nov '14

Uploading the current text in this email. Comment away! Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)grs-sim.de >>>>> >>>>> >>>>> _______________________________________________ >>>>> mpiwg-tools mailing list >>>>> mpiwg-tools(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >>>> >>>> <tools-3.pdf>_______________________________________________ >>>> mpiwg-tools mailing list >>>> mpiwg-tools(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >>> >>> >>> -- >>> Jeff Squyres >>> jsquyres(a)cisco.com >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>> >>> _______________________________________________ >>> mpiwg-tools mailing list >>> mpiwg-tools(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >> >> <tools-3.pdf> >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >_______________________________________________ >mpiwg-tools mailing list >mpiwg-tools(a)lists.mpi-forum.org >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0

Re: [mpiwg-tools] proposed text
by Jeff Squyres (jsquyres) 22 Nov '14

22 Nov '14

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(a)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(a)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(a)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(a)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(a)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(a)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(a)grs-sim.de >>>> >>>> >>>> _______________________________________________ >>>> mpiwg-tools mailing list >>>> mpiwg-tools(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >>> >>> <tools-3.pdf>_______________________________________________ >>> mpiwg-tools mailing list >>> mpiwg-tools(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >> >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > <tools-3.pdf> > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0

Re: [mpiwg-tools] proposed text
by Jeff Squyres (jsquyres) 22 Nov '14

22 Nov '14

I'm on phone which makes a full reply difficult. Generally agree with both your points. But let's change the 2nd one to make the parenthetical *not* a full sentence - a Capitol letter in a parenthetical is just weird. Perhaps just drop the "please"? Sent from my phone. No type good. > On Nov 22, 2014, at 5:04 PM, Kathryn Mohror <kathryn(a)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(a)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(a)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(a)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(a)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(a)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(a)grs-sim.de >>>> >>>> >>>> _______________________________________________ >>>> mpiwg-tools mailing list >>>> mpiwg-tools(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >>> >>> <tools-3.pdf>_______________________________________________ >>> mpiwg-tools mailing list >>> mpiwg-tools(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >> >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > <tools-3.pdf> > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0

Re: [mpiwg-tools] proposed text
by Kathryn Mohror 22 Nov '14

22 Nov '14

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(a)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(a)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(a)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(a)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(a)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(a)grs-sim.de >>>> >>> >>> >>> _______________________________________________ >>> mpiwg-tools mailing list >>> mpiwg-tools(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >> >> <tools-3.pdf>_______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > >-- >Jeff Squyres >jsquyres(a)cisco.com >For corporate legal information go to: >http://www.cisco.com/web/about/doing_business/legal/cri/ > >_______________________________________________ >mpiwg-tools mailing list >mpiwg-tools(a)lists.mpi-forum.org >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0