<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="PostalCode"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="Street"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="City"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="address"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="country-region"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="State"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="PlaceType"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="PlaceName"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="place"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
p.MsoBodyText, li.MsoBodyText, div.MsoBodyText
{margin-top:0pt;
margin-right:0pt;
margin-bottom:6.0pt;
margin-left:0pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:blue;
text-decoration:underline;}
p
{mso-margin-top-alt:auto;
margin-right:0pt;
mso-margin-bottom-alt:auto;
margin-left:0pt;
font-size:12.0pt;
font-family:"Times New Roman";}
tt
{font-family:"Courier New";}
p.Code, li.Code, div.Code
{margin:0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Courier New";
color:black;}
p.code0, li.code0, div.code0
{margin:0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Courier New";
color:black;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:Verdana;
color:blue;
font-weight:normal;
font-style:normal;
text-decoration:none none;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=blue>
<div class=Section1>
<p class=MsoNormal><font size=2 color=blue face=Verdana><span style='font-size:
10.0pt;font-family:Verdana;color:blue'>As you are saying, there are two
different classes of errors here.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Verdana><span style='font-size:
10.0pt;font-family:Verdana;color:blue'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Verdana><span style='font-size:
10.0pt;font-family:Verdana;color:blue'>1) Keys which are not understood and
need to be ignored by functions which don’t grok them (“JIMS_SECRET_TAG”,”99”)<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Verdana><span style='font-size:
10.0pt;font-family:Verdana;color:blue'>2) Keys which are understood by a
function, but with a value which is not (“buffer_size”, “Hello”)<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Verdana><span style='font-size:
10.0pt;font-family:Verdana;color:blue'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Verdana><span style='font-size:
10.0pt;font-family:Verdana;color:blue'>I think allowing the second type to have
undefined behavior is the right thing to do, since it’s the most general.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Verdana><span style='font-size:
10.0pt;font-family:Verdana;color:blue'>If your implementation wants to define the
behavior of some out-of-range values, that’s fine and doesn’t make
you non-conforming, it just means you defined the previously undefined behavior
for some set of values.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Verdana><span style='font-size:
10.0pt;font-family:Verdana;color:blue'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Verdana><span style='font-size:
10.0pt;font-family:Verdana;color:blue'>Having that undefined-ness explicit here
(in one central place) seems to make sense (if only because it may be omitted
in one of the other places where it should appear).<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Verdana><span style='font-size:
10.0pt;font-family:Verdana;color:blue'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=blue face=Verdana><span style='font-size:
10.0pt;font-family:Verdana;color:blue'>My addition does not alter the existing
change which guarantees case 1, it’s only concerned with case 2.<o:p></o:p></span></font></p>
<div>
<p style='margin-bottom:12.0pt'><font size=2 color=blue face=Verdana><span
style='font-size:10.0pt;font-family:Verdana;color:blue'>-- Jim<br>
<br>
James Cownie <james.h.cownie@intel.com><br>
SSG/DPD/PAT<br>
Tel: +44 117 9071438</span></font><o:p></o:p></p>
</div>
<div style='border:none;border-left:solid blue 1.5pt;padding:0pt 0pt 0pt 4.0pt'>
<div>
<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>
<hr size=2 width="100%" align=center tabindex=-1>
</span></font></div>
<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'>
mpi-21-bounces@cs.uiuc.edu [mailto:mpi-21-bounces@cs.uiuc.edu] <b><span
style='font-weight:bold'>On Behalf Of </span></b>Richard Treumann<br>
<b><span style='font-weight:bold'>Sent:</span></b> 31 January 2008 14:20<br>
<b><span style='font-weight:bold'>To:</span></b> <st1:PersonName w:st="on">Mailing
list for discussion of MPI 2.1</st1:PersonName><br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [mpi-21] Ballot 4 -
Re: Request for interpretation</span></font><o:p></o:p></p>
</div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
<p><font size=3 face="Times New Roman"><span style='font-size:12.0pt'>Jim -<br>
<br>
I was taking the view that the description of what to do for a recognized key
but dubious value belongs to the function that recognizes the specific key. For
example if MPI_File_open accepts a "buffer_size" hint with range
"32K" to "16M" we may want to define the behavior of hints
that are out of range.<br>
<br>
Once we say an info can have arbitrary keys we need to state that every info
consumer must be prepared to ignore keys it does not recognize because we have
made unrecognizable keys legitimate.<br>
<br>
Dick <br>
Dick Treumann - MPI Team/TCEM <br>
IBM Systems & Technology Group<br>
<st1:address w:st="on"><st1:Street w:st="on">Dept</st1:Street> 0lva</st1:address>
/ MS P963 -- <st1:Street w:st="on"><st1:address w:st="on">2455 South Road</st1:address></st1:Street>
-- <st1:place w:st="on"><st1:City w:st="on">Poughkeepsie</st1:City>, <st1:State
w:st="on">NY</st1:State> <st1:PostalCode w:st="on">12601</st1:PostalCode></st1:place><br>
Tele (845) 433-7846 Fax (845) 433-8363<br>
<br>
<br>
</span></font><tt><font size=2 face="Courier New"><span style='font-size:10.0pt'>mpi-21-bounces@cs.uiuc.edu
wrote on 01/31/2008 08:43:04 AM:</span></font></tt><font size=2
face="Courier New"><span style='font-size:10.0pt;font-family:"Courier New"'><br>
<br>
<tt><font face="Courier New">> However, you have apparently lost the liberty
to have undefined </font></tt><br>
<tt><font face="Courier New">> behavior which was there in the previous
version.</font></tt></span></font><br>
<tt><font size=2 face="Courier New"><span style='font-size:10.0pt'>> </span></font></tt><br>
<tt><font size=2 face="Courier New"><span style='font-size:10.0pt'>> Maybe
you should keep that, something like </span></font></tt><br>
<tt><font size=2 face="Courier New"><span style='font-size:10.0pt'>> An
implementation must support info objects as caches for arbitrary </span></font></tt><font
size=2 face="Courier New"><span style='font-size:10.0pt;font-family:"Courier New"'><br>
<tt><font face="Courier New">> (key, value) pairs, regardless of whether it
recognizes the keys. </font></tt><br>
<tt><font face="Courier New">> Each MPI function which takes hints in the
form of an MPI_Info must</font></tt><br>
<tt><font face="Courier New">> be prepared to ignore any key it does not
recognize. However if a </font></tt><br>
<tt><font face="Courier New">> function recognizes a key but not the
associated value, then the </font></tt><br>
<tt><font face="Courier New">> behavior is undefined.</font></tt></span></font><br>
<tt><font size=2 face="Courier New"><span style='font-size:10.0pt'>>
(Modifications in italics)</span></font></tt><br>
<tt><font size=2 face="Courier New"><span style='font-size:10.0pt'>> -- Jim</span></font></tt><font
size=2 face="Courier New"><span style='font-size:10.0pt;font-family:"Courier New"'><br>
<tt><font face="Courier New">> </font></tt><br>
<tt><font face="Courier New">> James Cownie <james.h.cownie@intel.com></font></tt><br>
<tt><font face="Courier New">> SSG/DPD/PAT</font></tt><br>
<tt><font face="Courier New">> Tel: +44 117 9071438</font></tt></span></font><br>
<tt><font size=2 face="Courier New"><span style='font-size:10.0pt'>> </span></font></tt><font
size=2 face="Courier New"><span style='font-size:10.0pt;font-family:"Courier New"'><br>
<tt><font face="Courier New">> From: mpi-21-bounces@cs.uiuc.edu [<a
href="mailto:mpi-21-bounces@cs.uiuc.edu">mailto:mpi-21-bounces@cs.uiuc.edu</a>]
</font></tt><br>
<tt><font face="Courier New">> On Behalf Of Richard Treumann</font></tt><br>
<tt><font face="Courier New">> Sent: 31 January 2008 13:29</font></tt><br>
<tt><font face="Courier New">> To: <st1:PersonName w:st="on">Mailing list
for discussion of MPI 2.1</st1:PersonName></font></tt><br>
<tt><font face="Courier New">> Subject: Re: [mpi-21] Ballot 4 - Re: Request
for interpretation</font></tt></span></font><br>
<tt><font size=2 face="Courier New"><span style='font-size:10.0pt'>> </span></font></tt><br>
<tt><font size=2 face="Courier New"><span style='font-size:10.0pt'>> Your
wording works for me Rolf. -- Thanks</span></font></tt><font size=2
face="Courier New"><span style='font-size:10.0pt;font-family:"Courier New"'><br>
<tt><font face="Courier New">> </font></tt><br>
<tt><font face="Courier New">> </font></tt><br>
<tt><font face="Courier New">> Dick Treumann - MPI Team/TCEM </font></tt><br>
<tt><font face="Courier New">> IBM Systems & Technology Group</font></tt><br>
<tt><font face="Courier New">> Dept 0lva / MS P963 -- <st1:Street w:st="on"><st1:address
w:st="on">2455 South Road</st1:address></st1:Street> -- <st1:place w:st="on"><st1:City
w:st="on">Poughkeepsie</st1:City>, <st1:State w:st="on">NY</st1:State> <st1:PostalCode
w:st="on">12601</st1:PostalCode></st1:place></font></tt><br>
<tt><font face="Courier New">> Tele (845) 433-7846 Fax (845) 433-8363</font></tt><br>
<tt><font face="Courier New">> </font></tt><br>
<tt><font face="Courier New">> </font></tt><br>
<tt><font face="Courier New">> mpi-21-bounces@cs.uiuc.edu wrote on
01/31/2008 05:25:46 AM:</font></tt><br>
<tt><font face="Courier New">> </font></tt><br>
<tt><font face="Courier New">> > I try to summarize all 3 replies in one
proposal:</font></tt><br>
<tt><font face="Courier New">> > </font></tt><br>
<tt><font face="Courier New">> > ___________________________________</font></tt><br>
<tt><font face="Courier New">> > </font></tt><br>
<tt><font face="Courier New">> > Proposal:</font></tt><br>
<tt><font face="Courier New">> > MPI 2.0, Sect. 4.10 Info Objects, page
43, line 38-40 read:</font></tt><br>
<tt><font face="Courier New">> > If a function does not
recognize a key, </font></tt><br>
<tt><font face="Courier New">> > it will ignore it, unless
otherwise specified.</font></tt><br>
<tt><font face="Courier New">> > If an implementation
recognizes a key but does not recognize </font></tt><br>
<tt><font face="Courier New">> > the format of the
corresponding value, the result is undefined.</font></tt><br>
<tt><font face="Courier New">> > but should read:</font></tt><br>
<tt><font face="Courier New">> > An implementation must support
info objects as caches for arbitrary</font></tt><br>
<tt><font face="Courier New">> > (key, value) pairs,
regardless of whether it recognizes the pairs.</font></tt><br>
<tt><font face="Courier New">> > Each MPI function which
takes hints in the form of an MPI_Info must</font></tt><br>
<tt><font face="Courier New">> > be prepared to ignore any
key it does not recognize.</font></tt><br>
<tt><font face="Courier New">> > </font></tt><br>
<tt><font face="Courier New">> > Add after MPI 2.0, Sect. 4.10 Info
Objects, page 44, line 22 a new</font></tt><br>
<tt><font face="Courier New">> > paragraph:</font></tt><br>
<tt><font face="Courier New">> > Advice to implementors.</font></tt><br>
<tt><font face="Courier New">> > Although in MPI functions
that take hints in form of an MPI_Info</font></tt><br>
<tt><font face="Courier New">> > (e.g., in process creation
and management, one-sided communication, </font></tt><br>
<tt><font face="Courier New">> > or parallel file I/O), an
implementation must be prepared to ignore </font></tt><br>
<tt><font face="Courier New">> > keys that it does not
recognize, for the purpose of MPI_INFO_GET_NKEYS, </font></tt><br>
<tt><font face="Courier New">> > MPI_INFO_GET_NTHKEY,
MPI_INFO_GET_VALUELEN, and MPI_INFO_GET, the </font></tt><br>
<tt><font face="Courier New">> > implementation must retain
all (key,value) pairs so that layered </font></tt><br>
<tt><font face="Courier New">> > functionality can also use
the Info object.</font></tt><br>
<tt><font face="Courier New">> > (End of advice to
implementors.)</font></tt><br>
<tt><font face="Courier New">> > _____________________________</font></tt><br>
<tt><font face="Courier New">> > Rationale for this clarification:</font></tt><br>
<tt><font face="Courier New">> > </font></tt><br>
<tt><font face="Courier New">> > The MPI-2.0 text allowed
that also MPI_INFO_DELETE, MPI_INFO_SET,</font></tt><br>
<tt><font face="Courier New">> > MPI_INFO_GET, and
MPI_INFO_DUP could ignore (key,value) pairs</font></tt><br>
<tt><font face="Courier New">> > that are not recognized in
routines in other chapters that</font></tt><br>
<tt><font face="Courier New">> > take hints with info
arguments.</font></tt><br>
<tt><font face="Courier New">> > The proposed clarification
is necessary when we assume, that </font></tt><br>
<tt><font face="Courier New">> > layered implementation of
parts of the MPI-2 standard should </font></tt><br>
<tt><font face="Courier New">> > be possible and may use the
MPI_Info objects for their needs.</font></tt><br>
<tt><font face="Courier New">> > This was a goal of the
MPI-2 Forum and the MPI-2.0 specification.</font></tt><br>
<tt><font face="Courier New">> > ___________________________________</font></tt><br>
<tt><font face="Courier New">> > </font></tt><br>
<tt><font face="Courier New">> > Bronis, for me, your wording "an
MPI implementation may restrict" was</font></tt><br>
<tt><font face="Courier New">> > in conflict with the rest of the advice.
I hope the formulation above</font></tt><br>
<tt><font face="Courier New">> > is also okay. It is based on the new
wording from you and Dick in first </font></tt><br>
<tt><font face="Courier New">> > part of the proposal.</font></tt><br>
<tt><font face="Courier New">> > </font></tt><br>
<tt><font face="Courier New">> > Best regards</font></tt><br>
<tt><font face="Courier New">> > Rolf</font></tt><br>
<tt><font face="Courier New">> > </font></tt><br>
<tt><font face="Courier New">> > </font></tt><br>
<tt><font face="Courier New">> > Dr. Rolf Rabenseifner . . . . . . . . .
.. email rabenseifner@hlrs.de</font></tt><br>
<tt><font face="Courier New">> > High Performance Computing Center (HLRS)
. phone ++49(0)711/685-65530</font></tt><br>
<tt><font face="Courier New">> > <st1:place w:st="on"><st1:PlaceType
w:st="on">University</st1:PlaceType> of <st1:PlaceName w:st="on">Stuttgart</st1:PlaceName></st1:place>
. . . . . . . . .. fax ++49(0)711 / 685-65832</font></tt><br>
<tt><font face="Courier New">> > Head of Dpmt Parallel Computing . . .
www.hlrs.de/people/rabenseifner</font></tt><br>
<tt><font face="Courier New">> > Nobelstr. 19, D-70550 <st1:place w:st="on"><st1:City
w:st="on">Stuttgart</st1:City>, <st1:country-region w:st="on">Germany</st1:country-region></st1:place>
. (Office: Allmandring 30)</font></tt><br>
<tt><font face="Courier New">> >
_______________________________________________</font></tt><br>
<tt><font face="Courier New">> > mpi-21 mailing list</font></tt><br>
<tt><font face="Courier New">> > mpi-21@cs.uiuc.edu</font></tt><br>
<tt><font face="Courier New">> > <a
href="http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21">http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21</a></font></tt></span></font><br>
<tt><font size=2 face="Courier New"><span style='font-size:10.0pt'>>
---------------------------------------------------------------------</span></font></tt><font
size=2 face="Courier New"><span style='font-size:10.0pt;font-family:"Courier New"'><br>
<tt><font face="Courier New">> Intel Corporation (<st1:country-region w:st="on"><st1:place
w:st="on">UK</st1:place></st1:country-region>) Limited</font></tt><br>
<tt><font face="Courier New">> Registered No. 1134945 (<st1:country-region
w:st="on"><st1:place w:st="on">England</st1:place></st1:country-region>)</font></tt><br>
<tt><font face="Courier New">> Registered Office: <st1:address w:st="on"><st1:Street
w:st="on">Pipers Way</st1:Street>, <st1:City w:st="on">Swindon</st1:City> <st1:PostalCode
w:st="on">SN3 1RJ</st1:PostalCode></st1:address></font></tt><br>
<tt><font face="Courier New">> VAT No: 860 2173 47</font></tt><br>
<tt><font face="Courier New">> </font></tt><br>
<tt><font face="Courier New">> This e-mail and any attachments may contain
confidential material for</font></tt><br>
<tt><font face="Courier New">> the sole use of the intended recipient(s).
Any review or distribution</font></tt><br>
<tt><font face="Courier New">> by others is strictly prohibited. If you are
not the intended</font></tt><br>
<tt><font face="Courier New">> recipient, please contact the sender and
delete all copies.</font></tt><br>
<tt><font face="Courier New">>
_______________________________________________</font></tt><br>
<tt><font face="Courier New">> mpi-21 mailing list</font></tt><br>
<tt><font face="Courier New">> mpi-21@cs.uiuc.edu</font></tt><br>
<tt><font face="Courier New">> <a
href="http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21">http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21</a></font></tt></span></font><o:p></o:p></p>
</div>
</div>
<pre>---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
</pre></body>
</html>