Exercises 2: Modules on LUMI¶

See the instructions to set up for the exercises.

Exercises on the use of modules¶

The Cray CPE comes with a number of differently configured HDF5 libraries.

a. Which ones can you find?

b. Can you find more documentation about those libraries?
Click to see the solution
```
module spider HDF5
```
or
```
module spider hdf5
```
can produce a lot of output on the system. It will show you three modules though (but this might be under "Other possible matches") that have cray- in their name: cray-hdf5, cray-hdf5-parallel and cray-netcdf-hdf5parallel. The first two of these really provide HDF5 configured in two different ways. The third one is another library using HDF5 as a backend. The other hdf5 modules that you might see are modules generated by Spack (see a little bit in the next session).

If you want more information about the cray-hdf5 module, you can try
```
module spider cray-hdf5
```
and then for a specific version
```
module spider cray-hdf5/1.12.2.7
```
and see that there is not much information. Even worse, the help of this particular version refers to the release info but mentions the wrong filename. The path is correct, but the file where the info is, is
```
/opt/cray/pe/hdf5/1.12.2.7/release_info.md
```
(and the same holds true for cray-hdf5-parallel)
The Bison program installed in the OS image is pretty old (version 3.0.4) and we want to use a newer one. Is there one available on LUMI?
Click to see the solution.
```
module spider Bison
```
tells us that there are indeed newer versions available on the system.

The versions that have a compiler name (usually gcc) in their name followed by some seemingly random characters are installed with Spack and not in the CrayEnv or LUMI environments.

To get more information about Bison/3.8.2 if you didn't get it already with the previous command:
```
module spider Bison/3.8.2
```
tells us that Bison 3.8.2 is provided by a couple of buildtools modules and available in all partitions in several versions of the LUMI software stack and in CrayEnv.

Alternatively, in this case
```
module keyword Bison
```
would also have shown that Bison is part of several versions of the buildtools module.

The module spider command is often the better command if you use names that with a high likelihood could be the name of a package, while module keyword is often the better choice for words that are more a keyword. But if one does not return the solution it is a good idea to try the other one also.
A problem with too much different versions of software on the system...

If you tried
```
module spider bison
```
to look for Bison, you wouldn't have found the version in buildtools which is the main version of Bison on LUMI in the main supported software stack (see the next presentation), but only versions that are currently on the system and installed through Spack.
The htop command is a nice alternative for the top command with a more powerful user interface. However, typing htop on the command line produces an error message. Can you find and run htop?
Click to see the solution.

We can use either module spider htop or module keyword htop to find out that htop is indeed available on the system. With module keyword htop we'll find out immediately that it is in the systools modules and some of those seem to be numbered after editions of the LUMI stack suggesting that they may be linked to a stack, with module spider you'll first see that it is an extension of a module and see the versions. You may again see some versions installed with Spack.

Let's check further for htop/3.2.1 that should exist according to module spider htop:
```
module spider htop/3.2.1
```
tells us that this version of htop is available in all partitions of LUMI/22.08 and LUMI/22.06, and in CrayEnv. Let us just run it in the CrayEnv environment:
```
module load CrayEnv
module load systools/22.08
htop
```
(You can quit htop by pressing q on the keyboard.)
LUMI now offers Open OnDemand as a browser-based interface to LUMI that enables running some graphical programs through a VNC server. But for users who do not want to use Open OnDemand apps, there is currently another way to start a VNC server (and that was the way to use graphical programs before the Open OnDemand interface was ready and may still be relevant if Open OnDemand would fail after a system update). Can you find the tool on LUMI, and if so, how can we use it?
Click to see the solution.

module spider VNC and module keyword VNC can again both be used to check if there is software available to use VNC. Both will show that there is a module lumi-vnc in several versions. If you try loading the older ones of these (the version number points at the date of some scripts) you will notice that some produce a warning as they are deprecated. However, when installing a new version we cannot remove older ones in one sweep, and users may have hardcoded full module names in scripts they use to set their environment, so we chose to not immediate delete these older versions.

One thing you can always try to get more information about how to run a program, is to ask for the help information of the module. For this to work the module must first be available, or you have to use module spider with the full name of the module. We see that version 20230110 is the newest version of the module, so let's try that one:
```
module spider lumi-vnc/20230110
```
The output may look a little strange as it mentions init-lumi as one of the modules that you can load. That is because this tool is available even outside CrayEnv or the LUMI stacks. But this command also shows a long help test telling you how to use this module (though it does assume some familiarity with how X11 graphics work on Linux).

Note that if there is only a single version on the system, as is the case for the course in May 2023, the module spider VNC command without specific version or correct module name will already display the help information.