On Mar 8, 2008, at 2:03 AM, Harald Klimach wrote:

...

It is required that the send and receive buffers have compatible type maps. See MPI-1:4.1:

Note that this is the only requirement -- compatible type *maps*. Not compatible *types*.

So this is about derived types? I don't think it is possible to catch derived types within the scope of F90, you have to fall back to the implicit F77 interface for this anyway. Even so, as you said compatible type maps are required, which means, as far as I understand it, that there are the same base types on each side. Looking at MPI-1: 3.3: "Data type matching and data conversion", I even think it is required that the two arguments are of the same type.

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.

Observations so far: It would be very nice, if Fortran would allow the assumed size notation in a generic interface to consume all ranks.

It was pointed out on the call on Friday that most F90 compilers have some kind of directive that effectively allows a Fortran subroutine/ function parameter to be the equivalent of C's (void*), thereby making much of this conversation moot. We were going to investigate this a bit more deeply; this option was not [widely] available when MPI-2 was written (nor when the Rasmussen/Squyres paper was written a few years ago).

Which would mean that you'd have to use assumed shape arrays if you want to explicitly use different routines for different ranks and both options would be mutually exclusive.

I think the MPI standard really prohibits different types in the case where there are 2 choice arguments.

Per above, I disagree. :-)

I can't find anywhere in the standard where it is required that arrays of all ranks are allowed to be passed as actual arguments. But I can't find where it states that scalars are allowed either and in MPI-2 it is explicitly stated that this is an inconsistency of MPI with F90. Both things (scalars and arrays of different ranks) are rather a observed behaviour of the F77 binding, which comes from the implicit interfaces. Maybe the F90 binding shouldn't exactly rebuild the behaviour of the F77 binding?

This is a point that was explicitly brought up when designing the C++ bindings (that perhaps the C++ bindings should not be effectively a 1- to-1 mapping of the C bindings). The Forum overwhelmingly decided to keep them simple and pretty much the same as the C bindings (they do take advantage of a small number of C++ language features, to be more natural to the C++ developer community). The rationale is that if you design an alternate set of bindings, it is effectively a new and different standard that requires its own, separate maintenance, and require a potentially substantially different implementation (than the C bindings).

Having to use only arrays of rank 1 certainly is quite inconvinient for the user, but I don't see where it is required by the standard to support all ranks in the F90 binding.

Open MPI defaults to supporting scalar plus ranks 1-4; you can change this with a configure argument when building Open MPI. We did this because we noticed that in some compilers, supporting 5-7 ranks made compilation of F90 MPI apps "slow" (and users complained). We found "4" to be a "sweet spot". But we had to offer the *possibility* of all 7 for anyone who wanted it.

To allow scalars and all ranks for all types I think in total there are 8 * 15 * 75 = 9000 subroutines needed.

If you restrict yourself to the types, that are at least required by MPI (MPI-1: 3.2.2) and don't support any other ranks besides rank 1, you're down at: 6*75 = 825 subroutines.

Based on my disagreements above, I think the above formulae are incorrect.

In MPI-2 Page 13 Line 33 it says: All MPI names have an MPI_ prefix, and all characters are capitals. However this statement "and all characters are capitals" hasn't any meaning in the Fortran context, right?

My understanding (and I'll repeat again: I'm nowhere near a fortran expert) is that fortran compilers will change subroutine/function/ variable symbols to either all upper case or all lower case (possibly with some additional underscores). I don't know if this is a Fortran standard thing (e.g., if the Fortran standard says that symbols are case-insensitive), or whether it's an implementation thing. -- Jeff Squyres Cisco Systems