Using Environment Modules with Intel Development Tools

What are Environment Modules

The Environment Modules utility allows dynamic modification of a user environment (shell environment variables such as PATH, LD_LIBRARY_PATH, etc). The Environment Module utility works with a set of system or user configure "modulefiles" which specify the necessary environment settings necessary to use a particular development tool or toolset, such as Intel® Parallel Studio XE.   More information on the Environment Utility and modulefiles can be found here

Each modulefile contains the information needed to configure the shell environment for a specific version of a development tool or toolset. Once the Modules utility has a modulefile configured for a particular tool, typically by the system administrator, the system user's environment can be modified using the 'module' command which interprets modulefiles. Typically modulefiles instruct the module command to alter or set shell environment variables such as PATH, MANPATH, etc. modulefiles may be shared by many users on a system and users may have their own collection to supplement or replace the shared modulefiles.  This utility and collection of modulefiles allows users to test code with different versions of the tools such as compilers quickly and easily. 

Environment modules give you control over your environment by keeping track of what variables are changed giving you the ability to remove those same entries, preventing variable bloat.

Supported Platforms

Linux* and OS X*

How to create a module file for Intel Software Development tools

First, install the Intel Development Tools on your system or cluster. Note that the Intel Development Tools ( Parallel Studio XE, Cluster Edition, Composer Edition, etc) do NOT come packaged with modulefiles.  Instead the bash or tcsh/csh script files, named '*' or '*vars.csh' (VARS scripts) are installed to the installation 'bin' directory (directories).  To use the tools, first of all set up the environment using the 'source' command. i.e.
source [install-dir]composer_xe_2015.x.yyy/bin/ intel64

There are two ways you can create modulefiles, the obvious way is by hand, using the provided script files *vars.[sh | csh] as reference.  DO NOT DO IT THIS WAY, the VARS script files usually call a series of other dependent scripts.  Also some scripts take arguments, such as the '' scripts, while others do not.  Unraveling this nest of scripts is nearly impossible and error prone.

Alternatively you can use a utility 'env2' to automate the process.  The 'env2' utility executes a script, capturing the changes it makes to the environment, and echoes those env vars and settings in a format suitable for a modulefile.  This output can be captured to create your module file. in order to get the correct information you will need to redirect the output from stdout to a file. 

The 'env2' utility can be found at

Creating a module file for any Intel Development Tool:

  1. First you place a special comment at the beginning of the file so that module will recognize it as a module file with following command:
    echo "#%Module" > my_module_file
  2. then you will need to use the env2 command like below, for example:
    perl env2 -from bash -to modulecmd "[install-dir]/parallel_studio_xe_201m.0.nnn/ <intel64|ia-32>" >> my_module_file 
    This will create a module file that has all the correct information need to run the compiler and tools correctly. 
  3. Now following the 'module' instructions to use the compiler tools through module file.

Note:You can find more information about Environment modules here


For more complete information about compiler optimizations, see our Optimization Notice.


Junqueira, Carlos's picture

I have tried to build my module using env2 without any success.

Actually the env2 script does not return anything using the command line as suggested by intel, which in my case is:

perl env2 -from bash -to modulecmd "/opt/intel/parallel_studio_xe_2017/bin/ intel64" >> my_module_file

I would love to know what i'm doing wrong....


Raffy, Guillaume's picture

FYI : the simple solution that I proposed on 12/22/2016 - 06:29 doesn't actually work properly : env2 issues append-path commands instead of prepend-path commands, as there's an ambiguity : the same path finds itself at the same time at the beginning and at the end of the environment variable.

I managed to get env2 output proper modulecmd instructions by adding environment variables with dummy content prior to calling env2. These environment variables prevent to enter lines such as "NLSPATH="$INSTALL_DIR/compiler/lib/locale/en_US/%N"; export NLSPATH":  for example, declaring NLSPATH=dummy prior to calling env2 then causes env2 to issue prepend-path on NLSPATH instead of setenv

In order to automate this process, I had to perform some scripting to automatically detect what environment variables creates. Here's the code that does it :

local strEnvComparerFilePath="./envcomparer.bash"
echo "#!/bin/bash" > "$strEnvComparerFilePath"
echo "env | awk -F= '{ print \$1}' | sort > $strTmpDir/env_before.txt" >> "$strEnvComparerFilePath"
echo "source intel64" >> "$strEnvComparerFilePath"
echo "env | awk -F= '{ print \$1}' | sort > $strTmpDir/env_after.txt" >> "$strEnvComparerFilePath"

chmod a+x "$strEnvComparerFilePath"

# temporarily disable the unbound variables check because some scripts dereference variables that are not necessarily defined and that's ok
set +o nounset
set -o nounset

diff "$strTmpDir/env_before.txt" "$strTmpDir/env_after.txt" | grep '> ' | sed 's/> //' > './new-env-vars.txt'

# create dummy environment variables so that env2 can properly detect append-path operations
local strNewVarName=''
for strNewVarName in $(cat ./new-env-vars.txt)
    export $strNewVarName='dummy'

# after this env2 will generate proper modulecmd instructions
perl env2 -from bash -to modulecmd "[install-dir]/ intel64" >> my_module_file

Hope this helps

Raffy, Guillaume's picture

This solution involving env2 doesn't actually generate a proper module file. The generated module file does seem to work as long as it's the only module being used. However, the generated module might wrongly redefine variables such as LD_LIBRARY_PATH instead of appending paths to it.

The reason for this is that env2 is not clever enough to decide when to issue setenv commands or prepend-path commands. In intel's ifortvars, for example, there are lots of things like :

   if [ -z "${NLSPATH}" ]
       NLSPATH="$INSTALL_DIR/compiler/lib/locale/en_US/%N"; export NLSPATH
       NLSPATH="$INSTALL_DIR/compiler/lib/locale/en_US/%N:${NLSPATH}"; export NLSPATH

If NLSPATH exists before calling env2, then the second branch (else condition) is entered, env2 detects a prepend operation and rightfully issues a prepend-path command. However, if  NLSPATH doesn't exist before calling env2, then the first branch (if condition) is entered, env2 detects a simple assignment, and wrongfully issues a setenv command.

There's a simple solution for this problem though (it does work for me but it's not guaranteed to work with all scripts) : just run the intel script once before calling it again via env2 : this will create the path-like environment variables that are missing, and will cause env2 to detect prepend operations.


Add a Comment

Have a technical question? Visit our forums. Have site or software product issues? Contact support.