Page History
| Panel | ||
|---|---|---|
| ||
|
Overview
Gadi uses Environment Modules to customise user shell environment. The Environment Modules package is a tool that simplifies shell initialisation and allow users to modify their environments using provided commands like `module load` and `module unload` during the session with modulefiles.
...
Since there are going to be multiple versions of the same application installed on Gadi and, in a certain shell, only one can be used, it is important to tell that all other module versions conflict with the current one. In the above example, `conflict python3` instructs the `module load` command not to load any other python3 modules if the module python3/3.7.4 has been already loaded to the current shell.
Load Modulefiles of a Specific Version of Applications
Users are encouraged to load modulefiles with their fullnames, <app>/<version>, to remove ambiguity and improve the reproducibility of works on Gadi, especially in job submission scripts and their private modulefiles. Because most of software applications Gadi keeps centrally on /apps are expected to have multiple versions available and we keep installing newly released versions, it is the best to load modulefiles with the specific version to avoid using a wrong version when resuming/replicating previous works on Gadi. For example,
...
We always set the default version of the application to the most recent or the most reliable version, therefore, it is expected that `module load openmpi` loads different versions of the openmpi application overtime. If your binary is compiled with openmpi/3.1.4 and the job submission script has `module load openmpi` in it, it may run at the time version 3.1.4 is still the default version, but it could fail 3 months later when the newer version is installed and set to the default version for openmpi applications.
Module Sub-commands
| Command | Notes |
|---|---|
| module list | List all loaded modules in the current shell environment |
| module purge | Remove all modulefiles from the current shell environment. |
| module load <app>/<version> | Load modulefile <app>/<version> into the current shell environment. |
| module unload <app> | Remove modulefile for application <app> in the current shell |
| module avail <str> | List all available modulefiles in the current MODULEPATH whose pathname starts with <str>. All directories in the MODULEPATH are recursively searched for the target files that contain the modulefile magic cookie. If no argument <str> is given, all the modulefiles are displayed. |
| module whatis <app>/<version> | Display the information set up by the module-whatis commands inside the modulefile <app>/<version>. |
User Defined Modules
Users can edit their own modulefiles for different versions of applications in their home folder ~/privatemodules. Once the modulefile <modulefile> is created in the `privatemodules` folder, first run
| Code Block | ||
|---|---|---|
| ||
$ module load use.own |
to include `~/privatemodules` in the search path MODULEPATH and prepare the reference counter to start tracking it, then run `module load <modulefile>` as you would load other modulefiles for applications installed on /apps.
...
| Code Block |
|---|
#%Module1.0 prereq python3/3.7.4 prereq tensorflow/2.0.0 prepend-path PYTHONPATH [envgetenv HOME]/envs/nsl/1.1.0/lib/python3.7/site-packages |
...
| Code Block |
|---|
$ module load use.own $ module load python3/3.7.4 $ module load tensorflow/2.0.0 $ module load nsl/1.1.0 $ python3 >> import tensorflow as tf >> import neural-_structured-_learning as nsl >> nsl.__versionfile__ '~/envs/nsl/1.1.0/lib/python3.7/site-packages/neural_structured_learning/__init__.py' |
Overview
Content Tools