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
_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
