[mpich-discuss] MPI_GET_COUNT behaviour unclear

[Tamás Faragó]

2009/12/15 Dave Goodell <goodell at mcs.anl.gov>

> [my page/section references are also relative to the MPI-2.1 Standard]
>
>
> On Dec 15, 2009, at 6:18 AM, Tamás Faragó wrote:
>
>  I have a question about MPI_GET_COUNT and MPI_GET_ELEMENTS. What do these
>> functions exactly return?
>>
>> As I have read from the documentation (3.2.5) MPI_GET_COUNT returns the
>> count of 'entries' of type 'datatype' received. According to me in example
>> 4.12 (line 13) MPI_GET_COUNT should return 2 as we have sent two MPI_REAL
>> types. The example however shows 1. Is this because as at when you send 2
>> types MPI transparently creates a new custom datatype (4.1.11) consisting of
>> these two elements and thus the top-entry is 1?
>>
>
> It returns 1 because the receiver side passed in "Type2" as 'datatype', and
> all of the data is received by a single instance of "Type2".  It would
> return 2 if instead line 13 passed "MPI_REAL" to MPI_Get_count.
>
>
> This, however should suggest that MPI_GET_COUNT always returns 1, or
>> MPI_UNDEFINED on an error (eg unmached receive count or type). Is this
>> correct?
>>
>
> No.  This is explained in a fairly precise way a little bit earlier in the
> section (4.1.11, pg 101).  The main discussion of type maps and type
> signatures is in section 4.1, pg 77.
>
>
> MPI_GET_ELEMENTS than receives what?
>>
>
> MPI_Get_elements returns the number of "basic elements" matched.  That is,
> things like MPI_REAL, MPI_CHAR, etc.  Derived datatypes are not basic types.
>  The main reason that this function is needed is because it is possible to
> receive less than (count*n) basic elements in a receive, where n is the
> number of (type,disp) pairs in the type map of the receive type.
>
>
> How is the example (4.12) even working correctly when a custom datatype
>> Type2 consists of two MPI_REALs and you want to receive two of those, eg 4
>> MPI_REALs?
>>
>
> 4.1.11 explains the matching rules for datatypes.  In particular, this
> paragraph might be helpful (pg 101, lines 39-42):
>
> ---------8<--------
> Type matching is defined according to the type signature of the
> corresponding datatypes,
> that is, the sequence of basic type components. Type matching does not
> depend on some
> aspects of the datatype definition, such as the displacements (layout in
> memory) or the
> intermediate types used.
> ---------8<--------
>
> So if you just take the sender and receiver datatypes, express them in
> terms of their type maps, and then compare them according to the rules of
> 4.1.11, you should be able to see whether they will match or not.
>
> If all of this still isn't clear after you take a look at those sections,
> please let me know.  I can cook up an example that might make it clearer.
>
> -Dave
>
>
> _______________________________________________
> mpich-discuss mailing list
> mpich-discuss at mcs.anl.gov
> https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss
>


Thank you very much for the clarifications. MPI_GET_ELEMENTS returns the
number of basic MPI datatypes (eg MPI::SHORT, MPI::BYTE, etc.) while
MPI_GET_COUNT the number of top-level elements. Eg if I ask for 2 MPI::REAL
GET_COUNT returns 2, while if I ask for Type2 (2 of type MPI_REAL),
GET_COUNT returns 1.

I have read and reread these sections at least a dozen times in the past few
days but the mixed usage of 'entries' (3.2.5) which gets renamed to
'top-level entries' (4.1.11) and 'datatype copies' and 'basic elements' -
'basic datatypes' doesn't really clear up things.

Example 4.12 is a good example but I think could use some explanation why
these actual values are returned. Although it might be me who is really slow
in understanding the specs :)

Thanks Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/mpich-discuss/attachments/20091216/d9b39424/attachment.htm>