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/

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

[Brian Dobbins]

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