Davide,
yes, 'iccifort' needs to be visible. In fact, in my setup I am
hiding 'icc' and 'ifort' and only have 'iccifort' non-hidden
(well, it is actually also renamed to 'Intel', but that is a
different story...). The 'recursive_module_unload' is not
necessarily a global setting; you can also put it in an the
corresponding easyconfig where you want this behavior, e.g.,
in all compiler modules which are the lowest level of the
hierarchy and the recursive unloading shouldn't do any harm.
Markus
On 03/16/17 14:58, Vanzo, Davide wrote:
> Markus and Alan,
> a quick follow up on this.
> I followed your route of not exposing the toolchains and I am facing the
> following issue. With the Intel compilers there are two separate modules
> for icc and ifort. I cannot add family("compiler") to both in order to
> avoid conflict with GCC built modules since it is possible that a user
> needs both iss and ifort at the same time. So the only option would be
> to expose the iccifort toolchain instead of the two separate modules.
> But in this way I need to build everything with recursive_module_unload.
> Any comment or suggestion on this?
>
> --
> Davide Vanzo, PhD
> Application Developer
> Adjunct Assistant Professor of Chemical and Biomolecular Engineering
> Advanced Computing Center for Research and Education (ACCRE)
> Vanderbilt University - Hill Center 201
> www.accre.vanderbilt.edu
>
> On Feb 6 2017, at 12:47 pm, Markus Geimer <[email protected]> wrote:
>
> Davide,
>
> > Do you add the family attribute manually after EB installed
> > the default module for a specific package?
>
> We currently add
>
> modluafooter = 'family("compiler")'
>
> or similar to the easyconfig file.
>
> > For this purpose it would be nice to have a function in EB that would
> > allow from the easyconfig file
>
> There has been some work on this, see
> https://github.com/hpcugent/easybuild-framework/pull/1257
> However, the PR hasn't been touched for a while and will need some
> care. Maybe someone at the User Group meeting is keep on adopting
> it ;-)
>
> > (or even better in a easyconfig patch
> > files) to add additional lines to the generated module for a more easy
> > to manage localization.
>
> +1 for easyconfig patch files
>
> Markus
>
>
> > On Feb 6 2017, at 12:05 pm, Alvarez, Damian <[email protected]>
> > wrote:
> >
> > I’ll cover it a bit, but not too deeply. In any case, I don’t think
> > Davide will come.
> >
> >
> >
> > Anyway, what are the issues you are seeing? I think that using a
> > toolchain based module naming scheme this would work similarly to
> > the hierarchical scheme (ie: it will prevent you from loading a
> > compiler on top of another one)
> >
> >
> >
> > Damian
> >
> >
> >
> > *From: *<[email protected]> on behalf of Alan O'Cais
> > <[email protected]>
> > *Reply-To: *"[email protected]" <[email protected]>
> > *Date: *Monday 6 February 2017 at 18:22
> > *To: *"[email protected]" <[email protected]>
> > *Subject: *Re: [easybuild] Lmod integration - Families
> >
> >
> >
> > We use families for compilers and MPI implementations in a
> > hierarchical scheme. We do not expose the toolchains to normal
> > users. Damian will probably cover this a little in his presentation
> > on Wednesday.
> >
> >
> >
> > Alan
> >
> >
> >
> > On 6 February 2017 at 16:57, Vanzo, Davide
> > <[email protected] <mailto:[email protected]>>
> > wrote:
> >
> > Hello all,
> >
> > one of the most useful features provided by Lmod is the ability
> > to assign a family to a subset of modules in order to avoid
> > loading potentially conflicting software. This gets a little
> > complicated when dealing with the toolchain-based model of EB. I
> > was wondering if anybody is using families and how.
> >
> > Thank you.
> >
> >
> > --
> > Davide Vanzo, PhD
> > Application Developer
> >
> > Adjunct Assistant Professor of Chemical and Biomolecular Engineering
> >
> > Advanced Computing Center for Research and Education (ACCRE)
> >
> > Vanderbilt University - Hill Center 201
> > www.accre.vanderbilt.edu <http://www.accre.vanderbilt.edu>
> >
> >
> >
> >
> >
> > --
> >
> > 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: [email protected] <mailto:[email protected]>
> > 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
> >
>
> ------------------------------------------------------------------------------------------------
> >
>
> ------------------------------------------------------------------------------------------------
> >
> >
>
> --
> Dr. Markus Geimer
> Juelich Supercomputing Centre
> Institute for Advanced Simulation
> Forschungszentrum Juelich GmbH
> 52425 Juelich, Germany
>
> Phone: +49-2461-61-1773
> Fax: +49-2461-61-6656
> E-Mail: [email protected]
> Web: http://www.fz-juelich.de/jsc
>
--
Dr. Markus Geimer
Juelich Supercomputing Centre
Institute for Advanced Simulation
Forschungszentrum Juelich GmbH
52425 Juelich, Germany
Phone: +49-2461-61-1773
Fax: +49-2461-61-6656
E-mail: [email protected]
WWW: http://www.fz-juelich.de/jsc/
