On 11/03/2016 12:22 PM, Pablo Escobar Lopez wrote:
Hi Ole,
Could you share your iomkl easyconfig using the latest intel2017 compiler?
I've made a working iomkl toolchain, however, using the Intel 2016.3.210
compiler version. The iomkl, iompi, imkl EB files are in this branch:
https://github.com/OleHolmNielsen/easybuild-easyconfigs/tree/iomkl-2016.09-GCC-5.4.0-2.26
We have tested the iomkl toolchain with one of our production codes, and
it seems to work correctly.
/Ole
2016-11-03 12:07 GMT+01:00 Fotis Georgatos <[email protected]
<mailto:[email protected]>>:
Hi Ole, all,
On Nov 2, 2016, at 2:33 PM, Ole Holm Nielsen
<[email protected] <mailto:[email protected]>> wrote:
> On 11/02/2016 12:52 PM, Åke Sandgren wrote:
>> env INTEL_LICENSE_FILE=port@host eb intel-2016a.eb ...
>
> Fantastic, this worked for me! I wonder where the usage of license_file
and/or INTEL_LICENSE_FILE within EB might be documented?
It SHOULD ;-)
There’s one caveat with the port@host approach:
One day, Intel’s practices will force you to setup a second license
server
(either because you need to setup a new flexlm server version or,
because Intel has the nasty habit of silently deprecating old
components in new licenses
and you need to point to a test instance without touching your
production instance yet)
So, it’s more beneficial to point to a file, so that you can easily
redirect clients
to a new server instance, from a *single* point of control - without
touching the modulefiles at all!
If you have 100s of Intel modulefiles in module buildset trees, you
know what I’m talking about!
Also one more potential caveat: although it IS possible to drop in
that one just the first 2 lines
of the license file (ie. license server coordinates) don’t do that
either and use the whole thing:
I’ve met situations where certain Intel components (not all) have
bugs and don’t cooperate well.
I no longer have the Intel ticket numbers but you can take my word
for it: I’ve spend endless hours around it.
Last but not least, something I’ve not tried yet: you could be
pointing instead to a licensefile
sitting on /dev/shm, presumably populated at node boot time, so that
you can have more granularity
of control - at node level rather than cluster. This would permit
you fi. to modify node behaviour
in a rolling update fashion. I haven’t yet been hit by the absence
of this but it’s a nice to have.
