Unexpected result from MPI_TYPE_GET_VALUE_INDEX

[dalcinl]

I'm working on updating mpi4py to automatically build with all the MPI 4.0/5.1 features added to ompi@main.

I'm getting this unexpected result,

>>> from mpi4py import MPI
>>> MPI.Datatype.Get_value_index(MPI.FLOAT, MPI.FLOAT).Get_name()
'MPI_2REAL'

My expectation was MPI_DATATYPE_NULL, and that's what I wrote in my tests.
I hope we all agree that MPI_2REAL is a very awkward thing from F77 times.

Funny enough, look at the following

>>> from mpi4py import MPI
>>> MPI.Datatype.Get_value_index(MPI.REAL, MPI.REAL).Get_name()
'MPI_DATATYPE_NULL'

The MPI standard says: Integer types supported by the underlying compiler are acceptable index types. MPI 5.0 pp 230.

cc @hppritcha

[hppritcha]

so do you think that we should be returning MPI_DATATYPE_NULL for any index that isn't an integer type supported by the compiler?

[dalcinl]

so do you think that we should be returning MPI_DATATYPE_NULL for any index that isn't an integer type supported by the compiler?

Yes, though I'm not really sure, as there are some extra nuance to it, and it is all related to Fortran. This is my take:

1. For C types as value/index input, follow the standard, and reject non-integer types for the index. The proper way to MINLOC/MAXLOC in C is to use a struct type. Of course remember that whatever type is returned, MINLOC/MAXLOC should work with such type. I'm not sure whether Open MPI added support for the tensor-product of all value=integer/float and value=integer types, e.g. MPI_LONG_DOUBLE and MPI_SIGNED_CHAR to mention an "extreme" combination.
2. If C types are provided as input, MPI should not return Fortran datatypes. The Fortran datatypes do not have a "stable" ABI, and now in MPI 5.0 they could possibly change size from one program run to another due to users specifying different sizes. Maybe this is ultimately inconsequential if the returned datatype, even if different on each program run, matches the input value datatype. What is definitely not correct is to map MPI_FLOAT+MPI_FLOAT -> MPI_2REAL unconditionally without looking at the runtime size of MPI_REAL (I should double check what OMPI actually does).
3. For Fortran datatypes, given that we do have MPI_2REAL and MINLOC and MAXLOC work with it, I think is reasonable to map MPI_REAL+MPI_REAL -> MPI_2REAL, even if that CONTRADICTS the wording MPI standard.

Of maybe I'm misinterpreting the language of the standard. Perhaps Integer types supported by the underlying compiler are acceptable index types does NOT mean that other non-integer types are NOT acceptable. However, I would still argue that a
) any sane C programmer will not use a floating for the index types, and b) calling a reduction operations in C with MPI_2(REAL|DOUBLE_PRECISION), even if it works, is an abuse of MPI's cross-language interoperability.

@jeffhammond What's your opinion here?

[jeffhammond]

I'll comment later but please see https://github.com/mpi-forum/mpi-standard/pull/798

[dalcinl]

Looking also at mpi-forum/mpi-issues#70, seems that your original intention was indeed to move away from the Fortran 77 way of doing minloc/maxloc reductions.

[hppritcha]

okay we'll check if the incoming index is from fortran or c and if its from the former, possibly return real2 etc. but not for 'c' case.