On Dec 8, 2015, at 7:02 PM, Jeff Squyres (jsquyres) <[email protected]> wrote:

On Dec 8, 2015, at 2:44 PM, Bill Long <[email protected]> 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 [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

_______________________________________________ mpiwg-fortran mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran

Bill Long [email protected] 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