support use of linalg without MPI, add iimkl toolchain definition

[bartoldeman]

The motivation for this request is that at Compute Canada we'd like to install MKL at the core level.
However that means we have to set interfaces = False in the mkl easyconfig.

Since non-MPI FFTW3 interfaces are already included in MKL without compiling interfaces this MKL can be used in toolchains except when MPI-FFTW3 is required (and I don't think many applications use MPI-FFTW3? I should look up some examples).

Another advantage is that one can construct compiler+linalg+fftw toolchains without MPI which is useful for compiler x MPI hierarchies.

[boegel]

Hmm, this is very dependent on the order in check_fftw_libs...
Can we make things more direct, by comparing directly with what should be removed from check_fftw_libs rather than making assumptions on order?

It's also not very clear to me what's going on here, can you clarify @bartoldeman?

[boegel]

hmm, I feel we need a more direct check on whether or not the toolchain definition includes MPI or not, rather than relying on toolchain options...

Maybe check if the MPI_MODULE_NAME attribute is defined (and if it's not None)?

if hasattr(self, 'MPI_MODULE_NAME') and getattr(self, 'MPI_MODULE_NAME') is not None:
    self._set_blacs_variables()
    self._set_scalapack_variables()

[boegel]

@bartoldeman One of the tests was broken, since $LIBSCALAPACK is no longer defined now for the iccifort toolchain which does not include MPI.

This signifies a backward-incompatible change, some easyblocks may expect that $LIBSCALAPACK & co are defined, even for toolchain that do not include MPI (although I admit that would be rather strange).

Maybe we should just define these variables as empty rather than not defining them (which is very different in practice)?

[bartoldeman]

Actually from looking into the logs the test failed for goolfc. I have pushed the getattr change suggested by you (with a minor syntax change, as getattr accepts a default argument).

We will see if that fixes the tests. I don't think iccifort defines $LIBSCALAPACK right?

[boegel]

@bartoldeman Yes, you're right, my apologies, I was misled by the name of the test that was failing.
Of course $LIBSCALAPACK is not defined for the iccifort toolchain, since it doesn't include imkl.

[boegel]

how about simplifying this a bit while we're at it:

if LooseVersion(imklver) >= LooseVersion('10.3'):
    suff = picsuff
    if LooseVersion(imklver) >= LooseVersion('11.0.2'):
        suff = bitsuff + suff
    cluster_interface_lib = 'fftw3x_cdft%s' % suff
    fftw_libs.append(cluster_interface_lib)

[boegel]

please change to:

check_fftw_libs = [l for l in check_fftw_libs if l not in [interface_lib, cluster_interface_lib]]

[boegel]

@bartoldeman looks OK now, just a couple of code style suggestions

This will need to be tested thoroughly though... Good candidates are builds using the intel toolchain that rely on $LIBFFT, e.g. numpy, CP2K, QuantumESPRESSO.

[boegel]

@bartoldeman looks good now, how extensively have you tested this (with which easyconfigs)?

[bartoldeman]

So far tested with an iomkl toolchain with imkl at the bottom ('dummy':'dummy'), compiled boost, gromacs, hpl, fftw (iomkl) python, R (iimkl, without mpi4py/Rmpi).

We will do a lot more this week (Compute Canada software installation hackathon this Thursday) so I will let you know. I think CP2K and QuantumESPRESSO both need to be installed.

[boegel]

I'm testing this with numpy, CP2K, QuantumESPRESSO, Wien2k and XCrySDen, all of which rely on $LIBFFT, and also MUMPS and NWChem which rely on $LIBSCALAPACK.

If those tests work out well (and I expect them too), I'll go ahead and merge this.

[boegel]

Tests worked out well as expected, so no reason to hold this back further.

Thanks @bartoldeman!