MPI_Accumulate permits the use of pre-defined reduction operations with user-defined datatypes, provided the user-defined datatypes are homogeneous. Your use of MPI_MAXLOC with MY_2INT for MPI_Accumulate is legal in my reading of the standard. It may not be legal for MPI_Reduce because of the stupid asymmetry (that I believe you have pointed out in the past) wherein MPI_Reduce (and MPI_Allreduce) cannot do things that MPI_Accumulate can do w.r.t. built-in MPI_Op with user-defined MPI_Datatype. Perhaps MPI_Accumulate is correct in not generating but providing the wrong answer for MPI_MAXLOC, which would be a bug of a different nature. Jeff On Tue, Jan 1, 2013 at 1:09 PM, Jed Brown <[email protected]> wrote:

With MPI_Reduce, we get a nice helpful error message:

Fatal error in PMPI_Reduce: Invalid MPI_Op, error stack: PMPI_Reduce(1217)...........: MPI_Reduce(sbuf=0x7fff3e39fa50, rbuf=0x7fff3e39fa40, count=1, dtype=USER<contig>, MPI_MAXLOC, root=0, MPI_COMM_WORLD) failed MPIR_MAXLOC_check_dtype(151): MPI_Op MPI_MAXLOC operation not defined for this datatype

With MPI_Accumulate, we just get wrong results. See attached code using a user-defined contiguous results.

I care about this because I'm stuck [1] dispatching into alternative mechanisms for type combinations that are not directly supported by MPI (e.g., struct {int u; long long k;} and __float128). I missed a spot and had a confusing bug that I think MPICH should be catching.

[1] As usual, the crud would evaporate if only MPI_Accumulate were extensible over datatypes.

_______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

-- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute [email protected] / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond