[mpich-discuss] attribute value of MPI_TAG_UB

[Wei-keng Liao]

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 <balaji at anl.gov> 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 <discuss at mpich.org> 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     discuss at mpich.org
>> To manage subscription options or unsubscribe:
>> https://lists.mpich.org/mailman/listinfo/discuss
>