Hi everyone, It seems to be that there is a consensus that moving the path extension to iccifort would be the solution for the core issue here? I.e. 1. Move the path extension to iccifort 2. Have the intel module load iccifort instead of icc and ifort independently
I don't think hiding icc or ifort would be required as long as they don't have the path extension. I think this could be introduced into the standard HMNS without harming backwards compatibility at all. Existing modules will remain for those users who are currently loading ifort + icc + impi. Newly installed toolchain versions will start giving correct dependency information. For those who wish to fix older versions, a module-only reinstall of the intel toolchain should suffice. Best regards, Mikael On Thu, Apr 12, 2018 at 4:35 PM, Alan O'Cais <a.oc...@fz-juelich.de> wrote: > Sorry guys, I can't believe I didn't remember this (given that I wrote it) > but our custom MNS fixes this problem: > https://github.com/easybuilders/JSC/blob/master/Custom_MNS/2017b/custom_ > hierarchical_mns.py > It ignores path extensions for icc/ifort (which are hidden for us anyway) > and instead does the path extension for iccifort (which it also renames to > Intel). It also puts the MPI implementations into a separate directory so > that we can nicely present the tree. > > Alan > > On 12 April 2018 at 15:47, Alan O'Cais <a.oc...@fz-juelich.de> wrote: > >> Yeah it is sorry, I was writing without checking! >> >> On 12 April 2018 at 15:44, Mikael Öhman <micket...@gmail.com> wrote: >> >>> Hi Alan, >>> >>> However, I don't understand how you can run into this problem. Normally >>>> for any package the toolchain components are included as dependencies in >>>> the final module: loading Caffe would also mean loading the missing ifort >>>> module. I guess you must have a configuration that does not include the >>>> toolchain deps in the final module? Removing this option would also solve >>>> the problem (but you probably decided on that setting for a reason). >>>> >>> >>> Isn't this the default behavior with HMNS? >>> I suppose the rationale is that with HMNS you'll have to load the >>> compilers first to have access to the modules in the first place (though, >>> clearly, there is a mismatch between the modulepath and dependencies in >>> this case). >>> >>> Best regards, Mikael >>> >>> >>> >> >> >> -- >> Dr. Alan O'Cais >> E-CAM Software Manager >> Juelich Supercomputing Centre >> Forschungszentrum Juelich GmbH >> 52425 Juelich, Germany >> >> Phone: +49 2461 61 5213 >> Fax: +49 2461 61 6656 >> E-mail: a.oc...@fz-juelich.de >> WWW: http://www.fz-juelich.de/ias/jsc/EN >> > > > > -- > Dr. Alan O'Cais > E-CAM Software Manager > Juelich Supercomputing Centre > Forschungszentrum Juelich GmbH > 52425 Juelich, Germany > > Phone: +49 2461 61 5213 > Fax: +49 2461 61 6656 > E-mail: a.oc...@fz-juelich.de > WWW: http://www.fz-juelich.de/ias/jsc/EN > > > ------------------------------------------------------------ > ------------------------------------ > ------------------------------------------------------------ > ------------------------------------ > Forschungszentrum Juelich GmbH > 52425 Juelich > Sitz der Gesellschaft: Juelich > Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 > Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher > Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), > Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, > Prof. Dr. Sebastian M. Schmidt > ------------------------------------------------------------ > ------------------------------------ > ------------------------------------------------------------ > ------------------------------------ > >
