The better solution is just to require MPI-3. It is available everywhere except Blue Gene/Q at this point, and it is better to putting the burden of ensuring MPI-3 is installed on the system to your users than doing horrible gymnastics to support ancient MPI libraries.
You can consult http://meetings.mpi-forum.org/mpi3-impl-status-Mar15.pdf to see the status of all implementations w.r.t. MPI-3 as of one year ago. Jeff On Mon, Mar 21, 2016 at 1:14 PM, Jeff Hammond <jeff.scie...@gmail.com> wrote: > 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/ > -- Jeff Hammond jeff.scie...@gmail.com http://jeffhammond.github.io/
