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.
