On Sep 22, 2008, at 6:48 PM, Brian Harker wrote:

when I compile my production code, I get:

fortcom: Error: driver.f90: line 211: There is no matching specific
subroutine for this generic subroutine call.   [MPI_SEND]

Seems odd that it would spit up on MPI_SEND, but has no problem with
MPI_RECV...  What do you guys think?  And thanks again for your help
and patience?

The F90 MPI bindings have some well-known design flaws (i.e., problems with the standard itself, not any particular implementation). Many of them center around the fact that F90 is a strongly-typed language. See this paper for some details:

    http://www.open-mpi.org/papers/euro-pvmmpi-2005-fortran/

Here's the highlights, as they pertain to writing F90 MPI apps:

- There is no equivalent to C's (void*). This means that the F90 MPI bindings cannot accept user-defined datatypes.

- This also means that *every* pre-defined type must have a F90 MPI binding. There are approximately 15 intrinsic size/type combinations. There are 50 MPI functions that take one choice buffer (e.g., MPI_SEND, etc.), and 25 functions that take two choice buffers (e.g., MPI_REDUCE). I'm copying this math from the paper, and I think we got it slightly wrong (there was a discussion about it on this list a while ago), but it results in many *millions* of F90 MPI bindings functions. There's no compiler on the planet than can handle all of these in a single F90 module.

Open MPI compensates for this with the following:

- F90 bindings are not created for any of the 2-choice-buffer functions
- F90 bindings are created for all the 1-choice-buffer functions, but only for dimensions up to N dimensions (N defaults to 4, IIRC). You can change the value of N with OMPI's configure script; use the --with- f90-max-array-dim. The maximum value of N is 7.

So -- your app failed to compile because you either used a user- defined datatype or you used an array with a dimension greater than 4. If it was a greater-dimension issue, you can reconfigure/recompile/ reinstall OMPI (again, sorry) with a larger N value. If it was a user- defined datatype, you unfortunately have to "include mpif.h" in that subroutine/function/whatever, sorry (and you lose the type checking). :-(

Here's some info from OMPI's README:

-----
- The Fortran 90 MPI bindings can now be built in one of three sizes
  using --with-mpi-f90-size=SIZE (see description below).  These sizes
  reflect the number of MPI functions included in the "mpi" Fortran 90
  module and therefore which functions will be subject to strict type
  checking.  All functions not included in the Fortran 90 module can
  still be invoked from F90 applications, but will fall back to
  Fortran-77 style checking (i.e., little/none).

  - trivial: Only includes F90-specific functions from MPI-2.  This
    means overloaded versions of MPI_SIZEOF for all the MPI-supported
    F90 intrinsic types.

  - small (default): All the functions in "trivial" plus all MPI
    functions that take no choice buffers (meaning buffers that are
    specified by the user and are of type (void*) in the C bindings --
    generally buffers specified for message passing).  Hence,
    functions like MPI_COMM_RANK are included, but functions like
    MPI_SEND are not.

  - medium: All the functions in "small" plus all MPI functions that
    take one choice buffer (e.g., MPI_SEND, MPI_RECV, ...).  All
    one-choice-buffer functions have overloaded variants for each of
    the MPI-supported Fortran intrinsic types up to the number of
    dimensions specified by --with-f90-max-array-dim (default value is
    4).

  Increasing the size of the F90 module (in order from trivial, small,
  and medium) will generally increase the length of time required to
  compile user MPI applications.  Specifically, "trivial"- and
  "small"-sized F90 modules generally allow user MPI applications to
  be compiled fairly quickly but lose type safety for all MPI
  functions with choice buffers.  "medium"-sized F90 modules generally
  take longer to compile user applications but provide greater type
  safety for MPI functions.

  Note that MPI functions with two choice buffers (e.g., MPI_GATHER)
  are not currently included in Open MPI's F90 interface.  Calls to
  these functions will automatically fall through to Open MPI's F77
  interface.  A "large" size that includes the two choice buffer MPI
  functions is possible in future versions of Open MPI.
-----

FWIW, we're arguing^H^H^H^H^H^H^Hdiscussing new Fortran 2003 bindings for MPI in the MPI-3 Forum right now. We have already addressed the problems discussed above (F03 now has an equivalent of (void*)), and hope to do a few more minor things as well. There's also discussion of the possibility of a Boost.MPI-like Fortran 2003 MPI library that would take advantage of many of the features of the language, but be a little farther away from the official MPI bindings (see www.boost-org for details about how their nifty C++ library works on top of MPI).

--
Jeff Squyres
Cisco Systems

Reply via email to