[MPI3 Fortran] MPI-2.1: Fortran 90 bindings
jsquyres at cisco.com
Fri Mar 14 19:15:08 CDT 2008
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
> 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
More information about the mpiwg-fortran