|
HPC cluster systems typically have a large number of software packages installed. Often there will be several versions provided for a package where it will be necessary for a user to choose between them. Equally, two different packages may clash with each other: for example, the commands for Intel MPI and Open MPI would overlap if simultaneously installed.
|
|
HPC cluster systems typically have a large number of software packages installed. Often there will be several versions provided for a package where it will be necessary for a user to choose between them. Equally, two different packages may clash with each other: for example, the commands for Intel MPI and Open MPI would overlap if simultaneously installed.
|
|
|
|
|
|
|
|
[[_TOC_]]
|
|
|
|
|
|
## Everyday use
|
|
## Everyday use
|
|
|
|
|
|
On `turing` node we use the modules package to manage the user environment for the installed packages. This makes it simple to use different packages or switch between versions of the same package without conflicts.
|
|
On `turing` node we use the modules package to manage the user environment for the installed packages. This makes it simple to use different packages or switch between versions of the same package without conflicts.
|
... | @@ -54,3 +56,14 @@ Currently Loaded Modulefiles: |
... | @@ -54,3 +56,14 @@ Currently Loaded Modulefiles: |
|
```
|
|
```
|
|
|
|
|
|
Sometimes we stick with an older version as the default, since a lot of people may still be using that version, and will require checking of scripts and communication to all users of the package. For popular packages, we rarely make the newest version the default one, due to the potential for introduction of incompatibilities or inconsistent results.
|
|
Sometimes we stick with an older version as the default, since a lot of people may still be using that version, and will require checking of scripts and communication to all users of the package. For popular packages, we rarely make the newest version the default one, due to the potential for introduction of incompatibilities or inconsistent results.
|
|
|
|
|
|
|
|
## Dependencies
|
|
|
|
|
|
|
|
Some of the software provided by a module may in turn depend on software provided by another module. For example, a `aster` tool implementation will require a bundle of tools and libraries needed. These cases may be handled by module dependencies. On Liger, the module system is set up to load dependent modules automatically rather than requiring users to satisfy the dependencies first. We see that loading this ASTER module also loads `python, lapack, intel, gcc`
|
|
|
|
|
|
|
|
```
|
|
|
|
$ module load aster
|
|
|
|
$ module list
|
|
|
|
Currently Loaded Modulefiles:
|
|
|
|
1) gcc/4.9.3 2) lapack/3.6.1/gcc/4.9.3 3) python/2.7.12/gcc/4.9.3 4) intel/2015.3.187 5) aster/11.0.10
|
|
|
|
``` |