I've been following the datatype discussions on the mpi-external
reflector with interest, although I haven't commented much because
all of the proposals give us much of what we need. There are
basically two things we need to do with MPI datatypes: transmit
them and decode them. For transmitting them, a compact string
representation is fine. Steve mentioned a new proposal for a
method to send MPI datatypes. I don't know what the proposers
have in mind, but for us the most useful approach would be one
that let us treat datatype objects like other built-in MPI types:
struct OpenRequest {
char filename[NAMELEN];
MPI_Datatype etype;
MPI_Datatype filetype;
/* ... etc ... */
} open_request;
int blocklens[2] = { NAMELEN, 2 };
MPI_Aint indices[2] = { 0, NAMELEN };
MPI_Datatype types[2] = { MPI_CHAR, MPI_DATATYPE };
MPI_Datatype open_req_type;
int mydest, mytag;
MPI_Type_struct( 2, blocklens, indices, types, &open_req_type );
/* ... */
MPI_Send( &open_request, 1, open_req_type, mydest, mytag, MPI_COMM_WORLD );
Of course, this may be impossible to implement because the size
of a datatype representation is variable and has no upper limit.
On the other hand, a strategy that let a program send only
datatypes in a message would not be very useful to us:
MPI_Send_datatype( etype, mydest, mytag, MPI_COMM_WORLD );
Since we have related data to send at the same time, we'd have
to send multiple messages and somehow guarantee that all the
data was associated correctly at the receiving end.
As for interpreting a datatype, we end up constructing a list of
contiguous byte blocks. MPI probably shouldn't be describing
data at this low a level, since that kind of description isn't
portable. An unrolled typemap probably isn't that useful either,
since our code would have to walk though it and identify
contiguous chunks one element at a time. So no matter how MPI
presents the datatype information, our code will have to do some
processing to get the data in the form we need.
As for MPI_Status, there are again two issues for us: First,
if we use MPI_Status to return the amount of data moved, we
have to store something in the status object. MPICH has a count
field that works just fine for this, although we really shouldn't
be writing to this field because its presence is implementation
dependent. Unless MPI2 includes some function that lets us store
count data in MPI_Status, MPI-IO needs to define its own status
object. Otherwise, MPI-IO implementations will continue to rely
on MPI implementation details.
The second issue is whether an MPI-IO implementation would need
to store any information in a status object that MPI doesn't now
use. For now, I don't think so. All the additional information
needed to determine the number of etypes, filetypes, or buftypes
moved is already available.
John