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