Request for comments: mpi and using multiple compilers

[Sean Farley]

eborisch at macports.org writes:

> On Thu, Jul 25, 2013 at 9:31 PM, Sean Farley <sean at macports.org> wrote:
>>
>> eborisch at macports.org writes:
>>
>>> Again, I haven't scoured the whole thread, but would making sub-ports
>>> rather than variants for the different compilers help? The
>>> dependent's +gcc44+mpich could require the mpich-gcc44 package, for example.
>>
>> Not really. It just changes the name to the same problem.
>
> Except for the fact that you can *depend* on the package (user gets
> warnings if they try to install it) but MP will happily let the user
> change the variants without warning to the (active) dependents of that
> package.

True but I don't think that would buy us anything in this case. The user
would still have to manually switch the dependents of the mpi ports.

> I personally swap back and forth between variants of mpich
> when I'm testing my own MPI code (why, oh why, doesn't clang have
> OpenMP support yet?)

Because there is almost no benefit for parallel applications? ;-)
Really, though, if you're in the domain where OpenMP can help
(computation bound, dense linear algebra) then your time is better spent
on using CUDA.

> Hopefully rev-upgrade will catch that something
> has (potentially) gone south, but it won't likely be able to rebuild
> things back to their initial state without some hand-holding.

That's true. We might have to disable rev-upgrade for ports with
multiple compilers?

> We could setup the different packages to avoid naming conflicts (much
> like gcc44, gcc45) so multiple versions could be installed
> side-by-side. An mpich_select could even be put together to redirect
> mpicc -> mpicc-gccNN.
>
> I'm not saying it's necessarily the right idea, I'm just throwing it out there.

It would work for the mpich and openmpi ports but none of their
dependents. There would still be a variant problem with the dependents
of mpi, e.g.

mpich-gcc45 -> hdf5-18+gcc45 -> netcdf+gcc45 -> petsc+gcc45

To help get things moving along, I'd suggest we concentrate on the
+gfortran variant (and therefore having mpich / openmpi use 'PortGroup
multiplecompilers 1.0'). What would be holding back using the
multiplecompilers group with active_variants?