Closed ocaisa closed 8 years ago
I don't think there's a very good reason.
It seems like some of the required logic is there though, see https://github.com/hpcugent/easybuild-framework/blob/master/easybuild/toolchains/fft/fftw.py#L52.
I.e., we're basically defining $LIBFFT
with the thread-safe libfftw
if the usempi
toolchain option is True
.
That's not exactly consistent with what we do for BLAS
and LAPACK
though, so letting the framework also define $LIBFFT_MT
makes sense.
Are you up for that? It should be pretty straightforward based on the logic for $LIBBLAS_MT
.
Take a look at easybuild/tools/toolchain/linalg.py
, look for _MT
, and then adjust easybuild/tools/toolchain/fft.py
+ the modules in easybuild/toolchains/linalg/
This bit us again yesterday with Quantum Espresso and the foss toolchain. Part of the problem is that the quantum espresso easyblock is not (yet) smart enough to use the correct libraries when things are threaded. It needs some additional logic in https://github.com/hpcugent/easybuild-easyblocks/blob/master/easybuild/easyblocks/q/quantumespresso.py#L136 to ensure the MT libraries are used when building the hybrid mode. Even if you do that, you come back to the issue that LIBFFT_MT
does not exist (yet) in the framework, without it you end with linking problems (when not using MKL).
fixed with #1802, thanks @ocaisa!
With the MKL, there are _MT versions of BLAS and LAPACK environment variables but no corresponding _MT variable for FFT. Is there a good reason for this? It looks like it is required when building a threaded version of ABINIT