[MPI3 Fortran] Results of San Jose Forum meeting

[Jeff Squyres]

On Mar 11, 2010, at 9:41 AM, N.M. Maclaren wrote:

> > There certainly is an elegance to having no MPI handle conversion
> > functions between use mpi/use mpi3/mpif.h. It would have been nice to
> > avoid the lookup, but a) the cost really doesn't matter, and b) I think
> > the usability issue is nice (i.e., assignment), even if none of the other
> > benefits work out. But I'm not tied strongly to either way.
> 
> I don't find that having to define the internals of a derived type any
> more elegant than defining two functions (or a single subroutine).

It's not 2 functions/1 subroutine -- it's probably twice that because there's now 3 types of handles:

- mpif.h / use mpi: INTEGER
- use mpi3: some derived type
- C

Keeping the underlying Fortran handle type as INTEGER was simple, but encasing it in a derived type provided the type safety.  Additionally, Rolf thought that using SEQUENCE with no other fields might allow us to have 2 interface files but one back-end implementation for both the mpi and mpi3 modules.

Per a prior question on this thread, the thought was to use BIND(C) to bind both routines to a back-end C routine, but still have an INTEGER type for the member so that Fortran codes could do the assignment from mpif.h/use mpi handles with no funky casting.  The C function would then simply ensure to use a C integer type that was compatible with INTEGER (Open MPI, for example, uses configure tests to setup MPI_Fint to be the Right size).  Then the C routine would do the lookup on the INTEGER (MPI_Fint) to get the appropriate C MPI handle and then go on from there.

-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/