Rajeev wrote:
> If someone new to MPI-IO asks me why there are both etypes and
> filetypes, where filetypes also define a tiling, I'm not sure
> I can give a convincing answer.
My answer to that person would be that etype defines the basic data unit
which makes up the file such as byte or some C structure, and filetype
is useful for defining a cyclic, non-sequential ordering of etypes.
Of course, filetypes are not giving added access capability, but do
offer the possibility of simplifying non-sequential access for the
user, IMHO.
> Therefore, I am in favor of eliminating etypes. It will simplify the
> interface.
I do not see how removing etypes significantly simplifies the interface.
The user can always let filetype equal etype. On the contrary I believe
removing etypes will result in creating more work for a user when performing
non-sequential access that could otherwise have been defined by a
strided filetype. Of course, the filetype alone (w/o etype) can
define a non-sequential, repeating access pattern, but in that case I
don't see how we could guarantee that buftype and filetype have the same
signature if buftype's structure doesn't equal that of the filetype.
Next issue:
I remember reading some discussion about whether or not buftype was meant
to be tiled, or to be defined for the whole user buffer (or did I
misunderstand something?). I've always assumed buftype would be tiled
just as filetype. If that is so, and buftype will continue to be defined
in terms of etype (or filetype, if etypes are struck down), then
I believe that the count parameter in the read/write calls should
refer to the number of etypes to read or write and not the number of
buftypes.
In the current definition if the structure of the data buffer is such
that more than one etype is required to define the buftype, then there
is no way to read a number of etypes that is not a multiple of the number
of etypes in buftype.
This seems to me to be an unnecessary restriction especially since the number
of etypes in buftype may simply be the number that was necessary in order
to create one complete tiling of the buffer and not have anything to do
with how the user plans to access the file.
Last issue:
Addition of one file open mode: MPI_TEMP_FILE. This mode would partly
consist of: MPI_CREATE | MPI_DELETE_ON_CLOSE. One difference, however,
between MPI_TEMP_FILE and the mode combination just mentioned would be that
if the file already existed it would be truncated to zero or just ignored
on open. It seems to me that such a mode would be especially useful to
scientific applications that commonly use many temporary files. Also,
it would allow certain optimizations. For example, the implementation
could choose to create such files in memory and not touch the disk.
Darren Sanders
--- sanders@hpc.uh.edu University of Houston