[MPIWG Fortran] F08 and pair types?

[Bill Long]

On Dec 8, 2015, at 7:02 PM, Jeff Squyres (jsquyres) <jsquyres at cisco.com> wrote:

> On Dec 8, 2015, at 2:44 PM, Bill Long <longb at cray.com> wrote:
>> 
>> 
>>> and goes on to define an MPI Datatype that is a C float followed immediately in memory by a C int.  So the MPI standard actually defines a memory representation rather than a C struct.
>> 
>> How do you handle  MPI_SHORT_INT?  A short immediately followed in memory by an int will cause the int to have bad memory alignment. 
> 
> Right.  MPI knows this; MPI_SHORT_INT will include padding between the SHORT and INT if it needs to.
> 
>> Was it the case that the starting point for the rules was the SEQUENCE type in Fortran (which might have been the only option at the time) and then force C to conform?   Today it is easier to get Fortran to mimic what is natural for C. 
> 
> There are two issues here:
> 
> 1. The "good" MPI datatype name of MPI_2INTEGER is already being used; it currently means "INTEGER foo(2)".  We want to update it to mean a derived type that contains 2 INTEGERs and still be able to use the MPI datatype name "MPI_2INTEGER" without breaking existing codes.

As I understand the high-level situation, this is all for MPI_REDUCE and friends, and MPI_2INTEGER and MPI_MINLOC or MPI_MAXLOC are all just magic constants that the MPI_REDUCE routine internally decodes to determine what to do.  The actual data, the in and out arguments of MPI_REDUCE, are choice arguments (void *). 

Current codes have the actual argument IN declared as INTEGER :: IN (2, K) where K is the number of things in the list to be reduced. IN(1,*) is the “VAL" value, and IN(2,*) is the “LOC” value.  Since the corresponding dummy argument is (void *) you can pass any actual type, since only the memory layout matters. 

> 
> I hear you that SEQUENCE is considered bad programming/style.  Is having the equivalence between INTEGER foo(2) and a derived type with 2 INTEGERs do-able without using SEQUENCE?

If the above is correct, then the following declarations would have the same memory layouts for the actual arguments:

INTEGER :: IN(2, K)

and

TYPE MPI_2INTEGER_TYPE
    SEQUENCE
    INTEGER :: VAL
    INTEGER :: LOC
END TYPE

TYPE(MPI_2INTEGER_TYPE) :: IN(K)

This seems like sugar coating for the 2INTEGER case. 


But, the following would likely not be equivalent:

DOUBLE PRECISION :: IN(2, K)

and

TYPE MPI_DOUBLE_INT_TYPE
   SEQUENCE
   DOUBLE PRECISION :: VAL
   INTEGER :: LOC
END TYPE

TYPE(MPI_DOUBLE_INT_TYPE) :: IN(K)

since the IN(1:2, n) section of the current IN array will have 2 doubles, or 16 bytes in most cases.  One element of the new IN would have only 12 bytes.  If K is > 1, there is potential for trouble.   Certainly no guarantee from the Fortran standard.

The standard does require that INTEGER and REAL (both default) as part of a SEQUENCE type are the same size in memory, so the MPI_REAL_INT_TYPE version would seem to be OK. 


> 
> 2. I wasn't looking to emulate the C types in Fortran -- I think we've had this discussion before.  The intent is to have Fortran-native types (that would be natural for Fortran programmers).

I think BIND(C) is “natural” for Fortran programmers these days.  This stuff has been around for over a decade.  The use of “DOUBLE PRECISION” is far less natural these days.  Essentially everyone has switched to REAL(KIND= ) instead.  That stuff is 25 years old. 

Cheers,
Bill


>  I might not have been clear when I said "parity with the C types" -- what I meant was having "Fortran-natural equivalents of the 6 C MPI_Datatypes".
> 
> Make sense?
> 
> -- 
> Jeff Squyres
> jsquyres at cisco.com
> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> _______________________________________________
> mpiwg-fortran mailing list
> mpiwg-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran

Bill Long                                                                       longb at cray.com
Fortran Technical Support  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101