+-------------------------------------------+
| int | double | char | char | char | float |
+-------------------------------------------+
MPI does not currently provide *any* mechanism to express this
as a *portable* datatype. Currently, the best a user can do is:
int lengths[] = { 1, 1 };
MPI_Aint disps[2];
MPI_Datatype types = { MPI_INT, MPI_FLOAT };
MPI_File_get_type_extent(fh, MPI_INT, &int_size);
MPI_File_get_type_extent(fh, MPI_DOUBLE, &double_size);
MPI_File_get_type_extent(fh, MPI_CHAR, &double_size);
disps[0] = 0;
disps[1] = int_size + double_size + (char_size * 3);
MPI_Type_struct(2, lengths, disps, types, &newtype);
MPI_Type_struct does not create a *portable* datatype, however,
so a new datatype must be created for every open file in which
this type is used, in addition to the one used for process memory.
So, MPI_Type_struct and MPI_File_get_type_extent do not solve
the problem, although the user can get around it, with some
difficulty.
-----
Note that a similar problem exists in one-sided communication
in a heterogeneous environment, although, in that case, alignment
causes additional headaches.
If we wanted to solve the problem for I/O, we would need a mechanism
to create portable datatype-sized "holes", e.g.,
MPI_TYPE_CREATE_HOLE(oldtype, hole)
This routine creates a new datatype, hole, with size zero and
extent equal to the extent of oldtype. If oldtype was a
portable type, then "hole" is a portable type.
and a mechanism to combine them, e.g.,
MPI_TYPE_SIMPLE_STRUCT(count, array_of_blocklengths,
array_of_types, newtype)
See JOD for description, but delete all the padding rules.
I would say that if there is a lot of time left after we finish
up everything else we have to do on MPI-2, we might want to discuss
this issue. Otherwise, it's probably better left alone for now.
- bill
Bill Nitzberg nitzberg@nas.nasa.gov
NAS Parallel Systems, MRJ
NASA Ames Research Center, M/S 258-6 Tel: (415) 604-4513
Moffett Field, CA 94035-1000 FAX: (415) 966-8669