Re: [OMPI users] Q: Fortran, MPI_VERSION and #defines

[Jeff Hammond]

On Mon, Mar 21, 2016 at 1:37 PM, Brian Dobbins  wrote:

>
> Hi Jeff,
>
> On Mon, Mar 21, 2016 at 2:18 PM, Jeff Hammond 
> wrote:
>
>> 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.
>>
>
> Thank you - that's something I was curious about, and it's incredibly
> helpful.  Some places seem to not update their libraries terribly often,
> perhaps for stability/reproducibility reasons, and one of the primary
> systems I'm using still has an MPI2 library as the default.  I suspected,
> but hadn't known, that MPI3 versions were already widely available.  Anyone
> else still have an MPI2 library as the default on their systems?
>
>
If you want to support IBM Blue Gene MPI and Fujitsu MPI, you should verify
MPI-3 support there.  Every other machine I know about has the ability to
support MPI-3.

Calling from C code is another workable but less-than-elegant solution,
> since not everyone knows C, even the basics of it, plus it adds a bit of
> complexity.  I think maybe I'll just plan on 'expecting' MPI3 and using
> macros to tackle the edge-case of MPI2/2.1.
>
>
Sure, but more people know C than Fortran :-)


> Still, I wish there was an automatic -DMPI_VERSION=30 flag (or something
> similar) added implicitly by the MPI command line.  Maybe, since
> MPI_VERSION and MPI_SUBVERSION are taken, an MPI_FEATURES one (eg,
> -DMPI_FEATURES=30, combining version and subversion)?  I guess it's rarely
> needed except in situations where you have new codes on older systems,
> though.
>
>
This is a great feature suggestion for the MPI Fortran compiler wrapper
scripts.  The behavior of these scripts is not standardized, but if
Open-MPI and MPICH support this, that's pretty close to standardized :-)

Jeff


> Any other perspectives on this?
>
> Cheers,
>   - 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/28780.php
>




-- 
Jeff Hammond
jeff.scie...@gmail.com
http://jeffhammond.github.io/

Re: [OMPI users] Q: Fortran, MPI_VERSION and #defines

[Brian Dobbins]

Hi Dave,

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
>

No, optimized works, actually - unoptimized is the issue.  I should've
added that in the beginning.  Since MPI_VERSION is a parameter, the
optimizer *knows* the code path won't be used, and thus it doesn't include
it in the binary and life is good.  Compiling with -O0 results in an issue,
however, at least with Intel 15/16 compilers, and I'd guess gfortran
too(?).

So, once again, maybe I'm trying too hard to find a problem.  ;-)

If I don't ever need to build with -O0, *or* simply request the user to
provide the -DMPI3 (or maybe -DMPI2, since that's the less-common one now)
flag, I have no issues.

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.
>

Yes, this is an option too.  It's more a mild nuisance in the dissimilarity
of how C/C++ can, by default, process the #defines due to the preprocessor,
whereas Fortran code doesn't have the same flexibility.  Autoconf to
provide the -D flag is an option, indeed.


> 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.
>

I'm only responsible for a tiny fraction of the code, none of which is the
build process.  I think I'm attempting to over-simplify an already
fairly-simple-but-not-quite-perfect reality.  ;)

  Thanks for the feedback and ideas!

  - Brian

Re: [OMPI users] Q: Fortran, MPI_VERSION and #defines

[Dave Love]

Brian Dobbins  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.

Re: [OMPI users] Q: Fortran, MPI_VERSION and #defines

[Brian Dobbins]

Hi Jeff,

On Mon, Mar 21, 2016 at 2:18 PM, Jeff Hammond 
wrote:

> 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.
>

Thank you - that's something I was curious about, and it's incredibly
helpful.  Some places seem to not update their libraries terribly often,
perhaps for stability/reproducibility reasons, and one of the primary
systems I'm using still has an MPI2 library as the default.  I suspected,
but hadn't known, that MPI3 versions were already widely available.  Anyone
else still have an MPI2 library as the default on their systems?

Calling from C code is another workable but less-than-elegant solution,
since not everyone knows C, even the basics of it, plus it adds a bit of
complexity.  I think maybe I'll just plan on 'expecting' MPI3 and using
macros to tackle the edge-case of MPI2/2.1.

Still, I wish there was an automatic -DMPI_VERSION=30 flag (or something
similar) added implicitly by the MPI command line.  Maybe, since
MPI_VERSION and MPI_SUBVERSION are taken, an MPI_FEATURES one (eg,
-DMPI_FEATURES=30, combining version and subversion)?  I guess it's rarely
needed except in situations where you have new codes on older systems,
though.

Any other perspectives on this?

Cheers,
  - Brian

Re: [OMPI users] Q: Fortran, MPI_VERSION and #defines

[Jeff Hammond]

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 
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 
> 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/

Re: [OMPI users] Q: Fortran, MPI_VERSION and #defines

[Jeff Hammond]

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  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/