What are Environment Modules?
The Environment Modules package provides for the dynamic modification
of a user's environment via modulefiles. Each modulefile contains the information needed to configure the
shell for an application. Once the Modules package is initialized,
the environment can be modified on a per-module basis 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.
Modules can be loaded and unloaded dynamically and atomically, in an clean fashion. All popular shells are supported, including bash, ksh, zsh, sh, csh, tcsh, as well as some scripting languages such as perl and python.
Modules are useful in managing different versions of applications. Modules can also be bundled into metamodules that will load an entire suite of different applications.
Modules can be loaded and unloaded dynamically and atomically, in an clean fashion. All popular shells are supported, including bash, ksh, zsh, sh, csh, tcsh, as well as some scripting languages such as perl and python.
Modules are useful in managing different versions of applications. Modules can also be bundled into metamodules that will load an entire suite of different applications.
Quick Examples
Here is an example of loading a module on a Linux machine under bash.
Some tips/notes from work:
Yeah, it's best if you start with a clean module set:
module purge
And then load the modules you need for a specific job. It's for that reason that we advise against loading modules automatically in .profile and other login scripts.
In this case, you probably want:
module purge
module load license_intel intel/12.1 hdf5 netcdf4/4.2.1
Then your job /should/ find the libnetcdf file it is looking for.
We would love to make module loading easier by having netcdf4/4.2.1 automatically verify the right modules are loaded, and that can be done, but then it leads to unpredictable behavior (ie: loading one module is making a mess of things, or unloading it unloads everything else that it preloads, etc).
- % module load gcc/3.1.1
- % which gcc
- /usr/local/gcc/3.1.1/linux/bin/gcc
- % module switch gcc gcc/3.2.0
- % which gcc
- /usr/local/gcc/3.2.0/linux/bin/gcc
- % module unload gcc
- % which gcc
- gcc not found
- tardis-> module load gcc/3.1.1
- tardis-> which gcc
- /usr/local/gcc/3.1.1/sunos5.6/bin/gcc
Some tips/notes from work:
Yeah, it's best if you start with a clean module set:
module purge
And then load the modules you need for a specific job. It's for that reason that we advise against loading modules automatically in .profile and other login scripts.
In this case, you probably want:
module purge
module load license_intel intel/12.1 hdf5 netcdf4/4.2.1
Then your job /should/ find the libnetcdf file it is looking for.
We would love to make module loading easier by having netcdf4/4.2.1 automatically verify the right modules are loaded, and that can be done, but then it leads to unpredictable behavior (ie: loading one module is making a mess of things, or unloading it unloads everything else that it preloads, etc).
No comments:
Post a Comment