I orginally sent my suggestion out to some of the MPI-IO
implementors to get their opinion on it. To avoid
keeping the mpi-core group in the dark, I'll include
a copy here so you know what I had in mind. The
confusion I refer to below is whether it's legal to
have MPI_BYTE as a "wild card" etype that would match
any buftype or filetype.
BTW, I like Jean-Pierre's suggested editorial change to
the rationale, and I have incorporated it below.
---It may be too late to get this in, but I want to present it anyway and try to convince you that it's important.
Section 10.6.5 is too vague on the type matching rules, and it doesn't clearly maintain the distinction between matching of MPI types with each other and matching of MPI types with files and memory buffers. As evidence of this, there have already been significantly different interpretations of the type matching rules not only between Rajeev and our group at LLNL but also between different members of the LLNL group! The following is a longer but much more specific version of 10.6.5. My intent was to say what I thought the chapter implied, without adding any new restrictions. I found that I did have to relax the restriction on matching between data written and data read because, given the possibility of different datareps and of reading files not written by MPI (which I don't think we want to outlaw), the current rule is neither necessary nor sufficient to guarantee correct reading of data. So here goes.
John
In general, the type matching rules for I/O mimic the type matching rules for communication. As with communication, type matching must be considered at several phases (compare Section 3.3.1 of the MPI-1 reference document). For I/O, these phases are:
\begin{enumerate} \item Between the memory buffer and the MPI datatype passed to a READ or WRITE command.
\item Between the datatype and the file view.
\item Between the file view and the MPI file. \end{enumerate}
For Phase 1, the rules for matching the MPI datatype to the type of data in the buffer are identical to the rules for matching MPI datatypes to send and receive buffers in communication calls.
For Phase 2, the type signature of the datatype passed to a READ or WRITE operation must equal the type signature of some number of contiguous copies of the etype used in the current file view. More formally, let $D$ be the type signature of the \mpiarg{datatype} passed to a READ or WRITE operation on file handle $fh$. Let $E$ be the type signature of the etype of the current file view for $fh$. Then for any MPI READ or WRITE operation, $D = E^r$ must hold for some positive integer $r$, where $E^r$ is the sequence of MPI basic types that consists of $r$ repetitions of $E$.
For Phase 3, MPI imposes type matching only on READ operations. Each data item read from a file must represent a legal value of the corresponding MPI basic type in the view. Specifically, let $V = \{(type_0, disp_0), (type_1, disp_1),\ldots \}$ be the (arbitrarily long) type map that represents the current file view on file handle $fh$ (where $type_i$ is an MPI basic type and $disp_i$ is its byte displacement with respect to the start of the file). Let $B = \{b_0, b_1,\ldots, b_{n-1}\}$ be the sequence of bytes in the file that $fh$ points to. An MPI read operation that accesses element $i$ of $V$ will read the byte sequence $B_i = \{b_{disp_i}, \ldots, b_{disp_{i} + s - 1}\}$ from the file, where $s$ is the size of $type_i$ in bytes, as computed by calling MPI\_FILE\_GET\_TYPE\_EXTENT for $type_i$ and $fh$. Then for each read operation of an element $i$ in $V$, the byte sequence $B_i$ must be a legal value for $type_i$ in the current data representation for $fh$.
\begin{users} The type matching rules between views and file data are quite lax. A program may write a data item as a floating-point number and then read the same bytes back as an integer. An MPI implementation is not required to recognize such a mismatch or to perform any conversion between these types. Also, the type matching rules between MPI datatypes and memory buffers permit a memory buffer of any type to be accessed using MPI\_BYTE. All of these type mismatches, though legal, will defeat the file interoperability features of MPI. READ and WRITE functions can only perform automatic conversion between heterogeneous data representations when the exact MPI basic types read and written are equal and are explicitly specified. \end{users}
\begin{rationale} Although it may seem desirable to impose stronger restrictions on the type matching between file data and file views, doing so would require implicitly defining the type of each element in a file. Unlike variables in a program, data in a file typically has no type independent of what an MPI read or write operation imposes on it. It would be possible to require that the MPI datatype used to read a file must match MPI datatype that was used to write it, but this would make it erroneous to read any file not written by MPI, and it would not account for the possibility that programs might read and write a file using different data representations. \end{rationale}