| Note | ||||||
|---|---|---|---|---|---|---|
|
| No Format |
|---|
Lmod Warning: You have no modules loaded because the collection "default" is empty! |
then this applies to you. This is because that module set does not have the stack/legacy module in it because it did not exist at the time. Here is how to regenerate your old default module set.
| No Format |
|---|
module reset
module load $(module -t describe default |& xargs)
module save default |
The same process can be applied to any other module set that you have. Just replace "default" with the name of your module set. Again, note that this only applies to module sets that were created prior to April 28, 2021 that contain legacy modules in the set.
| 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.
...
| ||
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.
Like previous generation UI HPC systems, Argon uses environment modules for managing the shell environment needed by software packages. Argon uses LMod rather than the TCL modules used in previous generation UI HPC systems. More information about Lmod can be found in the Lmod: A New Environment Module System. Briefly, Lmod provides improvements over TCL modules in some key ways. One is that Lmod will automatically load and/or swap dependent environment modules when higher level modules are changed in the environment. It can also temporarily deactivate modules if a suitable alternative is not found, and can reactivate those modules when the environment changes back. We are not using all of the features that Lmod is capable of so the modules behavior should be very close to previous systems but with a more robust way of handling dependencies.
...
| No Format |
|---|
[gpjohnsn@argon-login-2 ~]$ module load python/2.7.15
[gpjohnsn@argon-login-2 ~]$ module list
Currently Loaded Modules:
1) bzip2/1.0.6 9) fontconfig/2.12.1 17) ncurses/6.0 25) grib_api/1.19.0 33) pcre/8.40
2) glib/2.51.1 10) freetype/2.7.1 18) instantclient/12.2.0.1.0 26) hdf5/1.8.18 34) proj/4.9.3
3) pkg-config/0.29.1 11) cfitsio/3.410 19) jasper/1.900.1 27) jpeg/9b 35) readline/7.0
4) snappy/1.1.4 12) curl/7.52.1 20) libgeotiff/1.4.2 28) libffi/3.2.1 36) sqlite/3.16.2
5) c-blosc/1.11.2 13) szip/2.1.1 21) libiconv/1.15 29) libpng/1.6.28 37) tiff/4.0.7
6) expat/2.2.0 14) hdf/4.2.12 22) unixODBC/2.3.4 30) lzo/2.09 38) zeromq/4.2.5
7) xz/5.2.3 15) jdk/8u121 23) gdal/2.1.3 31) netcdf/4.4.1.1 39) zlib/1.2.11
8) libxml2/2.9.4 16) libaio/0.3.111 24) geos/3.6.1 32) openjpeg/2.1.2 40) python/2.7.15
[gpjohnsn@argon-login-2 ~]$ module swap python/2.7.15 python/3.6.4
[gpjohnsn@argon-login-2 ~]$ module list
Currently Loaded Modules:
1) bzip2/1.0.6 9) fontconfig/2.12.1 17) ncurses/6.0 25) grib_api/1.19.0 33) pcre/8.40
2) glib/2.51.1 10) freetype/2.7.1 18) instantclient/12.2.0.1.0 26) hdf5/1.8.18 34) proj/4.9.3
3) pkg-config/0.29.1 11) cfitsio/3.410 19) jasper/1.900.1 27) jpeg/9b 35) readline/7.0
4) snappy/1.1.4 12) curl/7.52.1 20) libgeotiff/1.4.2 28) libffi/3.2.1 36) sqlite/3.16.2
5) c-blosc/1.11.2 13) szip/2.1.1 21) libiconv/1.15 29) libpng/1.6.28 37) tiff/4.0.7
6) expat/2.2.0 14) hdf/4.2.12 22) unixODBC/2.3.4 30) lzo/2.09 38) zeromq/4.2.5
7) xz/5.2.3 15) jdk/8u121 23) gdal/2.1.3 31) netcdf/4.4.1.1 39) zlib/1.2.11
8) libxml2/2.9.4 16) libaio/0.3.111 24) geos/3.6.1 32) openjpeg/2.1.2 40) python/3.6.4 |
Unloading modules
| No Format |
|---|
[gpjohnsn@neon-login-0-1 ~]$ module unload python/3.6.4 |
Unloading an environment module will undo the changes that module made to the environment, restoring any variables set to their previous values.
Writing your own module files is not covered here but they are not that difficult to create. If there is some environment variable that should be set for a software package that we missed please send a note to research-computing@uiowa.edu.
Module sets
Lmod provides a mechanism to save sets of modules that can then be restored. This is a convenient way to switch out a whole bunch of modules to change the environment quickly. If you typically need to load several modules, module sets provides a better mechanism than loading individual module files. The reasons are that
- Only one command is needed
- The same command can be used at any time
- Restoring a module set runs a
module purgewhich will ensure that the environment, at least the part controlled by modules, is predictable.
To use this, simply load the modules that you want to have loaded as a set. Then run the following command.
| No Format |
|---|
module save |
That will save the loaded modules as the default set. To restore that run
| No Format |
|---|
module restore |
Note that the above command will restore your modules to the system default if you do not have a default module set saved. In addition to saving/restoring a default set you can also assign a name to the collection and save multiple collections.
| No Format |
|---|
module save mymodules
module restore mymodules |
If you have several different environments needed for different job types then saving a module set for each job type can save time and ensure consistency. There is also a technical reason to use the module save/restore feature as opposed to individual modules that involves how the LD_LIBRARY_PATH environment variable is handled at shell initialization.
| Expand | ||
|---|---|---|
| ||
One of the things that environment modules sets up is the $LD_LIBRARY_PATH. However, when a setuid/setgid program runs it unsets $LD_LIBRARY_PATH for security reasons. One such setuid program is the duo login program that runs as part of an ssh session. This will leave you with a partially broken environment as a module is loaded, sets $LD_LIBRARY_PATH but then has it get unset before shell initialization is complete. This is worked around on previous systems by always forcing a reload of the environment module but this is not very efficient. Use module restore to load saved modules if you are loading modules from your ~/.bashrc or similar. |
Other than the above items, and some other additional features, the environment modules controlled by Lmod should behave very similarly to the TCL modules on previous UI HPC systems.
Default module set
The default module set generally represents a set of modules that meet all of your needs and/or provide a starting point for loading other modules. This is particularly important for Argon, which uses independent stacks of software. Once you have your workflow worked out you can save a default set of modules, as described above. That set will include a specific "stack" module as well. This allows you to maintain consistency of the environment for your jobs.
| Info |
|---|
After the April 2021 HPC maintenance, the default module set, if you have one, will be loaded by default. Since your default module set will be loaded automatically, you should remove a |
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.
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
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 |
...
geos/3.6.1 32) openjpeg/2.1.2 40) python/3.6.4 |
Unloading modules
| No Format |
|---|
[gpjohnsn@neon-login-0-1 ~]$ module unload python/3.6.4 |
Unloading an environment module will undo the changes that module made to the environment, restoring any variables set to their previous values.
Writing your own module files is not covered here but they are not that difficult to create. If there is some environment variable that should be set for a software package that we missed please send a note to research-computing@uiowa.edu.
Module sets
Lmod provides a mechanism to save sets of modules that can then be restored. This is a convenient way to switch out a whole bunch of modules to change the environment quickly. If you typically need to load several modules, module sets provides a better mechanism than loading individual module files. The reasons are that
- Only one command is needed
- The same command can be used at any time
- Restoring a module set runs a
module purgewhich will ensure that the environment, at least the part controlled by modules, is predictable.
To use this, simply load the modules that you want to have loaded as a set. Then run the following command.
| No Format |
|---|
module save |
That will save the loaded modules as the default set. To restore that run
| No Format |
|---|
module restore |
Note that the above command will restore your modules to the system default if you do not have a default module set saved. In addition to saving/restoring a default set you can also assign a name to the collection and save multiple collections.
| No Format |
|---|
module save mymodules
module restore mymodules |
If you have several different environments needed for different job types then saving a module set for each job type can save time and ensure consistency. There is also a technical reason to use the module save/restore feature as opposed to individual modules that involves how the LD_LIBRARY_PATH environment variable is handled at shell initialization.
| Expand | ||
|---|---|---|
| ||
One of the things that environment modules sets up is the $LD_LIBRARY_PATH. However, when a setuid/setgid program runs it unsets $LD_LIBRARY_PATH for security reasons. One such setuid program is the duo login program that runs as part of an ssh session. This will leave you with a partially broken environment as a module is loaded, sets $LD_LIBRARY_PATH but then has it get unset before shell initialization is complete. This is worked around on previous systems by always forcing a reload of the environment module but this is not very efficient. Use module restore to load saved modules if you are loading modules from your ~/.bashrc or similar. |
Other than the above items, and some other additional features, the environment modules controlled by Lmod should behave very similarly to the TCL modules on previous UI HPC systems.
Default module set
The default module set generally represents a set of modules that meet all of your needs and/or provide a starting point for loading other modules. This is particularly important for Argon, which uses independent stacks of software. Once you have your workflow worked out you can save a default set of modules, as described above. That set will include a specific "stack" module as well. This allows you to maintain consistency of the environment for your jobs.
| Info |
|---|
After the April 2021 HPC maintenance, the default module set, if you have one, will be loaded by default. Since your default module set will be loaded automatically, you should remove a |
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.
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.