Call MPI from C code, where you will have all the preprocessor support you need. Wrap that C code with Fortran 2003 ISO_C_BINDING. If you don't have neighborhood collectives from MPI-3, you can implement them using MPI-1 yourself in the interface between your Fortran code and MPI C bindings. This will ensure you don't need Fortran preprocessing.
I end up doing this (except for the Fortran part) with MPI RMA code. For example, I have a wrapper for MPI_Win_allocate, which drops into MPI_Alloc_mem+MPI_Win_create when only MPI-2 is available. Jeff On Mon, Mar 21, 2016 at 10:27 AM, Brian Dobbins <bdobb...@gmail.com> wrote: > > 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: > > 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. > > 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? Scientists don't typically know what > version of MPI they're running, so the more that can be detected and > handled automatically the better. (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? > > Or any other suggestions? > > Thanks, > - Brian > > _______________________________________________ > users mailing list > us...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users > Link to this post: > http://www.open-mpi.org/community/lists/users/2016/03/28777.php > -- Jeff Hammond jeff.scie...@gmail.com http://jeffhammond.github.io/
