146:13 STRUCT instead of CREATE_STRUCT
And now new arguments for the decision to Parkson's alternatives:
Parkson Wong wrote:
> On page 147, line 47 to 49 reads:
> If combiner is MPI_COMBINER_FUNDAMENTAL then ni = 0, na = 0,
> and nd = 0 so none of the arrays are used.
> In this case, the value returned in type must be one of the
> predefined handles.
> Two things here, one type is not one of the arguement to the function call.
> If the intent is datatype, it is an IN parameter, and so cannot hold any return
> value. If something is returned, it is returned in the array_of_datatypes,
> and nd = 1. But it explicitly said nd = 0 and the array is not used.
> Are we trying to say that "MPI_COMBINER_FUNDAMENTAL is returned by
> MPI_Type_get_envelope if and only if datatype is one of the predefined handle"?
> MPI_Type_get_contents when called with the datatype argument containing a
> predefined handle will return nothing.
> Or do we really want a datatype be returned in the array_of_datatypes?
I believe we must go this second way due to the definition of
163:19-21 defines for MPI_TYPE_DUP:
The new datatype has ... as well as yielding the same result
when decoded with the functions in section 7.6
i.e. MPI_TYPE_GET_ENVELOPE and MPI_TYPE_GET_CONTENTS
And I think that the handle returned by MPI_TYPE_DUP may be different
because 1st it is allowed and 2nd the attributes can be modified
due to 163:17-18.
Therefore the looking at the input argument "datatype" of
MPI_TYPE_GET_ENVELOPE does not answer the question which
fundamental datatype it is if MPI_COMBINER_FUNDAMENTAL is
returned in "combiner".
Therefore it is necessary to return nd=1 and to use
MPI_TYPE_GET_CONTENTS which returns the corresponding predefined
datatype handle in d or D(1).
Rolf Rabenseifner (Computer Center )
Rechenzentrum Universitaet Stuttgart (University of Stuttgart)
Allmandring 30 Phone: ++49 711 6855530
D-70550 Stuttgart 80 FAX: ++49 711 6787626