need fortran 08 ts style interfaces

[hppritcha]

Open MPI doesn't currently define the "ts" fortran 08 interfaces added as part of MPI 3 errata.
See Item 18 in B.1.1 of the proposed MPI-3.1 standard, as well as MPI Forum trac item 388.

[jsquyres]

Specifically, see Table 17.1 in (the new) section 17.1.5 in MPI-3.1.

[hppritcha]

@ggouaillardet would you be interested in taking a look at this?

[hppritcha]

It may be that the only Fortran compiler that supports this feature is the Cray compiler. @ggouaillardet you may want to check if gfortran supports this feature. If it doesn't, feel free to unassign yourself.

[jsquyres]

@ggouaillardet We talked about this in the dev meeting. There's two main issues here:

1. I would really, really love it if the f08 bindings became generated instead of hard-coded. We have a set of perl data structures that break out the Fortran bindings (by type, parameter, etc. -- although, they may be missing some of the latest 3.0 and/or 3.1 functions...?); this is being used to generate many of the Fortran header files already. This could be expanded to also generate the bodies/implementations of the Fortran subroutines, too (although this is a non-trivial amount of work). This would make the whole Fortran implementation in Open MPI much more maintainable -- it would generate 3 bindings for exactly the one compiler that OMPI was configured with: mpif.h, use mpi, and use mpi_f08.
2. To implement the TS29113 interfaces, we can probably have logic like this:

void MPI_Send_f08_c_routine(void *buffer, ..., MPI_Datatype type, ...)
{
   if (is_fortran_dope_vector(buffer)) {
        void *new_buffer;
        MPI_Datatype new_type;
        ompi_convertor_merge(buffer, type, &new_buffer, &new_type)
        buffer = new_buffer;
        type = new_type; 
    }
   // ...the rest of the function
   // need some kind of magic to make sure the reference counting on
   // both type and new_type is correct
}

The function ompi_convertor_merge() does not exist -- you will likely need to write it and/or work with @bosilca. It would take the Fortran dope vector and apply the MPI datatype to it, and output a new base pointer and MPI datatype that represents the memory layout. This new base/type can then be passed to all the underlying OMPI infrastructure (PMLs, collectives, ...etc.) just like any other base/type passed in via C MPI functions, etc.

[jsquyres]

Per http://lists.mpi-forum.org/mpiwg-fortran/2015/06/1665.php, it looks like gfortran 5.0 doesn't yet support this. Intel Fortran v16 will, though (the public beta of which is ending soon).

[ggouaillardet]

i can have a look at it

@jsquyres could you please send me some more pointers ?

the only perl script i could find was gen-mpi-sizeof.pl :-(
also, which files would you like to be automatically generated ?

• ./mpif-h/prototypes_mpi.h ?
  • ./use-mpi-f08-desc/mpi-f-interfaces-bind.h ?
• ./use-mpi-f08/mpi-f-interfaces-bind.h ?
• others ?

[jsquyres]

Meh! It looks like this was on a branch that I never released... checking...

Ah, I found it -- the work wasn't done in the OMPI tree. It was originally done on Craig and Soren Rasmussen's bitbucket for Fortran<-->C interop stuff (https://bitbucket.org/SorenRasmussen/pyofp). I/Jeff did a bunch of local commits and never pushed them anywhere to use Craig/Soren's stuff to generate the header files for Open MPI's Fortran bindings. But I never pushed those commits anywhere. I also stopped after generating the header files -- it doesn't generate any of the Fortran implementation.

It looks like Craig/Soren's tree eventually moved to Github (https://github.com/OpenFortranProject/ofp-sdf). So I just forked it on Github, added the "jsquyres" tree that I had in their old Mercurial repo that contained the work that I did, and pushed it to my Github fork (https://github.com/jsquyres/ofp-sdf).

So here's what's at the jsquyres fork:

• I don't know what the status is of the ofp-sdf project is. It looks like it advanced significantly after leaving bitbucket.
• All the work that I did is self-contained in the jsquyres/ directory. I was simply trying to use their work to generate OMPI Fortran bindings -- in Perl, not Python (all their work is in Python). Hence, I think the jsquyres directory might be fully self-contained...?
• The scripts that are in the jsquyres/ directory might be a good starting point for actual code generation for the OMPI Fortran bindings. I'm sure it still requires a good bit of work, though.

[ggouaillardet]

thanks Jeff,

your directory is self contained :-)
I had to refresh some constant values.
I will focus on the f08 part from now.
the most painful part will be to add all the bindings since there are just a few right now.

btw, I got limited access to a cray with cray compilers, so I can fully investigate this :-)

[jsquyres]

Sweet!

[ggouaillardet]

i worked on the automatic generation of f08 bindings.
my branch is at https://github.com/ggouaillardet/ompi/tree/poc/new_fortran_bindings

right now :

• f08 interfaces are automatically generated
• most f08 subroutines are automatically generated
• the script is still invoked from autogen.pl, and it should be invoked in configure
• when the script is invoked from configure, the appropriate pragma should be used

[jsquyres]

That sounds sweet!

I agree -- the script should be invoked from configure. It can then use the results from configure (e.g., what aspects of Fortran are supported); this will allow us to get rid of many #defines -- i.e., we emit Fortran that precisely matches what the configure-determined Fortran compiler can support.

[hppritcha]

closing this issue. Will open issues per comments above.