Hi Pavan You are right. The example shows me the right way to call MPI_Comm_get_attr(). I am now getting a consistent value of 268435455 from MPICH 3.3 and 2147483647 from OpenMPI 4.0.1 when running on a Redhat box. Thanks, Wei-keng

On May 2, 2019, at 7:43 PM, Balaji, Pavan <[email protected]> wrote:

Attributes have these weird point-to-integer casting semantics. Make sure you are using it correctly.

See https://github.com/pmodels/mpich/blob/master/test/mpi/attr/baseattr2.c#L30

Basically, even though the parameter is "void *", it really needs to be treated as "int **" in this case.

-- Pavan

...

On Apr 26, 2019, at 2:18 PM, Wei-keng Liao via discuss <[email protected]> wrote:

According to MPI 3.1, Section 8.1.2, the attribute value of MPI_TAG_UB attached to MPI_COMM_WORLD can be inquired by function MPI_Comm_get_attr(). It has the same value on all processes of MPI_COMM_WORLD.

My first question is should this value be the same across different runs? A small test program using MPICH 3.3 shows they are not the same across runs and across processes. But when compiled with the latest master branch, they are the same. So, can I assume the answer to my question is YES and MPICH has fixed this in the master branch?

My second question is that I notice MPI_TAG_UB is defined as a constant of 0x64400001 (=1681915905) in mpi.h. That value is not the one returned by MPI_Comm_get_attr(), which is 10345120. Is this intended?

I also tested OpenMPI 4.0.0. The inconsistency occurs across different runs, as well as different processes. I can see OpenMPI defines MPI_TAG_UB as an enum type, rather than a constant.

Wei-keng

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