[MPI3 Fortran] MPI-2.1: Fortran 90 bindings

[Harald Klimach]

OK, sorry I should have done this earlier!
I just had a look into openmpi, and how it's done there, and found,
that there already assumed size is used.
Looking at the standard I found it is also everywhere talking of assumed
size only.
For example in openmpi-1.2.5/ompi/mpi/f90/mpi_buffer_attach_f90.f90.sh
a construct like this is used:
for rank in $allranks
do
  case "$rank" in  0)  dim=''  ;  esac
  case "$rank" in  1)  dim=', dimension(*)'  ;  esac
  case "$rank" in  2)  dim=', dimension(1,*)'  ;  esac
  case "$rank" in  3)  dim=', dimension(1,1,*)'  ;  esac
  case "$rank" in  4)  dim=', dimension(1,1,1,*)'  ;  esac
  case "$rank" in  5)  dim=', dimension(1,1,1,1,*)'  ;  esac
  case "$rank" in  6)  dim=', dimension(1,1,1,1,1,*)'  ;  esac
  case "$rank" in  7)  dim=', dimension(1,1,1,1,1,1,*)'  ;  esac

The only 2 meaningful options are the first two. $rank = 0 provides the
possibility to provide the routine with a scalar. $rank = 1 enables the
routine to take an array of any rank.
The rest is just not needed. At least to my understanding.

I would even doubt, that the first option is really necessary, as the
standard states buffer for MPI_BUFFER_ATTACH to be:
<type> BUFFER(*)
To my reading that would mean it has to be an array. From the options
above $rank = 1 would then be the only one, that is really needed. The
MPI-2 standard is talking about this issue on page 285 in the paragraph
"Problems Due to Strong Typing". As I read it, it is expected to only
use the array. The user can always just use an array of size 1.
However it is very convenient to just put the scalar in the argument
list ;)
So it certainly is a nice thing to have the additional interface (but
requires to double the work by the implementor).

Actually you could even an explicit shape array:
subroutine MPI_BUFFER_ATTACH(buffer, size, ierror)
  integer :: size, iError
  integer :: buffer(size)
end subroutine MPI_BUFFER_ATTACH

and call it with any integer array, that fits into size. Just try it
with the sample program I sent in my first mail ;). This would ensure
that the actual argument for buffer isn't larger than size.

Regarding the functions with two choice parameters:
Is there any function which actually would make it necessary to allow
two different types?
By a brief glance at the standard, I only found constructs like in
MPI_Allreduce:

MPI_ALLREDUCE(sendbuf, recvbuf, count, datatype, op, comm, ierror)
<type> sendbuf(*), recvbuf(*)
integer count, datatype, op, comm, ierror

To my understanding this means, that sendbuf and recvbuf have to of the
same type. It won't make any sense in the programs logic otherwise
anyway.
If they are really allowed to be of different types, I would expect
them to be on two lines:
<type> sendbuf(*)
<type> recvbuf(*)
But perhaps that's just a bad interpretation by me.

No Fortran program should want to get different typed values then it
sent.

Are there really any MPI functions, where it is sensible to use two
different types for the two choice parameters?

Otherwise a thousand interfaces would be sufficient (just one logical
from your list: 12*75 = 900, all logicals from your list: 15*75 = 1125)
for the current MPI-Standard, as it is.
Maybe a clarification could be useful for the case of two choice
parameters, but maybe this is already clearly specified in the standard
somewhere.

Kind regards,
Harald

-- 
Dipl.-Ing. Harald Klimach  email: klimach at hlrs.de
HLRS, Uni Stuttgart        http://www.hlrs.de/people/klimach
Nobelstraße 19             phone: 0711-685 60300
70569 Stuttgart            fax:   0711-685 65832