[MPI3 Fortran] MPI-2.1: Fortran 90 bindings

[Jeff Squyres]

On Mar 10, 2008, at 1:26 PM, Harald Klimach wrote:

>>>> Not really.  You could send N COMPLEX items and receive N*2 REAL
>> items.  You can get more creative with C structs and Fortran derived
>> types, with the already-mentioned restriction that you might (* see
>> below) have to fall back to the F77 bindings for Fortran derived  
>> types.
>
> I thought we were talking about basic datatypes only. You obviously
> can't provide explicit interfaces with type checking for all possible
> Fortran derived types.

We might be running into terminology issues here: MPI has COMPLEX as  
an intrinsic datatype (meaning that it's natively supported by MPI).   
That's what I meant.

Regardless: the rule is that what you send in MPI must have an  
equivalent type map on the receiver, but the specific datatypes do not  
have to be the same.  I agree that without user-defined MPI datatypes  
(since at least OMPI's current F90 implementation doesn't allow  
arbitrary derived types in the choice buffer arguments without falling  
back to the F77 bindings), this severely restricts the cases where  
datatypes do not match (more importantly, where the types of the  
choice buffer do not match) but type maps do.  If derived types are  
allowed in the choice buffers, it gets more complicated (see below),  
and it's impossible to make a finite listing of overloaded functions.

In Chicago this week, we pretty much decided that for the F90  
bindings, almost every F90 compiler (if not all of them?) has a  
"void*"-like extension to ignore the type of a given parameter, and  
that might be good enough for current MPI implementations.  It's bad  
for the MPI standard to rely on compiler extensions, but it does at  
least make the current F90 bindings salvageable.

> I thought compatible type maps require you to have the same basic
> types, and if it is allowed to change basic types from sender to
> receiver I'm wondering what MPI1 3.3.1 is talking about, when it says:
> Communication of typed values (e.g., with datatype different from
> MPI_BYTE), where the datatypes of the corresponding entries in the
> sender program, in the send call, in the receive call and in the
> receiver program must all match.


There are two main cases where this can occur:

1. C structs / F90 derived types where you could conceivably have two  
different datatypes with the same type map (or some combination of  
datatypes -- possibly even with N instances of datatype A and M  
instances of different datatype B, where N != M).

2. Using the various datatype pattern constructors to build datatypes  
with "holes" in them, but have the same number of data items.  E.g.,  
one datatype with 100 doubles, skipping every other one, and a 2nd  
datatype with 100 doubles, but skipping every two.  Here's a wonky  
example: you could use MPI_SENDRECV to effect a memcpy in a single  
process from one memory pattern (datatype) to a different memory  
pattern (datatype).

-- 
Jeff Squyres
Cisco Systems