Spack can install and use several software development products offered by Intel.
Some of these are available under no-cost terms, others require a paid license.
All share the same basic steps for configuration, installation, and, where
applicable, license management. The Spack Python class
Spack interacts with Intel tools in several routes, like it does for any other package:
Accept system-provided tools after you declare them to Spack as external packages.
Install the products for you as internal packages in Spack.
Use the packages, regardless of installation route, to install what we’ll call client packages for you, this being Spack’s primary purpose.
An auxiliary route follows from route 2, as it would for most Spack packages, namely:
Make Spack-installed Intel tools available outside of Spack for ad-hoc use, typically through Spack-managed modulefiles.
This document covers routes 1 through 3.
intel-mkl– Math Kernel Library (linear algebra and FFT),
intel-mpi– The Intel-MPI implementation (derived from MPICH),
intel-ipp– Primitives for image-, signal-, and data-processing,
intel-daal– Machine learning and data analytics.
Some earlier versions of these libraries were released under a paid license. For these older versions, the license must be available at installation time of the products and during compilation of client packages.
The library packages work well with the Intel compilers but do not require them – those packages can just as well be used with other compilers. The Intel compiler invocation commands offer custom options to simplify linking Intel libraries (sometimes considerably), but Spack always uses fairly explicit linkage anyway.
Intel’s core software development products that provide compilers, analyzers, and optimizers do require a paid license. In Spack, they are packaged as:
intel-parallel-studio– the entire suite of compilers and libraries,
intel– a subset containing just the compilers and the Intel-MPI runtime [fn2].
The license is needed at installation time and to compile client packages, but never to merely run any resulting binaries. The license status for a given Spack package is normally specified in the package code through directives like license_required (see Licensed software). For the Intel packages, however, the class code provides these directives (in exchange of forfeiting a measure of OOP purity) and takes care of idiosyncasies like historic version dependence.
The libraries that are provided in the standalone packages are also included in the
intel-parallel-studio. To complicate matters a bit, that
package is sold in 3 “editions”, of which only the upper-tier
edition supports compiling MPI applications, and hence only that edition can
mpi virtual package. (As mentioned [fn2], all editions
provide support for running MPI applications.)
The edition forms the leading part of the version number for Spack’s
intel* packages discussed here. This differs from the primarily numeric
version numbers seen with most other Spack packages. For example, we have:
$ spack info intel-parallel-studio ... Preferred version: professional.2018.3 http:... Safe versions: professional.2018.3 http:... ... composer.2018.3 http:... ... cluster.2018.3 http:... ... ...
The full studio suite, capable of compiling MPI applications, currently
requires about 12 GB of disk space when installed (see section Install steps
for packages with compilers and libraries for detailed instructions).
If you need to save disk space or installation time, you could install the
intel compilers-only subset (0.6 GB) and just the library packages you
need, for example
intel-mpi (0.5 GB) and
intel-mkl (2.5 GB).
If you wish to integrate licensed Intel products into Spack as external packages (route 1 above) we assume that their license configuration is in place and is working [fn3]. In this case, skip to section Integration of Intel tools installed external to Spack.
If you plan to have Spack install licensed products for you (route 2 above), the Intel product installer that Spack will run underneath must have access to a license that is either provided by a license server or as a license file. The installer may be able to locate a license that is already configured on your system. If it cannot, you must configure Spack to provide either the server location or the license file.
For authoritative information on Intel licensing, see:
Installing and configuring a license server is outside the scope of Spack. We assume that:
Your system administrator has a license server running.
The license server offers valid licenses for the Intel packages of interest.
You can access these licenses under the user id running Spack.
Be aware of the difference between (a) installing and configuring a license server, and (b) configuring client software to use a server’s so-called floating licenses. We are concerned here with (b) only. The process of obtaining a license from a server for temporary use is called “checking out a license”. For that, a client application such as the Intel package installer or a compiler needs to know the host name and port number of one or more license servers that it may query [fn4].
Follow one of three methods to point client software to a floating license server.
Ideally, your license administrator will already have implemented one that can
be used unchanged in Spack: Look for the environment variable
INTEL_LICENSE_FILE or for files
/opt/intel/licenses/*.lic that contain:
SERVER hostname hostid_or_ANY portnum USE_SERVER
The relevant tokens, among possibly others, are the
intended specifically for clients, and one or more
SERVER lines above it
which give the network address.
If you cannot find pre-existing
/opt/intel/licenses/*.lic files and the
INTEL_LICENSE_FILE environment variable is not set (even after you loaded
any relevant modulefiles), ask your license administrator for the server
address(es) and place them in a “global” license file within your Spack
directory tree as shown below).
If you purchased a user-specific license, follow Intel’s instructions to “activate” it for your serial number, then download the resulting license file. If needed, request to have the file re-sent to you.
Intel’s license files are text files that contain tokens in the proprietary
“FLEXlm” format and whose name ends in
Intel installers and compilers look for license files in several locations when they run.
Place your license by one of the following means, in order of decreasing preference:
Install your license file in the directory
/opt/intel/licenses/if you have write permission to it. This directory is inspected by all Intel tools and is therefore preferred, as no further configuration will be needed. Create the directory if it does not yet exist. For the file name, either keep the downloaded name or use another suitably plain yet descriptive name that ends in
.lic. Adjust file permissions for access by licensed users.
Directory given in environment variable
If you cannot use the default directory, but your system already has set the environment variable
INTEL_LICENSE_FILEindependent from Spack [fn5], then, if you have the necessary write permissions, place your license file in one of the directories mentioned in this environment variable. Adjust file permissions to match licensed users.
If your system has not yet set and used the environment variable
INTEL_LICENSE_FILE, you could start using it with the
spack installstage of licensed tools and subsequent client packages. You would, however, be in a bind to always set that variable in the same manner, across updates and re-installations, and perhaps accommodate additions to it. As this may be difficult in the long run, we recommend that you do not attempt to start using the variable solely for Spack.
The first time Spack encounters an Intel package that requires a license, it will initialize a Spack-global Intel-specific license file for you, as a template with instructional comments, and bring up an editor [fn6]. Spack will do this even if you have a working license elsewhere on the system.
To proceed with an externally configured license, leave the newly templated file as is (containing comments only) and close the editor. You do not need to touch the file again.
To configure your own standalone license, copy the contents of your downloaded license file into the opened file, save it, and close the editor.
To use a license server (i.e., a floating network license) that is not already configured elsewhere on the system, supply your license server address(es) in the form of
USE_SERVERlines at the beginning of the file [fn7], in the format shown in section Pointing to an existing license server. Save the file and close the editor.
To revisit and manually edit this file, such as prior to a subsequent installation attempt, find it at
Spack will place symbolic links to this file in each directory where licensed Intel binaries were installed. If you kept the template unchanged, Intel tools will simply ignore it.
This section discusses route 1 from the introduction.
A site that already uses Intel tools, especially licensed ones, will likely have some versions already installed on the system, especially at a time when Spack is just being introduced. It will be useful to make such previously installed tools available for use by Spack as they are. How to do this varies depending on the type of the tools:
For Spack to use external Intel compilers, you must tell it both where to
find them and when to use them. The present section documents the “where”
compilers.yaml and, in most cases, long absolute paths.
The “when” aspect actually relates to route 3 and requires explicitly
stating the compiler as a spec component (in the form
foo %intel or
%intel@compilerversion) when installing client packages or altering Spack’s
compiler default in
See section Selecting Intel compilers for details.
To integrate a new set of externally installed Intel compilers into Spack
Briefly, prepare your shell environment like you would if you were to use these
compilers normally, i.e., typically by a
module load ... or a shell
source ... command, then use
spack compiler find to make Spack aware of
these compilers. This will create a new entry in a suitably scoped and possibly new
compilers.yaml file. You could certainly create such a compiler entry
manually, but this is error-prone due to the indentation and different data
The Intel compilers need and use the system’s native GCC compiler (
clang on macOS) to provide certain functionality, notably to
support C++. To provide a different GCC compiler for the Intel tools, or more
generally set persistent flags for all invocations of the Intel compilers, locate
compilers.yaml entry that defines your Intel compiler, and, using a
text editor, change one or both of the following:
modules:tag, add a
gccmodule to the list.
Consult the examples under
Vendor-Specific Compiler Configuration
in the Spack documentation.
When done, validate your compiler definition by running
spack compiler info intel@compilerversion (replacing
the version that you defined).
Be aware that both the GCC integration and persistent compiler flags can also be affected by an advanced third method:
A modulefile that provides the Intel compilers for you could, for the benefit of users outside of Spack, implicitly integrate a specific
gccversion via compiler flag environment variables or (hopefully not) via a sneaky extra
Next, visit section Selecting Intel Compilers to learn how to tell Spack to use the newly configured compilers.
Configure external library-type packages (as opposed to compilers)
in the files
~/.spack/packages.yaml, following the Spack documentation under
packages.yaml files define a package
external to Spack in terms of a Spack spec and resolve each such spec via
modules tokens to a specific pre-installed package
version on the system. Since Intel tools generally need environment variables
to interoperate, which cannot be conveyed in a mere
modules token will be more sensible to use. It resolves the Spack-side
spec to a modulefile generated and managed outside of Spack’s purview,
which Spack will load internally and transiently when the corresponding spec is
called upon to compile client packages.
Unlike for compilers, where
spack find compilers [spec] generates an entry
in an existing or new
compilers.yaml file, Spack does not offer a command
to generate an entirely new
packages.yaml entry. You must create
new entries yourself in a text editor, though the command
[--scope=...] edit packages can help with selecting the proper file.
for an explanation about the different files
for specifics and examples for
The following example integrates packages embodied by hypothetical
Spack as packages
$ spack config edit packages
Make sure the file begins with:
Adapt the following example. Be sure to maintain the indentation:
# other content ... intel-mkl: modules: firstname.lastname@example.org arch=linux-centos6-x86_64: intel-mkl/18/18.0.2 email@example.com arch=linux-centos6-x86_64: intel-mkl/18/18.0.3
The version numbers for the
intel-mkl specs defined here correspond to file
and directory names that Intel uses for its products because they were adopted
and declared as such within Spack’s package repository. You can inspect the
versions known to your current Spack installation by:
$ spack info intel-mkl
Using the same version numbers for external packages as for packages known
internally is useful for clarity, but not strictly necessary. Moreover, with a
packages.yaml entry, you can go beyond internally known versions.
Note that the Spack spec in the example does not contain a compiler specification. This is intentional, as the Intel library packages can be used unmodified with different compilers.
A slightly more advanced example illustrates how to provide
and how to use the
buildable: False directive to prevent Spack from installing
other versions or variants of the named package through its normal internal
packages: intel-parallel-studio: modules: firstname.lastname@example.org +mkl+mpi+ipp+tbb+daal arch=linux-centos6-x86_64: intel/18/18.0.2 email@example.com +mkl+mpi+ipp+tbb+daal arch=linux-centos6-x86_64: intel/18/18.0.3 buildable: False
One additional example illustrates the use of
paths: instead of
modules:, useful when external modulefiles are not available or not
packages: intel-parallel-studio: paths: firstname.lastname@example.org +mkl+mpi+ipp+tbb+daal: /opt/intel email@example.com +mkl+mpi+ipp+tbb+daal: /opt/intel buildable: False
Note that for the Intel packages discussed here, the directory values in the
paths: entries must be the high-level and typically version-less
“installation directory” that has been used by Intel’s product installer.
Such a directory will typically accumulate various product versions. Amongst
them, Spack will select the correct version-specific product directory based on
@version spec component that each path is being defined for.
For further background and details, see External Packages.
This section discusses route 2 from the introduction.
When a system does not yet have Intel tools installed already, or the installed versions are undesirable, Spack can install these tools like any regular Spack package for you and, with appropriate pre- and post-install configuration, use its compilers and/or libraries to install client packages.
intel (which is a subset of the
former) are many-in-one products that contain both compilers and a set of
library packages whose scope depends on the edition.
Because they are general products geared towards shell environments,
it can be somewhat involved to integrate these packages at their full extent
Note: To install library-only packages like
follow the next section instead.
Review the section Configuring spack to use intel licenses.
To install a version of
intel-parallel-studiothat provides Intel compilers at a version that you have not yet declared in Spack, the following preparatory steps are recommended:
Determine the compiler spec that the new
intel-parallel-studiopackage will provide, as follows: From the package version, combine the last two digits of the version year, a literal “0” (zero), and the version component that immediately follows the year.
Compiler spec provided
Example: The package
firstname.lastname@example.org provide the compiler with spec
Add a new compiler section with the newly anticipated version at the end of a
compilers.yamlfile in a suitable scope. For example, run:
$ spack config --scope=user/linux edit compilers
and append a stub entry:
- compiler: target: x86_64 operating_system: centos6 modules:  spec: email@example.com paths: cc: stub cxx: stub f77: stub fc: stub
18.0.3with the version that you determined in the preceeding step. The contents under
paths:do not matter yet.
You are right to ask: “Why on earth is that necessary?” [fn8]. The answer lies in Spack striving for strict compiler consistency. Consider what happens without such a pre-declared compiler stub: Say, you ask Spack to install a particular version
intel-parallel-studio@edition.V. Spack will apply an unrelated compiler spec to concretize and install your request, resulting in
intel-parallel-studio@edition.V %X. That compiler
%Xis not going to be the version that this new package itself provides. Rather, it would typically be
%gcc@...in a default Spack installation or possibly indeed
%intel@..., but at a version that precedes
The problem comes to the fore as soon as you try to use any virtual
mpipackages that you would expect to now be provided by
intel-parallel-studio@edition.V. Spack will indeed see those virtual packages, but only as being tied to the compiler that the package
intel-parallel-studio@edition.Vwas concretized with at installation. If you were to install a client package with the new compilers now available to you, you would naturally run
spack install foo +mkl %intel@V, yet Spack will either complain about
mkl%intel@Vbeing missing (because it only knows about
mkl%X) or it will go and attempt to install another instance of
intel-parallel-studio@edition.V %intel@Vso as to match the compiler spec
%intel@Vthat you gave for your client package
foo. This will be unexpected and will quickly get annoying because each reinstallation takes up time and extra disk space.
To escape this trap, put the compiler stub declaration shown here in place, then use that pre-declared compiler spec to install the actual package, as shown next. This approach works because during installation only the package’s own self-sufficient installer will be used, not any compiler.
Verify that the compiler version provided by the new
studioversion would be used as expected if you were to compile a client package:
$ spack spec zlib %intel
If the version does not match, explicitly state the anticipated compiler version, e.g.:
$ spack spec zlib %firstname.lastname@example.org
if there are problems, review and correct the compiler’s
compilers.yamlentry, be it still in stub form or already complete (as it would be for a re-installation).
Install the new
studiopackage using Spack’s regular
installcommand. It may be wise to provide the anticipated compiler (see above) as an explicit concretization element:
$ spack install email@example.com %firstname.lastname@example.org
Follow the same steps as under Integrating external compilers to tell Spack the minutiae for actually using those compilers with client packages. If you placed a stub entry in a
compilers.yamlfile, now is the time to edit it and fill in the particulars.
paths:, give the full paths to the actual compiler binaries (
ifort, etc.) located within the Spack installation tree, in all their unsightly length [fn9].
To determine the full path to the C compiler, adapt and run:
$ find `spack location -i email@example.com` \ -name icc -type f -ls
If you get hits for both
ia32, you almost certainly will want to use the
ifortcompilers will be located in the same directory as
cflags:tokens to specify a suitable accompanying
gccversion to help pacify picky client packages that ask for C++ standards more recent than supported by your system-provided
To set the Intel compilers for default use in Spack, instead of the usual
%gcc, follow section Selecting Intel compilers.
Compiler packages like
intel-parallel-studio can easily be above 10 GB
in size, which can tax the disk space available for temporary files on
small, busy, or restricted systems (like virtual machines). The Intel
installer will stop and report insufficient space as:
==> './install.sh' '--silent' 'silent.cfg' ... Missing critical prerequisite -- Not enough disk space
As first remedy, clean Spack’s existing staging area:
$ spack clean --stage
then retry installing the large package. Spack normally cleans staging directories but certain failures may prevent it from doing so.
If the error persists, tell Spack to use an alternative location for temporary files:
df -hto identify an alternative location on your system.
Tell Spack to use that location for staging. Do one of the following:
Run Spack with the environment variable
TMPDIRaltered for just a single command. For example, to use your
$ TMPDIR="$HOME/spack-stage" spack install ....
This example uses Bourne shell syntax. Adapt for other shells as needed.
Alternatively, customize Spack’s
$ spack config edit config
config: build_stage: - /home/$user/spack-stage
Do not duplicate the
config:line if it already is present. Adapt the location, which here is the same as in the preceeding example.
Retry installing the large package.
To install library-only packages like
follow the steps given here.
For packages that contain a compiler, follow the previous section instead.
For pre-2017 product releases, review the section Configuring Spack to use Intel licenses.
Inspect the package spec. Specify an explicit compiler if necessary, e.g.:
$ spack spec firstname.lastname@example.org $ spack spec email@example.com %intel
Check that the package will use the compiler flavor and version that you expect.
Install the package normally within Spack. Use the same spec as in the previous command, i.e., as general or as specific as needed:
$ spack install firstname.lastname@example.org $ spack install email@example.com %intel@18
To prepare the new packages for use with client packages, follow Selecting libraries to satisfy virtual packages.
You can trigger a wall of additional diagnostics using Spack options, e.g.:
$ spack --debug -v install intel-mpi
--debugoption can also be useful while installing client packages (see below) to confirm the integration of the Intel tools in Spack, notably MKL and MPI.
.spack/subdirectory of an installed
IntelPackagewill contain, besides Spack’s usual archival items, a copy of the
silent.cfgfile that was passed to the Intel installer:
$ grep COMPONENTS ...intel-mpi...<hash>/.spack/silent.cfg COMPONENTS=ALL
If an installation error occurs, Spack will normally clean up and remove a partially installed target directory. You can direct Spack to keep it using
$ spack install --keep-prefix intel-mpi
You must, however, remove such partial installations prior to subsequent installation attempts. Otherwise, the Intel installer will behave incorrectly.
Finally, this section pertains to route 3 from the introduction.
Once Intel tools are installed within Spack as external or internal packages they can be used as intended for installing client packages.
Select Intel compilers to compile client packages, like any compiler in Spack, by one of the following means:
Request the Intel compilers explicitly in the client spec, e.g.:
$ spack install firstname.lastname@example.org%intel
Alternatively, request Intel compilers implicitly by concretization preferences. Configure the order of compilers in the appropriate
packages.yamlfile, under either an
all:or client-package-specific entry, in a
compiler:list. Consult the Spack documentation for Configuring Package Preferences and Concretization Preferences.
etc/spack/packages.yaml might simply contain:
packages: all: compiler: [ intel, gcc, ]
To be more specific, you can state partial or full compiler version numbers, for example:
packages: all: compiler: [ intel@18, intel@17, email@example.com, firstname.lastname@example.org, email@example.com, ]
Intel packages, whether integrated into Spack as external packages or
installed within Spack, can be called upon to satisfy the requirement of a
client package for a library that is available from different providers.
The relevant virtual packages for Intel are
In both integration routes, Intel packages can have optional
which alter the list of virtual packages they can satisfy. For Spack-external
packages, the active variants are a combination of the defaults declared in
Spack’s package repository and the spec it is declared as in
Needless to say, those should match the components that are actually present in
the external product installation. Likewise, for Spack-internal packages, the
active variants are determined, persistently at installation time, from the
defaults in the repository and the spec selected to be installed.
To have Intel packages satisfy virtual package requests for all or selected
client packages, edit the
packages.yaml file. Customize, either in the
all: or a more specific entry, a
providers: dictionary whose keys are
the virtual packages and whose values are the Spack specs that satisfy the
virtual package, in order of decreasing preference. To learn more about the
providers: settings, see the Spack tutorial for
Configuring Package Preferences
and the section
Example: The following fairly minimal example for
packages.yaml shows how
to exclusively use the standalone
intel-mkl package for all the linear
algebra virtual packages in Spack, and
intel-mpi as the preferred MPI
implementation. Other providers can still be chosen on a per-package basis.
packages: all: providers: mpi: [intel-mpi] blas: [intel-mkl] lapack: [intel-mkl] scalapack: [intel-mkl]
If you have access to the
intel-parallel-studio@cluster edition, you can
all: providers: mpi: [intel-parallel-studio+mpi] # Note: +mpi vs. +mkl blas: [intel-parallel-studio+mkl] lapack: [intel-parallel-studio+mkl] scalapack: [intel-parallel-studio+mkl]
With the proper installation as detailed above, no special steps should be required when a client package specifically (and thus deliberately) requests an Intel package as dependency, this being one of the target use cases for Spack.
The Math Kernel Library (MKL) is provided by several Intel packages, currently
intel-parallel-studio when variant
+mkl is active (it is by default)
and the standalone
intel-mkl. Because of these different provider packages,
mkl package is declared in Spack.
To use MKL-specific APIs in a client package:
Declare a dependency on
mkl, rather than a specific provider like
intel-mkl. Declare the dependency either absolutely or conditionally based on variants that your package might have declared:
# Examples for absolute and conditional dependencies: depends_on('mkl') depends_on('mkl', when='+mkl') depends_on('mkl', when='fftw=mkl')
MKLROOTenvironment variable (part of the documented API) will be set during all stages of client package installation, and is available to both the Spack packaging code and the client code.
To use MKL as provider for BLAS, LAPACK, or ScaLAPACK:
The packages that provide
mklalso provide the narrower virtual
scalapackpackages. See the relevant Packaging Guide section for an introduction. To portably use these virtual packages, construct preprocessor and linker option strings in your package configuration code using the package functions
.libsin conjunction with utility functions from the following classes:
Do not use constructs like
.prefix.lib, with Intel or any other implementation of
For example, for an AutotoolsPackage use
.libs.ld_flagsto transform the library file list into linker options passed to
def configure_args(self): args =  ... args.append('--with-blas=%s' % self.spec['blas'].libs.ld_flags) args.append('--with-lapack=%s' % self.spec['lapack'].libs.ld_flags) ...
.ld_flagswill return a string of multiple words, do not use quotes for options like
--with-blas=...because Spack passes them to
./configurewithout invoking a shell.
Likewise, in a MakefilePackage or similiar package that does not use AutoTools you may need to provide include and link options for use on command lines or in environment variables. For example, to generate an option string of the form
and to generate linker options (
-L<dir> -llibname ...), use the same as above,
Strictly speaking, versions from
intelintentionally does not have a
+mpivariant since it is meant to be small. The native installer will always add MPI runtime components because it follows defaults defined in the download package, even when
intel-parallel-studio ~mpihas been requested.
intel-parallel-studio +mpi, the class function :py:func:
"intel-mpi intel-imb"in a list of component patterns passed to the Intel installer. The installer will extend each pattern word with an implied glob-like
*to resolve it to package names that are actually present in the product BOM. As a side effect, this pattern approach accommodates occasional package name changes, e.g., capturing both
How could the external installation have succeeded otherwise?
According to Intel’s documentation, there is supposedly a way to install a product using a network license even when a FLEXlm server is not running: Specify the license in the form
INTEL_LICENSE_FILEenvironment variable. All other means of specifying a network license require that the license server be up.
Despite the name,
INTEL_LICENSE_FILEcan hold several and diverse entries. They can be either directories (presumed to contain
*.licfiles), file names, or network locations in the form
port@host(on Linux and Mac), with all items separated by “:” (on Linux and Mac).
Should said editor turn out to be
vi, you better be in a position to know how to use it.
Comment lines in FLEXlm files, indicated by
#as the first non-whitespace character on the line, are generally allowed anywhere in the file. There have been reports, however, that as of 2018,
USE_SERVERlines must precede any comment lines.
Spack’s close coupling of installed packages to compilers, which both necessitates the detour for installing
intel-parallel-studio, and largely limits any of its provided virtual packages to a single compiler, heavily favors recommending to install Intel Parallel Studio outside of Spack and declare it for Spack in
packages.yamlby a compiler-less spec.
With some effort, you can convince Spack to use shorter paths.
Altering the naming scheme means that Spack will lose track of all packages it has installed for you so far. That said, the time is right for this kind of customization when you are defining a new set of compilers.
The relevant tunables are:
Set the hash length in
install-path-scheme, also in
You will want to set the same hash length for tcl module files if you have Spack produce them for you, under
modules.yaml. Other module dialects cannot be altered in this manner.