On Mar 6, 2008, at 4:33 PM, Harald Klimach wrote:

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.

w00t. I wouldn't have know that that was what it was called. :-)

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.

It did not work for us to *only* provide (*); we found that we had to list all the dimensions. Here's a relatively simple example that shows the problem with both gfortran and ifort on my system: ------------------ [17:23] svbu-mpi:~/tmp/f90 % cat module.f90 module my_function_module interface my_function subroutine my_function_scalar(arg) integer, intent(in) :: arg end subroutine my_function_scalar subroutine my_function_1d(arg) integer, dimension(*), intent(in) :: arg end subroutine my_function_1d end interface my_function end module my_function_module [17:23] svbu-mpi:~/tmp/f90 % gfortran -c module.f90 [17:23] svbu-mpi:~/tmp/f90 % cat arrays.f90 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Subroutines !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! subroutine my_function_scalar(arg) implicit none integer, intent(in) :: arg print *, "This is the scalar my_function" end subroutine my_function_scalar subroutine my_function_1d(arg) implicit none integer, dimension(*), intent(in) :: arg print *, "This is the 1d my_function" end subroutine my_function_1d !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! All good. Now try to use them !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! program f90_is_confusing use my_function_module implicit none integer :: a integer, dimension(1) :: b integer, dimension(2,3) :: c call my_function(a) call my_function(b) call my_function(c) end program f90_is_confusing [17:23] svbu-mpi:~/tmp/f90 % gfortran arrays.f90 -I. In file arrays.f90:28 call my_function(c) 1 Error: Generic subroutine 'my_function' at (1) is not an intrinsic subroutine [17:23] svbu-mpi:~/tmp/f90 % ------------------ So it didn't allow calling my_function with a 2D array (c). Just to make sure this is not a gfortran weird-ism, I tried compiling the same stuff with ifort: ------------------ [17:23] svbu-mpi:~/tmp/f90 % ifort --version ifort (IFORT) 10.1 20071116 Copyright (C) 1985-2007 Intel Corporation. All rights reserved. [17:23] svbu-mpi:~/tmp/f90 % ifort module.f90 -c [17:23] svbu-mpi:~/tmp/f90 % ifort arrays.f90 -I. fortcom: Error: arrays.f90, line 28: There is no matching specific subroutine for this generic subroutine call. [MY_FUNCTION] call my_function(c) -------^ compilation aborted for arrays.f90 (code 1) [17:23] svbu-mpi:~/tmp/f90 % ------------------- This is why we have all the dimensions explicitly specified in Open MPI.

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

I think we were just covering all possible bases with MPI_BUFFER_ATTACH -- you *could* specify a buffer of size 1. But s/ MPI_BUFFER_ATTACH/MPI_SEND/ and the issue is the same (i.e., it does make sense to pass a scalar to MPI_SEND).

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 ;)

Either way, the back-end C function gets a pointer. So I think we were likely a) going above and beyond the spec, and b) fitting MPI_BUFFER_ATTACH into the same OMPI F90 infrastructure as everything else.

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.

But the type is variable, right? Hence, if you use an explicit size, the *real* size of the buffer (in bytes) is sizeof(type)*size. The "size" parameter is supposed to be specified in bytes, not increments of type size. So I don't think the above binding would yield correct results for non-character types. Right?

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.

Actually, MPI explicitly allows you to mix-n-match the types. :-\

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?

It's unfortunately not for us to say; the standard allows it, so we have to allow it (because *some* app out there is likely using it in a weird-o way that is valid for their situation). Certainly, there are cases that are non-sensical (e.g., sending its and receiving floats), but you *could* send complexes and receive twice as many floats, and that would be fine. -- Jeff Squyres Cisco Systems