I expect that there are some (hopefully) minor clarifications and
changes needed to this proposal, but I think it's good enough to send
out for further discussion. Please look this over and make comments on
[For the present purposes I am considering only the following functions:
(from the TMC proposal) and
(from the NEC proposal). The other proposed functions, namely:
are ignored here -- I consider them to be logically separate proposals.]
The TMC proposal for low level accessors has the problem that the FORTRAN
user can't malloc and hence has to pass in arrays to MPI_Type_elements
that are a fixed size -- a size that might be too small for a particular
The NEC proposal has the problem that the information about the combiner
is lost, resulting in a rather verbose output and the C user has no way
of finding out, a priori, how many times he or she is going to have to
call MPIDE_Type_next. Thus the C code is more complex than it needs to
First, the prototypes:
MPI_Type_envelope(MPI_Datatype datatype, /* IN */
int *count, /* OUT */
int *combiner); /* OUT */
MPI_Type_contents(MPI_Datatype datatype, /* IN */
int start, /* IN */
int count, /* IN */
int *array_blocklens, /* OUT */
MPI_Aint *stride, /* OUT: XXX */
MPI_Aint *array_disps, /* OUT: XXX */
MPI_Datatype *array_types); /* OUT */
Given an MPI datatype 'datatype', returns in 'combiner' one of the
Each of the above constants is a defined integer constant (C) or
parameter (FORTRAN). In C, they are usable in a switch statement.
If combiner is MPI_BASIC, then the returned count is 1; if combiner is
anything else (i.e., MPI_CONTIG, MPI_VECTOR, MPI_HVECTOR, MPI_INDEXED,
MPI_HINDEXED, or MPI_STRUCT), then the returned count is the 'count'
argument passed in to the corresponding MPI_Type_xxx function
(respectively: MPI_Type_contiguous, MPI_Type_vector, MPI_Type_hvector,
MPI_Type_indexed, MPI_Type_hindexed, or MPI_Type_struct).
Returns infomation about the top-level datatypes that underlie
'datatype' except it skips the first 'start' underlying datatypes and
returns information on the next 'count' datatypes.
If 'count' is <= 0, then nothing is returned; otherwise...
[I lean towards making this an error. comments?
Also, should 'count' be 'INOUT' rather than 'IN'? That is, should it be
set to the number of elements being returned? I lean towards leaving it
as it is, but I don't really care...]
If the 'combiner' returned by MPI_Type_envelope was MPI_BASIC, then
'datatype' is a basic datatype; array_blocklens, stride, and array_disps
are not modified, and array_types is 'datatype'.
If the 'combiner' returned by MPI_Type_envelope was MPI_CONTIG, then
oldtype is returned in array_types.
If the 'combiner' returned by MPI_Type_envelope was VECTOR or HVECTOR,
then blocklength, stride, and oldtype are returned in
array_blocklens, *stride, and array_types, respectively.
If the combiner is INDEXED, HINDEXED, or STRUCT, then define filled:
filled = max(0, min(con_count, env_count - start))
env_count == count passed in to MPI_Type_envelope
con_count == count passed in to MPI_Type_contents
start == start passed in to MPI_Type_contents.
If the 'combiner' returned by MPI_Type_envelope was INDEXED or HINDEXED,
then array_of_blocklengths and array_of_displacements are returned in
the first 'filled' positions of array_blocklens and array_disps,
respectively and oldtypes is returned in array_types.
If the 'combiner' returned by MPI_Type_envelope was STRUCT, then
array_of_blocklengths, array_of_displacements, and array_of_types are
returned in the first 'filled' positions of array_blocklens,
array_disps, and array_types, respectively.