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:43:29

What's the source code in question, then? Did you match all the

On Sep 22, 2008, at 8:36 PM, Brian Harker wrote:

> Nope, no user-defined types or arrays greater than 2 dimensions.
> On Mon, Sep 22, 2008 at 6:24 PM, Jeff Squyres <jsquyres_at_[hidden]>
> wrote:
>> 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
>> 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
>> _______________________________________________
>> users mailing list
>> users_at_[hidden]
> --
> Cheers,
> Brian
> brian.harker_at_[hidden]
> "In science, there is only physics; all the rest is stamp-collecting."
> -Ernest Rutherford
> _______________________________________________
> users mailing list
> users_at_[hidden]

Jeff Squyres
Cisco Systems