Hej Joachim,
We have the same issue. From the last EasyBuild user meeting, I got a few
suggestions on how to try and fix the issue, but I was never successful
with these.
We try to educate out users to always use the toolchain packages whenever
possible "module load intel".
I think the nicest solution, which would make it similar to how foss
toolchain works, is to remove
prepend_path("MODULEPATH", "/apps/etc.etc/all/Compiler/intel/some.version")
from the icc and ifort modules into the their respective "iccifort" module.
This would make "module spider" only spit out 1 version, "module load
intel" still works correctly, and there is no way to achieve this without.
Unfortunately, I would have preferred if we could have simply gotten
"module spider" to show e.g. "intel/2017b" directly. But, the the way the
heirarchical structure is set up, I can't see any way to achieve this
(without drastic changes)
As an alternative approach, I also wrote some python code that reads out
the entire module tree, and gives a summary expressed only in terms of
toolchains; "intel/2017a" "foss/2018a" etc. I was thinking of publishing
this on our website and just direct users there instead of "module spider".
I also regret the decision to go with HMNS.
On Thu, Apr 12, 2018 at 3:22 PM, Joachim Hein <[email protected]>
wrote:
> Hi,
>
> There is a longstanding issue on our site regarding the intel fortran
> runtime for some packages. I assume other sites have the same, but am not
> sure it was ever discussed here.
>
> We are using hierarchical modules in production. If a package is build
> with an intel toolchain, you can load it by either loading the
>
> icc, impi
>
> or
>
> ifort, impi
>
> component of that toolchain. If a package (e.g.
> Caffe-1.0-intel-2017a-Python-2.7.13.eb) requires the Fortran runtime but
> it is loaded via the icc route, you get runtime errors because of the
> missing libifport.so.
>
> A possible fix could be to load either of the ifort or intel modules
> inside the package (e.g. Caffe) module. I assume that would need to be
> done in the easy-block or further down inside the easybuild framework.
>
> Any comments or insights? Apologies if that was discussed before.
>
> Best wishes
> Joachim
