BTW, thanks for hanging in there with me on this guys. I appreciate your time and input.
On Mon, Sep 22, 2008 at 6:36 PM, Brian Harker <brian.har...@gmail.com> wrote: > Nope, no user-defined types or arrays greater than 2 dimensions. > > On Mon, Sep 22, 2008 at 6:24 PM, Jeff Squyres <jsquy...@cisco.com> 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: >> >> 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 >> > > > > -- > Cheers, > Brian > brian.har...@gmail.com > > > "In science, there is only physics; all the rest is stamp-collecting." > -Ernest Rutherford > -- Cheers, Brian brian.har...@gmail.com "In science, there is only physics; all the rest is stamp-collecting." -Ernest Rutherford
