Module versions get a facelift

If you’re a Sherlock user who often needs to load specific module versions, but don’t care or can’t remember specific minor version numbers, you’re in luck!

Starting today, Sherlock allows loading modules via an extended default system which will automatically load the best available version, based on what users request.

Too many versions

There are too many version numbers to remember. For instance, take CUDA:

$ ml av cuda

--------------- devel -- compilers, MPI, languages, libs ---------------
cuda/8.0.61 (g) cuda/9.2.148 (g)
cuda/9.0.176 (g,D) cuda/10.0.130 (g)
cuda/9.1.85 (g) cuda/10.1.105 (g)
cuda/9.2.88 (g)

Where:
g: GPU support
D: Default Module

There are a number of versions of the CUDA module, that follow the semantic versioning scheme of major.minor.patch version numbers.

This is great, but in practice, most of us only care about the major version number. Sometimes major.minor, but mostly, we just want to get the latest patch version. Without having to look it up, let alone remember it.

Extended defaults

Enter extended defaults, a new module mechanism to simplify all of this.

Starting now, you can simply load a module using its major version number, and you’ll get the best module that matches your request.

For instance:

$ ml cuda/10.1

will automatically load cuda/10.1.105

If you want to specific a minor version, but don’t care about the patch number, you can too:

$ ml cuda/9.2

will load cuda/9.2.148

Finally, if you don’t specify any version at all, the highest version number will automatically be loaded, unless a default is defined (noticeable with the D flag in ml av output) which will be used instead.

We hope this will make things easier, and if you have any question, don’t hesitate to reach out at srcc-support@stanford.edu