[mpich-discuss] MPI_GET_COUNT behaviour unclear

[Dave Goodell]

[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