<html><body>
<p>Rajeev <br>
<br>
I think you just agreed with the interpretation I advocated. Neither the proposal or rationale made this at all clear to me. How about?<br>
<br>
<tt>Proposal:<br>
Add in MPI-2.0 Sect. 9.2.8, File Info, page 218, after line 18 the <br>
following sentences:<br>
<br>
When an info object that mentions a subset of valid hints</tt><br>
<tt> is passed to MPI_FILE_SET_VIEW or MPI_FILE_SET_INFO, there </tt><br>
<tt> will be no effect on previously set or defaulted hints that </tt><br>
<tt> the info does not mention. </tt><br>
<tt> <br>
___________________________________<br>
Rationale for this clarification:<br>
This text was missing. It was not clear, whether an info object<br>
in MPI_FILE_SET_VIEW and MPI_FILE_SET_INFO was intended to </tt><br>
<tt> replace only the mentioned hints or was intended to substitute</tt><br>
<tt> a complete new set of hints for the prior set.<br>
___________________________________</tt><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 12:29:41 PM:<br>
<br>
> The intent is that if the user calls MPI_File_set_info (or <br>
> MPI_File_set_view) twice, the 2nd call will only update (if <br>
> possible) the key-vals passed in the 2nd call; others are <br>
> unmodified. If the 2nd call passes MPI_INFO_NULL, nothing will <br>
> change -- it won't nullify previously passed hints.</tt><br>
<tt>> </tt><br>
<tt>> Rajeev</tt><br>
<tt>> </tt><br>
<tt>> <br>
> From: mpi-21-bounces@cs.uiuc.edu [<a href="mailto:mpi-21-bounces@cs.uiuc.edu">mailto:mpi-21-bounces@cs.uiuc.edu</a>] <br>
> On Behalf Of Richard Treumann<br>
> Sent: Thursday, January 31, 2008 9:23 AM<br>
> To: Mailing list for discussion of MPI 2.1<br>
> Subject: Re: [mpi-21] Ballot 4 - MPI_File_set_info update or replacement<br>
</tt><br>
<tt>> I think we have an overall ambiguity about what the "current set of <br>
> hints" is. This ambiguity is evident in the question about what <br>
> MPI_FILE_INFO_GET returns and in this discussion too. If an <br>
> implementation supports 5 file hints then it must select a value for<br>
> each of these hints an MPI_FILE_OPEN. If there is an MPI_Info that <br>
> stipulates 2 of the hints then how many hints are in the "current <br>
> set of hints"? 2 or 5? I would say there are 5 and I think it makes <br>
> 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 <br>
> given non-default hints ("A","yes") and ("B","no") and then at <br>
> MPI_FILE_INFO_SET is given ("B","yes") the net effect is that hint <br>
> "A" remains as set and hint "B" is altered (if possible). If there <br>
> is a hint "C" which has never been mentioned it will have received a<br>
> default value at MPI_FILE_OPEN and the MPI_FILE_INFO_SET which does <br>
> not mention "C" will leave that default unchanged.<br>
> <br>
> Is the "clarification" saying hint "A" must return to default when <br>
> MPI_FILE_INFO_SET fails to mention it? If that is the intent then I <br>
> need to be convinced. If we decide this is to be blessed then we <br>
> probably need to say that any use of MPI_FILE_SET_INFO must first <br>
> call MPI_FILE_GET_INFO, tweek the INFO it gets back from <br>
> MPI_FILE_GET_INFO and pass that to MPI_FILE_SET_INFO to avoid <br>
> 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 <br>
> possible that some hint can be honored at MPI_FILE_OPEN but once it <br>
> has been honored, cannot be altered at reasonable cost. <br>
> <br>
> For example, maybe somebody's MPI_FILE_OPEN could accept a hint <br>
> ("buffer_size", "dynamic-64MB") meaning "start with a 64MB buffer <br>
> but be prepared to accept changes to buffer size". If the user has <br>
> set hint ("buffer_size", "64MB") at FILE_OPEN, the implelentation <br>
> would omit whatever synchs are needed to preserve the ability to <br>
> change on the fly. Passing ("buffer_size", "dynamic-16MB") to <br>
> MPI_FILE_SET_INFO could be honored if the user had chosen "dynamic" <br>
> 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 <br>
> 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>
> 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>
> _______________________________________________<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></body></html>