[MPI3 Fortran] MPI-2.1: Fortran 90 bindings

[Harald Klimach]

Hi,
> 
> Assuming the compiler supports CHARACTER, LOGICAL{1,2,4,8},  
> INTEGER{1,2,4,8},
> REAL{4,8,16}, and COMPLEX{8,16,32}.
Fine, thank you. I think we can assume one kind of logical is
sufficient. I never ran across different kinds of logicals.

> Keep in mind that we cannot make huge changes to the existing MPI F90  
> bindings.  They're more-or-less set in stone.  What we can do is  
> deprecate them in favor of newer, better bindings (E.g., stuff that  
> takes advantage of more modern Fortran features, such as the C-to- 
> Fortran interoperability compiler features).  That's going on for MPI-3.
The standard doesn't state anything about assumed shape/assumed size as
far as I know. This is just a implementation detail.
You could say, assumed size is the F77 way to do it. But as it is part
of the F90 standard it is usable through explicit interfaces, so you
don't loose the type checking and key words for parameters.

> My goal in posting this morning was the see if we could do a very  
> minor fix for MPI-2.1 to make the existing MPI F90 bindings  
> implementable.  My point: I don't know if we can change from assumed  
> shape to assumed size for MPI-2.1.  Possibly for MPI-2.2...?  (MPI-2.2  
> is allowed to have small changes that require a little implementation  
> effort)
I just wanted to point out, that there may be no need for as many
interfaces as you summed up in your posting. I think the number of
necessary interfaces for the functions with 2 choice parameters is
embarrasing large, but as you said around 6000 may be doable, so there
may not even be the need to change anything in the standard.

> 
> I think I would need to understand much better what this change would  
> mean:
> 
> - for existing MPI F90 applications
The user shouldn't see any difference.

> - for existing MPI F90 implementations
If the implementation uses assumed shape it has to provide something
like this:
MPI_BUFFER_ATTACH1_TYPE(buffer, size, ierror)
   type :: buffer(:)
   integer :: size, ierror

MPI_BUFFER_ATTACH2_TYPE(buffer, size, ierror)
   type :: buffer(:,:)
   integer :: size, ierror

MPI_BUFFER_ATTACH3_TYPE(buffer, size, ierror)
   type :: buffer(:,:,:)
   integer :: size, ierror

MPI_BUFFER_ATTACH4_TYPE(buffer, size, ierror)
   type :: buffer(:,:,:,:)
   integer :: size, ierror

MPI_BUFFER_ATTACH5_TYPE(buffer, size, ierror)
   type :: buffer(:,:,:,:,:)
   integer :: size, ierror

MPI_BUFFER_ATTACH6_TYPE(buffer, size, ierror)
   type :: buffer(:,:,:,:,:,:)
   integer :: size, ierror

MPI_BUFFER_ATTACH7_TYPE(buffer, size, ierror)
   type :: buffer(:,:,:,:,:,:,:)
   integer :: size, ierror

INTERFACE MPI_BUFFER_ATTACH
  module procedure MPI_BUFFER_ATTACH1_TYPE
  module procedure MPI_BUFFER_ATTACH2_TYPE
  module procedure MPI_BUFFER_ATTACH3_TYPE
  module procedure MPI_BUFFER_ATTACH4_TYPE
  module procedure MPI_BUFFER_ATTACH5_TYPE
  module procedure MPI_BUFFER_ATTACH6_TYPE
  module procedure MPI_BUFFER_ATTACH7_TYPE
  ...
  other types
END INTERFACE


With assumed shape you just have to do:

MPI_BUFFER_ATTACH_TYPE(buffer, size, ierror)
  type, dimension(*) :: buffer
  integer :: size, ierror

INTERFACE MPI_BUFFER_ATTACH
  module procedure MPI_BUFFER_ATTACH_TYPE
  ...
  other types
END INTERFACE

I don't really know, but I can't see any reason for the implementation
to use the assumed shape here, as the buffer normally just has to be
handed over to the C-Function.

> - for the MPI-2.x standard
It doesn't mean anything for the MPI-2.x standard.

> 
> This is probably worth discussing on the teleconference tomorrow.
I can't participate in the conference, sorry.


> This is probably something I don't understand well in Fortran; the  
> goal is to be able to pass any intrinsic type of any array shape/size/ 
> whatever through the "choice" MPI buffers (e.g., the buffer argument  
> to MPI_SEND).  If we can reduce the number of subroutine signatures to  
> 750 from 5250, that's a good thing (but may be a moot point, per above).
By using assumed size, you don't have to care about the shape or the
size anymore, what's left is the type.

> 
> > If this is the case we would "only" have 15^2 * 25 = 5625 interfaces
> > for functions with two choice buffers.
> 
> 
> That's predicated on whether we can change the F90 bindings to use  
> assumed size, right?
> 
Yes, but as said, this is a mere implementation detail, the standard
doesn't state anything about how this.
Every implementor is free to spent as much (unnecessary) effort as he
likes to, as long as the interface for the user looks, like specified
in the standard, right?

I hope this helps a little bit to clarify some of the issues,
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