<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6000.16587" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=513062717-31012008><FONT face=Arial
color=#0000ff size=2>The intent is that if the user calls MPI_File_set_info (or
MPI_File_set_view) twice, the 2nd call will only update (if possible) the
key-vals passed in the 2nd call; others are unmodified. If the 2nd call passes
MPI_INFO_NULL, nothing will change -- it won't nullify previously passed
hints.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=513062717-31012008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=513062717-31012008><FONT face=Arial
color=#0000ff size=2>Rajeev</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=513062717-31012008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV><BR>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> mpi-21-bounces@cs.uiuc.edu
[mailto:mpi-21-bounces@cs.uiuc.edu] <B>On Behalf Of </B>Richard
Treumann<BR><B>Sent:</B> Thursday, January 31, 2008 9:23 AM<BR><B>To:</B>
Mailing list for discussion of MPI 2.1<BR><B>Subject:</B> Re: [mpi-21] Ballot
4 - MPI_File_set_info update or replacement<BR></FONT><BR></DIV>
<DIV></DIV>
<P>I think we have an overall ambiguity about what the "current set of hints"
is. This ambiguity is evident in the question about what MPI_FILE_INFO_GET
returns and in this discussion too. If an implementation supports 5 file hints
then it must select a value for each of these hints an MPI_FILE_OPEN. If there
is an MPI_Info that stipulates 2 of the hints then how many hints are in the
"current set of hints"? 2 or 5? I would say there are 5 and I think it makes
sense for MPI_FILE_GET_INFO to return all 5 (key,value) pairs.<BR><BR>Two more
specific points -<BR><BR>1) I would expect that if at MPI_FILE_OPEN the
implementation is given non-default hints ("A","yes") and ("B","no") and then
at MPI_FILE_INFO_SET is given ("B","yes") the net effect is that hint "A"
remains as set and hint "B" is altered (if possible). If there is a hint "C"
which has never been mentioned it will have received a default value at
MPI_FILE_OPEN and the MPI_FILE_INFO_SET which does not mention "C" will leave
that default unchanged.<BR><BR>Is the "clarification" saying hint "A" must
return to default when MPI_FILE_INFO_SET fails to mention it? If that is the
intent then I need to be convinced. If we decide this is to be blessed then we
probably need to say that any use of MPI_FILE_SET_INFO must first call
MPI_FILE_GET_INFO, tweek the INFO it gets back from MPI_FILE_GET_INFO and pass
that to MPI_FILE_SET_INFO to avoid unexpected changes to the set of hints that
is "in effect".<BR><BR>2) Since a hint is a hint, not a command, it can be
rejected. It is possible that some hint can be honored at MPI_FILE_OPEN but
once it has been honored, cannot be altered at reasonable cost. <BR><BR>For
example, maybe somebody's MPI_FILE_OPEN could accept a hint ("buffer_size",
"dynamic-64MB") meaning "start with a 64MB buffer but be prepared to accept
changes to buffer size". If the user has set hint ("buffer_size", "64MB") at
FILE_OPEN, the implelentation would omit whatever synchs are needed to
preserve the ability to change on the fly. Passing ("buffer_size",
"dynamic-16MB") to MPI_FILE_SET_INFO could be honored if the user had chosen
"dynamic" at FILE_OPEN but would need to be ignored if he had not.<BR><BR>For
most implementations, a hint like "buffer_size" could not be honored at all
after the first file read or write had been done.<BR><BR>Dick Treumann - MPI
Team/TCEM <BR>IBM Systems & Technology Group<BR>Dept 0lva / MS P963 --
2455 South Road -- Poughkeepsie, NY 12601<BR>Tele (845) 433-7846 Fax (845)
433-8363<BR><BR><BR><TT>mpi-21-bounces@cs.uiuc.edu wrote on 01/31/2008
08:24:51 AM:<BR><BR>> This is a proposal for MPI 2.1, Ballot 4.<BR>>
<BR>> I'm asking especially the implementors to check, whether<BR>> this
interpretation is implemented in their MPI implementations,<BR>> or does
not contradict to the existing implementation.<BR>> <BR>> This is a
follow up to:<BR>> MPI_File_set_info<BR>> in <A
href="http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-">http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-</A><BR>>
errata/index.html<BR>> with mail discussion not yet existing<BR>>
___________________________________<BR>> <BR>> Proposal:<BR>> Add in
MPI-2.0 Sect. 9.2.8, File Info, page 218, after line 18 the <BR>> following
sentences:<BR>> <BR>> With MPI_FILE_SET_VIEW and
MPI_FILE_SET_INFO the current setting<BR>> of all hints used by the
system to this open file is updated by <BR>> the (key,value) pairs
in the info argument.<BR>> ___________________________________<BR>>
Rationale for this clarification:<BR>> This text was missing. It was
not clear, whether a info handles<BR>> in MPI_FILE_SET_VIEW and
MPI_FILE_SET_INFO are updating or replacing<BR>> the current set of
used hints. <BR>> The developers from ROMIO decided to update the
current set of used hints.<BR>> Therefore, this behavior should be
the expected behavior of a majority<BR>> of users.<BR>>
___________________________________<BR>> <BR>> Best regards<BR>>
Rolf<BR>> <BR>> <BR>> <BR>> <BR>> Dr. Rolf Rabenseifner . . . .
. . . . . .. email rabenseifner@hlrs.de<BR>> High Performance Computing
Center (HLRS) . phone ++49(0)711/685-65530<BR>> University of Stuttgart . .
. . . . . . .. fax ++49(0)711 / 685-65832<BR>> Head of Dpmt Parallel
Computing . . . www.hlrs.de/people/rabenseifner<BR>> Nobelstr. 19, D-70550
Stuttgart, Germany . (Office: Allmandring 30)<BR>>
_______________________________________________<BR>> mpi-21 mailing
list<BR>> mpi-21@cs.uiuc.edu<BR>> <A
href="http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21">http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21</A><BR></TT></P></BLOCKQUOTE></BODY></HTML>