From treumann@XXXXXXXXXX Fri Feb 1 14:34:17 2008 In-Reply-To: Subject: Re: Fw: [mpi-21] Ballot 4 - MPI_File_get_info To: "Rolf Rabenseifner" Cc: bronis@XXXXXXXX,"Bill Gropp" ,rabenseifner@XXXXXXX,X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Richard Treumann Date: Fri, 1 Feb 2008 15:33:55 -0500 X-MIMETrack: Serialize by Router on D01ML064/01/M/IBM(Release 7.0.2FP2 IGS702FP2HF5|November 8, 2007) at 02/01/2008 15:33:57 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBF971DFFCD9D78f9e8a93df938690918c0ABBF971DFFCD9D7" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at mailgw.mcs.anl.gov --0__=0ABBF971DFFCD9D78f9e8a93df938690918c0ABBF971DFFCD9D7 Content-type: multipart/alternative; Boundary="1__=0ABBF971DFFCD9D78f9e8a93df938690918c0ABBF971DFFCD9D7" --1__=0ABBF971DFFCD9D78f9e8a93df938690918c0ABBF971DFFCD9D7 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable OK - the standard does say that an implementation should return filenam= e if it can. I guess if an implementation is not able to discover the filena= me by the time the app calls MPI_FILE_GET_INFO there is no requirement tha= t the "filename" hint be returned. The description of the "filename" hin= t on page 220 comes close to a requirement but leaves an out. That means an= implementation that is not "capable of returning the file name" might return MPI_INFO_NULL. I have a hard time imagining how any implementation could have been giv= en the filename at MPI_FILE_OPEN but not be "capable of returning the file= name" later but that is the text Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 = "Rolf = Rabenseifner" = Richard = Treumann/Poughkeepsie/IBM@IBMUS,= 02/01/2008 12:14 rabenseifner@XXXXXXXX = PM bronis@XXXXXXXX = = cc "Bill Gropp" =, "Rajeev Thakur" = , Rob Ross = = Subj= ect Re: Fw: [mpi-21] Ballot 4 - = MPI_File_get_info = = = = = = = Dick, I expect that Bill had put the question on the errata page and I do not know the historical reason. As MPI 2.1 chair, I try to take all unclear items and to bring them into a clear state. I took your input mainly as the information that this clarification is only needed for implementations, that do not use any default infos on file handles. Therefore, this clarification may not have any impact on current implementations. A portable user appplication should be aware, that the MPI standard does not guarantee default hints on file handles. And therefore the application programmer should know where he/she must make which if-statement to have not a broken application code. Do we know, what a cheap and light MPI implementation may offer on a beautiful xxx-flop-platform in 7 years? Therefore this clarification is mainly for consistency and portability. Okay? Best regards Rolf On Fri, 1 Feb 2008 09:23:09 -0500 Richard Treumann wrote:> > >Is this still topic still open? I sent this note suggesting the issue = is >moot and have not seen any response. If no response means the questio= n has >been removed from consideration, that is fine. If not, what next. I w= as >not able to find discussion history older than Rolf's note and Bronis'= >reply so I do not know where the original concern came from. > > Thanks > >Dick Treumann - MPI Team/TCEM >IBM Systems & Technology Group >Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 >Tele (845) 433-7846 Fax (845) 433-8363 > >----- Forwarded by Richard Treumann/Poughkeepsie/IBM on 02/01/2008 09:= 08 AM >----- > > Richard > Treumann/Poughkee > psie/IBM@IBMUS = To > Sent by: "Mailing list for discussion of= MPI > mpi-21-bounces@cs 2.1" > .uiuc.edu = cc > > Sub= ject > 01/31/2008 09:25 Re: [mpi-21] Ballot 4 - > AM MPI_File_get_info > > > Please respond to > "Mailing list for > discussion of MPI > 2.1" > du> > > > > > > >I think this proposal is moot unless it is intended as a loophole to a= llow >an implementation to provide a zero-functionality version of the INFO >bindings. The "filename" hint is always present on an MPI_File so ther= e >should never be a empty MPI_FILE_GET_INFO return. > >Dick >hh >Dick Treumann - MPI Team/TCEM >IBM Systems & Technology Group >Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 >Tele (845) 433-7846 Fax (845) 433-8363 > > >mpi-21-bounces@XXXXXXXXXXX wrote on 01/31/2008 08:01:20 AM: > >> This is a proposal for MPI 2.1, Ballot 4. >> >> I'm asking especially the implementors to check, whether >> this interpretation is implemented in their MPI implementations, >> or does not contradict to the existing implementation. >> >> This is a follow up to: >> MPI_File_get_info >> in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- >> errata/index.html >> with mail discussion not yet existing >> ___________________________________ >> >> Proposal: >> MPI-2.0 Sect. 9.2.8, File Info, page 219, lines 11-13 read: >> >> MPI_FILE_GET_INFO returns a new info object containing the hint= s >> of the file associated with fh. The current setting of all hints >> actually used by the system related to this open file is returned >> in info_used. >> The user is responsible for freeing info_used via MPI_INFO_FREE. >> >> but should read (" or an abort(errorcode)" removed): >> >> MPI_FILE_GET_INFO returns a new info object containing the hint= s >> of the file associated with fh. The current setting of all hints >> actually used by the system related to this open file is returned >> in info_used. >> If there does not exist such a hint, MPI_INFO_NULL is returned. >> The user is responsible for freeing info_used via MPI_INFO_FREE >> if info_used is not MPI_INFO_NULL. >> ___________________________________ >> Rationale for this clarification: >> This text was missing. It was not clear, whether a MPI_Info handle= >> would be returned that would return nkeys=3D0 from MPI_INFO_GET_NK= EYS. >> From user's point of view, this behavior might have been expected >> without this clarification. >> ___________________________________ >> >> As far as I understand, ROMIO is using for all filesystems some defa= ult >> hints and therefore "no-hints" is never returned. >> MPI_File_set_view and MPI_File_set_info are only modifying values >> but do not remove keys. >> Therefore, the info handle cannot become empty. >> >> Best regards >> Rolf >> >> >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner@XXXXXXX e >> High Performance Computing Center (HLRS) . phone ++49(0)711/685-6553= 0 >> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-6583= 2 >> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifne= r >> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) >> _______________________________________________ >> mpi-21 mailing list >> mpi-21@XXXXXXXXXXX >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 >_______________________________________________ >mpi-21 mailing list >mpi-21@XXXXXXXXXXX >http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner@XXXXXXX High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) = --1__=0ABBF971DFFCD9D78f9e8a93df938690918c0ABBF971DFFCD9D7 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

OK - the standard does say that an implementation should return file= name if it can. I guess if an implementation is not able to discover th= e filename by the time the app calls MPI_FILE_GET_INFO there is no requ= irement that the "filename" hint be returned. The descriptio= n of the "filename" hint on page 220 comes close to a require= ment but leaves an out. That means an implementation that is not "= ;capable of returning the file name" might return MPI_INFO_NULL.
I have a hard time imagining how any implementation could have been giv= en the filename at MPI_FILE_OPEN but not be "capable of returning = the file name" later but that is the text


Dick Treumann - MPI Team/TCEM
IBM Systems & Technology Group
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846 Fax (845) 433-8363

3D"Inactive
=
          "Rolf Rabenseifner" <rabenseifner@= hlrs.de>

          02/01/2008 12:14 PM

 =
3D=
To
3D""
Richard Treumann/Poughkeepsie/IBM@IBMUS, rabenseifner@= hlrs.de, bronis@XXXXXXXXXXXXXXXXXXXXXXXXX
3D=
cc
3D""
"Bill Gropp" <gropp@XXXXXXXXXXXXXXXX &quo= t;Rajeev Thakur" <thakur@XXXXXXXXXXXXXXXX Rob Ross <rross@mc= s.anl.gov>
3D=
Subject
3D""
Re: Fw: [mpi-21] Ballot 4 - MPI_File_get_info
3D=3D""

Dick,

I expect that Bill had put the question on the errata page
and I do not know the historical reason.
As MPI 2.1 chair, I try to take all unclear items
and to bring them into a clear state.

I took your input mainly as the information that this clarification
= is only needed for implementations, that do not use any
default infos on file handles.

Therefore, this clarification may not have any impact on
current implementations.
A portable user appplication should be aware, that the MPI
standard does not guarantee default hints on file handles.
And therefore the application programmer should know
where he/she must make which if-statement to have not a broken
application code.

Do we know, what a cheap and light MPI implementation may
offer on a beautiful xxx-flop-platform in 7 years?

Therefore this clarification is mainly for consistency
and portability.

Okay?

Best regards
Rolf


On Fri, 1 Feb 2008 09:23:09 -0500
Richard Treumann <treumann@XXXXXXXXXXXXXX wrote:
>
>
>Is this still topic still open? I sent this note suggesting the iss= ue is
>moot and have not seen any response.  If no response means the= question has
>been removed from consideration, that is fine.  If not, what n= ext. I was
>not able to find discussion history older than Rolf's note and Bron= is'
>reply so I do not know where the original concern came from.
>
>                Thanks
>
>Dick Treumann  -  MPI Team/TCEM
>IBM Systems & Technology Group
>Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 >Tele (845) 433-7846         Fax (845) 433-8363<= br> >
>----- Forwarded by Richard Treumann/Poughkeepsie/IBM on 02/01/2008 = 09:08 AM
>-----
>                   &nb= sp;                   &nbs= p;                    = ;              
>             Richard     &n= bsp;                   &nb= sp;                   &nbs= p;        
>             Treumann/Poughkee  =                     =                     &= nbsp;
>             psie/IBM@IBMUS   &n= bsp;                   &nb= sp;                   &nbs= p; To
>             Sent by:     &= nbsp;            "Mailing list for d= iscussion of MPI
>             mpi-21-bounces@cs  =       2.1" <mpi-21@XXXXXXXXXXXXXXX    = ;      
>             .uiuc.edu     =                     &= nbsp;                   &n= bsp;    cc
>                   &nb= sp;                   &nbs= p;                    = ;              
>                   &nb= sp;                   &nbs= p;                    = ;       Subject
>             01/31/2008 09:25   =        Re: [mpi-21] Ballot 4 -      =      
>             AM       =                  MPI_File_= get_info                  =
>                   &nb= sp;                   &nbs= p;                    = ;              
>                   &nb= sp;                   &nbs= p;                    = ;              
>             Please respond to  =                     =                     &= nbsp;
>             "Mailing list for &= nbsp;                   &n= bsp;                   &nb= sp;  
>             discussion of MPI  =                     =                     &= nbsp;
>                   2.1= "                   &= nbsp;                   &n= bsp;            
>             <mpi-21@XXXXXXXXX &nb= sp;                   &nbs= p;                    = ;  
>                   &nb= sp;du>                  = ;                    =              
>                   &nb= sp;                   &nbs= p;                    = ;              
>                   &nb= sp;                   &nbs= p;                    = ;              
>
>
>
>
>I think this proposal is moot unless it is intended as a loophole t= o allow
>an implementation to provide a zero-functionality version of the IN= FO
>bindings. The "filename" hint is always present on an MPI= _File so there
>should never be a empty MPI_FILE_GET_INFO return.
>
>Dick
>hh
>Dick Treumann - MPI Team/TCEM
>IBM Systems & Technology Group
>Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 >Tele (845) 433-7846 Fax (845) 433-8363
>
>
>mpi-21-bounces@XXXXXXXXXXX wrote on 01/31/2008 08:01:20 AM:
>
>> This is a proposal for MPI 2.1, Ballot 4.
>>
>> I'm asking especially the implementors to check, whether
>> this interpretation is implemented in their MPI implementation= s,
>> or does not contradict to the existing implementation.
>>
>> This is a follow up to:
>>   MPI_File_get_info
>>   in http://www.cs.uiuc.edu/homes/wgropp/pro= jects/parallel/MPI/mpi-
>> errata/index.html
>> with mail discussion not yet existing
>> ___________________________________
>>
>> Proposal:
>> MPI-2.0 Sect. 9.2.8, File Info, page 219, lines 11-13 read: >>
>>      MPI_FILE_GET_INFO returns a new info objec= t containing the hints
>>   of the file associated with fh. The current setting of = all hints
>>   actually used by the system related to this open file i= s returned
>>   in info_used.
>>   The user is responsible for freeing info_used via MPI_I= NFO_FREE.
>>
>> but should read (" or an abort(errorcode)" removed):=
>>
>>      MPI_FILE_GET_INFO returns a new info objec= t containing the hints
>>   of the file associated with fh. The current setting of = all hints
>>   actually used by the system related to this open file i= s returned
>>   in info_used.
>>   If there does not exist such a hint, MPI_INFO_NULL is r= eturned.
>>   The user is responsible for freeing info_used via MPI_I= NFO_FREE
>>   if info_used is not MPI_INFO_NULL.
>> ___________________________________
>> Rationale for this clarification:
>>   This text was missing. It was not clear, whether a MPI_= Info handle
>>   would be returned that would return nkeys=3D0 from MPI_= INFO_GET_NKEYS.
>>   From user's point of view, this behavior might have bee= n expected
>>   without this clarification.
>> ___________________________________
>>
>> As far as I understand, ROMIO is using for all filesystems som= e default
>> hints and therefore "no-hints" is never returned. >> MPI_File_set_view and MPI_File_set_info are only modifying val= ues
>> but do not remove keys.
>> Therefore, the info handle cannot become empty.
>>
>> Best regards
>> Rolf
>>
>>
>> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner@= hlrs.de
>> High Performance Computing Center (HLRS) . phone ++49(0)711/68= 5-65530
>> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 68= 5-65832
>> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/raben= seifner
>> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandrin= g 30)
>> _______________________________________________
>> mpi-21 mailing list
>> mpi-21@XXXXXXXXXXXXXXX >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 >_______________________________________________
>mpi-21 mailing list
>mpi-21@XXXXXXXXXXXXXXX >http:/= /lists.cs.uiuc.edu/mailman/listinfo/mpi-21



Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner@XXXXXXXXXX r> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)
=
= --1__=0ABBF971DFFCD9D78f9e8a93df938690918c0ABBF971DFFCD9D7-- --0__=0ABBF971DFFCD9D78f9e8a93df938690918c0ABBF971DFFCD9D7 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBF971DFFCD9D78f9e8a93df938@XXXXXXXXXX>Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBF971DFFCD9D78f9e8a93df938690918c0ABBF971DFFCD9D7 Content-type: image/gif; name="pic06815.gif" Content-Disposition: inline; filename="pic06815.gif" Content-ID: <2__=0ABBF971DFFCD9D78f9e8a93df938@XXXXXXXXXX>Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=0ABBF971DFFCD9D78f9e8a93df938690918c0ABBF971DFFCD9D7 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=0ABBF971DFFCD9D78f9e8a93df938@XXXXXXXXXX>Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBF971DFFCD9D78f9e8a93df938690918c0ABBF971DFFCD9D7--