LAPACK and BLAS Support

[gha3mi]

Hi,
I am thinking on adding support for certain libraries to setup-fortran, especially LAPACK and BLAS. Do you think setup-fortran is the right place for this?

[wpbonelli]

While I see the appeal I wonder about scope/complexity creep. Maybe best limited to BLAS/LAPACK if we pursue this?

One question is which versions, presumably not the unoptimized reference. For Intel there is MKL. openBLAS seems like the typical choice otherwise and is available on APT, homebrew, mingw. However I think optimized blas/lapack are already built into macOS in the Accelerate framework.

There are also questions of GPU support. GitHub just opened private beta for hosted GPU runners github/roadmap#505 not to mention self-hosting. I guess we would detect platform and pick from cublas, rocblas, etc but I don't have any sense of the difficulty/overhead of installation, and there are also e.g. CLBlast.. I am out of my depth here, maybe others can weigh in.

[gha3mi]

I've been thinking about making libraries with fpm, which I used for ForLAPACK and ForBLAS. These may not be optimized versions, but for testing Fortran codes on GitHub, it could be a straightforward approach.

There are also questions of GPU support. GitHub just opened private beta for hosted GPU runners github/roadmap#505 not to mention self-hosting. I guess we would detect platform and pick from cublas, rocblas, etc but I don't have any sense of the difficulty/overhead of installation, and there are also e.g. CLBlast.. I am out of my depth here, maybe others can weigh in.

Interesting!

[iulusoy]

I created a fork that also installs mkl libraries for ubuntu and macos.
https://github.com/ssciwr/setup-fortran

Will also open a PR so that it may get merged with this action.

[wpbonelli]

@iulusoy I took a quick look at your fork. I like the idea, but I wonder if worth the effort. If we do this, I think it should be generic and support arbitrary components from Base or HPC kit, rather than separate inputs for each component like install_mkl. For instance we have a request to setup MPI too #21.

Maybe something like intel_components, which could accept a delimited list of the name segments following intel.oneapi.<platform>. e.g. mkl.devel,mpi,dnnl, and translate this into the full component names (retrievable from the installer with --list-components). However I am not sure component names are consistent across all versions. The action would also need to maintain a mapping of which are in base/hpc kit.

Or even more generic, maybe booleans like

- uses: fortran-lang/setup-fortran@v1
   id: setup-fortran
   with:
      compiler: ...
      version: ...
      math: true
      mpi: true

...where math installs mkl for intel and some other blas/lapack for other toolchains, and similar for mpi.

This could get pretty complicated and I want to avoid inconsistent/adhoc solutions if possible. I'm tempted to say if someone needs mkl/mpi/etc, better off just writing a custom workflow. Maybe @awvwgk has thoughts

[iulusoy]

Thank you for your feedback @wpbonelli. True, it would be nice to have something more generic.

I set it up just for mkl because I just needed those libraries, and tried to generalize for as many versions on macOS as possible. Since the code I am working with is not tested on windows, I skipped that.

It would be fairly easy to create a general action for mkl and mpi just on linux without introducing too much complexity in the code.

[wpbonelli]

@iulusoy my bandwidth to work on this is limited but please feel free if you and/or @gha3mi want to push this forward. In general I think it's probably best to

• support all three platforms
• include all currently supported toolchain versions
• avoid toolchain-specific inputs if possible

but happy to take a look at any PR. Thanks for the contributions!

[wpbonelli]

A modernized reference BLAS/LAPACK just went into stdlib — perhaps we could add a separate option to install the stdlib