Re: OK to import wip/scalapack?

[Jason Bacon <jtocino%gmx.com@localhost>]

On 8/1/22 15:46, Greg Troxel wrote:
> Jason Bacon <jtocino%gmx.com@localhost> writes:
>
> > Based on my experience, though, MPI packages could work well in pkgsrc,
> > as long as each implementation is isolated, e.g. under
> > ${PREFIX}/openmpi/version, ${PREFIX}/mpich/version, etc.
> >
> > Dependent packages should probably be installed under the same prefix.
> > This will be necessary for some dependents like fftw, for which it may
> > be necessary to install both mpich and openmpi builds.
>
> This is a fair bit of work, and it's not clear to me:
>
>    - if this is a proposal on the table to actually do this in pkgsrc
>
>    - if you are intending to do it
>
> I think it's a "we could do this" and "but I'm not".
>
> > I've heard arguments that conflicts between MPI packages and their
> > dependents are OK, but that won't fly on an HPC cluster where many
> > different users are running different software.  Maintaining entirely
> > separate pkgsrc trees for each MPI implementation would cost man-hours
> > in a field where there's an extreme talent shortage.
>
> I guess on one hand there is making all the mpi packages namespaced, and
> then making everything that depends on mpi also namespaced, and somehow
> bin things hooked in via alternatives, and on the other somebody kicking
> off N builds of pkgsrc.  I think it's hard to judge but I'm not doing
> either :-)
>
> > wip/openmpi is more or less functional and installs 4.0.0.  It shouldn't
> > be hard to update it to 4.1.4.
>
> [summarizing things I said offlist for tech-pkg]
> I see wip/openmpi is now at 4.1.4, thanks, and I'm trying to test and
> resolve a few PLIST issues.
>
> I see that wip/openmpi is namespaced, but that won't do the same for
> anything that uses it (and we haven't come to consensus on that, or
> against it).  Are you wanting to update parallel/openmpi from wip?  If
> so, do you see the namespace code being activated or disabled?  If not,
> do you plan to have multiple versions of openmpi in pkgsrc?
>
> (I really don't have strong opinions here, other than it's good to
> discuss.)

Like I said in another response, this is in someone else's hands now.
My plate is more than full with non-MPI projects (mainly bioinformatics
development and teaching) and I don't foresee having time to contribute
anything beyond advice based on my past experience.

I assume what you mean by "namespaced" is installed under
${PREFIX}/openmpi4.

If so, I did some crude testing of namespacing MPI dependents.  See
wip/fftw-openmpi and wip/fftw-mpich.  Those packages have the prefix
hard coded.  There might be a better way than having separate packages
(bl3?), though the mpich and openmpi builds might need different tweaks.

Also from my experience, applications usually won't need to support
multiple MPI implementations.  It's only a handful of intermediate
dependencies like fftw that would need multiple builds installed side by
side.  E.g. meep might only be built with openmpi, but it also depends
on fftw-openmpi.  Another application might be built only with mpich and
require fftw-mpich.  So separate packages like fftw-openmpi and
fftw-mpich wouldn't get out of hand.  E.g. wip/meep* could probably be
merged into one meep package with options for openmpi and MPI-free builds.

Another benefit of namespacing dependents is the use of environment
modules, which prepend PATH components and are a standard tool in HPC.
Load the openmpi4 module and you have access to the openmpi4 commands as
well as all dependent software since they are all in
${PREFIX}/openmpi4/bin or similar.  This makes pkgsrc more convenient
than what many HPC users are used to: Loading a whole chain of modules
for applications and libraries cave-man installed into different
directories.

That's the direction I was going with this when I was supporting HPC.
Whoever it matters to more at this point might take a different approach.

Cheers,

	J