| Note | ||
|---|---|---|
| ||
old environment modules moved to "legacy" stack The original set of environment modules on Argon have been available by default and their availability was not removed upon loading one of the newer stack modules. As the software stacks have grown, in size and complexity, that introduces more opportunities for module collisions in an environment. With this change, the old modules will be made available as a distinct stack, just like the newer stacks. Thus, it will no longer be possible to have the legacy modules available at the same time in a session as newer modules. The modules will still be available, they will just be swapped out with other stacks. For now, the legacy modules stack will be loaded by default if you do not have a default module set. However, if you have a default module set that was generated prior to this change that consisted of legacy modules then you will need to regenerate the set. If you see the following message:
then this applies to you. |
| Table of Contents |
|---|
...
| ||
If you have a default module set, it will be loaded at login time. Otherwise, a system default will be loaded. The system default has historically been the "legacy" stack. Beginning with the Fall 2022 Maintenance, November 2, 2022, the system default stack will be set to load the 2021.1 stack. If you need to use modules from the legacy stack then it will need to be explicitly loaded before loading module files.
Note that the naming scheme of the legacy stack is different so the names of modules that you wish to use may have changed, typically to all lower case but hyphenation could also be different. More information on the software stacks can be found on the Argon Software List page. |
| Table of Contents |
|---|
The HPC cluster system at the University of Iowa has many software packages installed and sometimes different versions of the same package. These software programs are installed in several different directories. These software packages are made available for use via environment modules. See Argon Software List - HPC Documentation - UIowa Wiki for the software installed on Argon.
...
Note that if there are multiple versions in the module directory and no default is listed, the modules program will try to load the latest version that it finds. This may not be what you want. To avoid surprises, you should specify the entire module name and version. If there is only one version in a module directory then the module version does not have to be specified, it will load the only version it finds. However, you should still specify the entire name and version to avoid surprises when a second version is added at a later point in time. It is often the case that you need to reference the path to the software managed by the module, such as specifying directory paths while compiling software. There is a special variable set in every module file that points to the root directory of the installation. The nomenclature pattern is like ROOT_MODULENAME. For example, the zlib module sets $ROOT/1.2.11 module sets this:
ROOT_ZLIB=/opt/apps/zlib/1.2.11
...
| Info |
|---|
After the April 2021 HPC maintenance, the default module set, if you have one, will be loaded by default. If there is no default module set, a default stack module will be loaded. Since your default module set will be loaded automatically, you should remove a |
| Warning |
|---|
If you had a default module stack that consisted of just legacy modules prior to the April 2021 HPC maintenance you will need to regenerate the set. This is because the legacy modules are now also part of a stack and that will not be reflected in the set file created prior to the April 2021 HPC maintenance. |
As the default stack module loaded at startup is changed over time, having a default module set Having a default module set ensures that your module environment will stay the same over time. You can then verify your jobs with a new stack and then update the default module set when you are ready.
Using environment modules with SGE jobs and qlogin
For qsub jobs, if you have not overridden the default SGE parameters then the entire environment is passed to the job. This is because the -V qsub flag is set in the default request. Since environment modules set up the environment then the environment set up by the modules will be passed. Since the list of the loaded modules is also part of the environment then the list of loaded modules will be passed as well. However, the above does not apply to qlogin sessions as that creates a fresh environment. See the Qlogin for Interactive Sessions - HPC Documentation - UIowa Wiki page for more information.
However, the recommendation for qsub jobs is to include the module load statements in your job script and not depend on the environment passed in from the submit host. That way, setting up the needed environment is part of the job and is thus more reproducible. If depending on loading modules before qsub then you have to remember to get the environment set up before job submission. When loading modules in your job script, it is best to use module sets. If you would prefer to make sure that the module loads are more explicit then make sure to do a
| No Format |
|---|
module purge |
...
Resetting modules
After you have loaded modules over time you may want to clean up the environment a bit. You can unload individual modules but often you will simply want to reset. You could run module purge to clean out all modules but that will also remove the stack module. You would then need to reload a stack module to make program modules available again.
| No Format |
|---|
module purge
module load stack/??? |
Using module purge is probably not what you want. If you have default module set then you can reset to that by simply running
| No Format |
|---|
module restore |
If you wish to clear out the environment even more then you could run
| No Format |
|---|
module restore system
or
module reset |
to reset to the default system modules, ignoring your default module set. If you do not have a default module set then any of the following
| No Format |
|---|
module restore
module restore system
module reset |
will restore the module state to the system default.
Using environment modules with SGE jobs and qlogin
qlogin
For qsub jobs, if you have not overridden the default SGE parameters then the entire environment is passed to the job. This is because the -V qsub flag is set in the default request. Since environment modules set up the environment then the environment set up by the modules will be passed. Since the list of the loaded modules is also part of the environment then the list of loaded modules will be passed as well. However, the above does not apply to qlogin sessions as that creates a fresh environment. See the Qlogin for Interactive Sessions - HPC Documentation - UIowa Wiki page for more information.
standard qsub
The recommendation for "standard" qsub jobs is to include the module load statements in your job script and not depend on the environment passed in from the submit host. That way, setting up the needed environment is part of the job and is thus more reproducible. If depending on loading modules before qsub then you have to remember to get the environment set up before job submission. When loading modules in your job script, it is best to use module sets. If you would prefer to make sure that the module loads are more explicit then make sure to do a
| No Format |
|---|
module purge |
before any "module load ..." commands.
High Throughput Computing (HTC) and/or High Volume Computing (HVC)
If your jobs are High Throughput Computing (HTC) and/or High Volume Computing (HVC) jobs, it is advised to not load modules per job but rather use the submission environment. The reason is that many thousands of jobs will need to do a large number of module loads in relatively short time frames, which could cause failures. For HTC/HVC type jobs, carefully load the modules that you will need for the jobs prior to job submission. The loaded modules are part of the environment so they will get passed to the job, unless you have overridden the default. Do not load any modules or module sets in the job script, although you may want to have comments regarding what modules are in use. Do not load any modules or module sets in your ~/.bashrc file. Finally, disable the default module set if you have one.