Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

Subject: Re: [OMPI users] Configure and Build ok, but mpi module not recognized?
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2008-09-22 20:24:37

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:

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

   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