Adding MPI back to Boost

[Sean Farley]

Ryan Schmidt writes:

> On Dec 14, 2014, at 12:21 PM, Sean Farley wrote:
>> 
>> Ryan Schmidt writes:
>> 
>>> So, this would add clang33, clang34, clang35 variants, for example? But these would be different from the clang 3.x provided by Xcode in some way? The MacPorts clang ports would be able to use MPI somehow, while Xcode clang would not?
>> 
>> ... ?
>
> That's a bit how I feel about this mpi business, yes.

:-/

>> First of all, for the sake of completeness, the list of variants would
>> be:
>> 
>> $ port info boost
>> boost @1.56.0_2 (devel)
>> Variants:             clang31, clang32, clang33, clang34, clang35, debug, mpich, mpich_devel, [+]no_single, [+]no_static, openmpi, openmpi_devel, python25, python26, [+]python27, python31, python32, python33, python34, regex_match_extra, universal
>> 
>> The reason I wrote the mpi and compilers portgroup was because there was
>> no way to make sure the same compiler for both is selected. For example,
>> 
>> $ port install boost +clang35 +mpich
>> 
>> will install mpich (built with clang35 compilers) and boost (built with
>> clang35 compilers).
>
> Only if mpich had not already been installed with a different variant, since MacPorts does not have the capability to declare dependencies on variants (ticket #126).

Not in this case. The mpi portgroup forces the same active compilers.

> Is the correspondence of variants between e.g. boost and mpich required? In other words, if mpich is installed with +clang35, does that mean boost *must* use the +clang35 variant as well if one wants to use the +mpich variant, or would it work if +clang34 or clang from Xcode is used for boost?

Yes, the same must be used across the board.

>> The clang provided by Xcode can be used, of course, which is the
>> default:
>> 
>> $ port install boost +mpich
>> 
>> will install mpich (built with Xcode compilers) and boost (built with
>> Xcode compilers). This will change depending on the OS version.
>
> Under what circumstances would using Xcode clang not be sufficient? In other words, why would we ever want MacPorts clang variants?

As Eric pointed out, it's for experimenting. This is exactly the same as
the reason ATLAS uses different compilers: sometimes there is a speed
improvement.

>> Perhaps you're missing that MPI is a library that provide compiler
>> *wrappers*? If a package needs MPI then that package is compiled with:
>> 
>> CC=mpicc
>> CXX=mpicxx
>> FC=mpifort
>> etc.
>
> Sure, I'm missing that, and probably a lot of other things. For example: what is the goal? What does adding mpi support to boost do? Why would someone want this?

So that a package could use Boost.MPI (such as dolfin does).

MPI falls under the category of scientific computing. This changes a few
presumptions: the goal here is numerical computation (matrix vector
operations).

Having one implementation just isn't feasible. Science users want to
experiment with each combination. You could say it's part of their
nature.