[MPI3 Fortran] MPI Data types

[Hubert Ritzdorf]

The function CFI_is_contiguous() is what Jeff was referencing to the last
Chicago meeting. cdesc->elem_len doesn't help the MPI programmer
since there is a special constant (MPI_BOTTOM) and other
possibilities to construct the MPI datatype. I think, there are
4 possibilities in case of an MPI_Send/MPI_Isend:

(1) CFI_is_contiguous() returns isContiguous == true and
     MPI datatype is contiguous:
     MPI uses cdesc->base_add and sends count elements of
     the MPI datatype.
(2) CFI_is_contiguous() returns isContiguous == true and
     MPI datatype is NOT contiguous:
     MPI uses address cdesc->base_add  and sends count elements of
     the MPI datatype.
(3) CFI_is_contiguous() returns isContiguous == false and
     MPI datatype is contiguous:
     MPI uses the the cdesc description ( including cdesc->base_add and
     cdesc->elem_len) in order to pack count data elements of the 
non-contiguous
     Fortran array (similar to a Fortran copy-in; of course MPI can do
     this  packing on the fly).
     This would be backward compatible to behaviour
     of actual Fortran 90 compilers.
(4) CFI_is_contiguous() returns isContiguous == false and
     MPI datatype is non-contiguous:
     This is the tricky part:
     (a) If MPI should be compatible to actual Fortran 90 compiler,
          it must simulate the packing (copy in) and apply the
          non-contiguous MPI datatype, to the packed buffer.
          This corresponds to (3).
     (b) Otherwise, handle the buffer and the MPI datatype
          such as in (2).

Hubert
          

Craig Rasmussen wrote:
> I'll try to be gentle to you C folk (except for Jeff  of course :-)
>
> The MPI implementation will get an array descriptor instead of _just_ 
> a pointer.  Consider a simple MPI_send,
>
> void MPI_send(CFI_desc_t * cdesc, int count, int * error)
> {
>    void * addr = cdesc->base_add;  /* this is the normal address C 
> expects (given some qualifications) */
>
>    /* now for some example error checking code, not real code */
>
>   assert(cdesc->type == the_right_MPI_type_given_by_the_user);
>
>   CFI_is_contiguous(cdesc, &isContiguous);  /* this function supplied 
> by Fortran compiler */
>   assert(isContiguous);
>
>   assert(MPI_lib_actual_size(cdesc) >= count*cdesc->elem_len);  /* 
> this function supplied by MPI library */
>
>   addr = MPI_lib_actual_addr_start(cdesc);  /* this function supplied 
> by MPI library */
>
>   /* now can send data */
>
>   *error = ...
> }
>
>
> On May 7, 2009, at 10:54 AM, N.M. Maclaren wrote:
>
>> On May 7 2009, Jeff Squyres wrote:
>>>
>>> I don't understand the implications of what you are saying.  Be 
>>> gentle  with me; I'm *NOT* a Fortran expert (or anywhere close).
>>
>> Sorry.
>>
>> C's array model is confused, but the issue is its semantic aspect.  A C
>> array is simply a pointer to the first element of a contiguous sequence
>> of an unspecified number of elements.  Nothing more.  A void * pointer
>> is the first byte of an unspecified length of storage of unspecified
>> type.  It is assumed that it is of appropriate alignment and size for 
>> how
>> it is used, but that information is not associated with an array 
>> argument.
>>
>> A Fortran array is strongly typed (the first difference), and it 
>> comes in
>> many forms.  Most of them are contiguous, but the most important 
>> Fortran 90
>> one (plain assumed size) is not.  All but assumed shape (a Fortran 77
>> feature) have a strongly associated size.  It is the user's 
>> responsibility
>> to never pass a smaller array to a largerr argument.
>>
>> Pretty well all combinations are allowed in argument passing, and the
>> compiler is expected to use copy-in/copy-out when needed.  In 
>> particular,
>> it is needed (in general) when passing an assumed-shape array to an 
>> assumed
>> size argument (which is the form that matches C's model).  That can be
>> locked out, but that means that callers cannot use assumed shape arrays,
>> which (as I said) are the main Fortran 90 mechanism.
>>
>>>> I thought that we were discussing features to enable MPI-3 to  
>>>> support things
>>>> like Fortran array arguments that have no equivalent in C (principally
>>>> assumed shape).
>>>
>>> I don't understand.  What does it matter if there is no equivalent  
>>> data type in C?
>>
>> Not data type - semantic model.
>>
>>> MPI is about message passing -- as long as we can get a memory 
>>> layout  description of the data to send / receive, then it doesn't 
>>> matter what  language the data will be accessed from.
>>
>> Yes, but ....
>>
>> The data layout is part of the MPI datatype, so there is a problem when
>> passing a Fortran 90 assumed shape REAL array (for example).  If the MPI
>> datatype is REAL, the MPI send / receive needs to handle discontiguous
>> data (which it doesn't).  If the MPI datatype is an MPI derived type, 
>> there
>> is no direct equivalence between the Fortran and C interfaces.
>>
>>
>> Regards,
>> Nick Maclaren,
>> University of Cambridge Computing Service,
>> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
>> Email:  nmm1 at cam.ac.uk
>> Tel.:  +44 1223 334761    Fax:  +44 1223 334679
>>
>>
>>
>> _______________________________________________
>> mpi3-fortran mailing list
>> mpi3-fortran at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran
>
> _______________________________________________
> mpi3-fortran mailing list
> mpi3-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-fortran/attachments/20090507/4bf050f5/attachment-0001.bin>