Brian Dobbins <bdobb...@gmail.com> writes: > Hi everyone, > > This isn't really a problem, per se, but rather a search for a more > elegant solution. It also isn't specific to OpenMPI, but I figure the > experience and knowledge of people here made it a suitable place to ask:
It's also not Fortran specific, though it's probably best asked about in a Fortran forum. > I'm working on some code that'll be used and downloaded by others on > multiple systems, and this code is using some MPI3 features (neighborhood > collectives), but not everyone has the latest MPI libraries, many people > will be running the code on systems without these functions. > > If this were a C/C++ code, it'd be quite easy to deal with this as > 'mpi.h' has MPI_VERSION as a #define, so I can use a preprocessor check to > conditionally compile either the neighbor routines or the old > point-to-point routines. However, Fortran obviously doesn't use #define > natively, and so the mpif.h (or MPI module) simply define MPI_VERSION as a > parameter - I can use it in the code, but not at the preprocessor level. > So, putting the MPI3 neighborhood collective in the code, even in a > non-executed codepath, results in an error when linking with an MPI2 > library since the routine isn't found. With which compiler, and even optimized? $ `mpif90 --showme` --version | head -n1 GNU Fortran (GCC) 4.4.7 20120313 (Red Hat 4.4.7-17) $ cat a.f90 use mpi if (mpi_version == 3) call undefined() print *, mpi_version end $ mpif90 a.f90 && ./a.out 2 > Obviously I can just have the user supply the -DMPI_VERSION=3 flag (or a > different one, since this *is* a parameter name) *if they know* their MPI > is version 3, and I intend to submit a patch to Cmake's FindMPI command to > detect this automatically, but is there a *better* way to do this for > projects that aren't using Cmake? Yes, not using cmake is definitely better -- people like me should be able to build the result! With autoconf, you could run the above to get mpi_version, or adapt it to produce a link-time error for a specific version if cross-compiling. However, you should test for the routines you need in the normal autoconf way. Presumably checking one is enough for a particular standard level. There are examples of autoconf tests for MPI3 (at least the constification of arguments in C) in several profiling/correctness tools, but I can't remember what's where, and I think all in C. > Scientists don't typically know what > version of MPI they're running, so the more that can be detected and > handled automatically the better. Right. > (Providing stub versions that link > *after* the main library (and thus don't get chosen, I think) also seems > less than elegant.) > > To make it slightly more broad - if new MPI versions outpace library > obsolescence on existing systems, what's the ideal way to write portable > Fortran code that uses the most recent features? Is there a way to use or > change MPI_VERSION and MPI_SUBVERSION such that they can be used to > conditionally compile code in Fortran built by standard 'Make' processes? > Is 'recommending' that the mpif90/mpif77 commands provide them a terrible, > terrible idea? I'd hope you could modularize things and select the right modules to link using a configure test and possibly automake. That's probably easier for Fortran than the sort of C I encounter. You _can_ use cpp for Fortran with care (.F extension for GNU Fortran), but it's intrinsically evil. The cp2k chemistry code is one that does, including for MPI-3 selection, but it isn't autoconfiscated and so is relatively awkward to build.