HPCwiki - Recent changes [en]

Software Overview

Haars0011 — Tue, 16 Jun 2026 14:31:16 GMT

Phase 1 § 5 P1.5.1 / Phase 2 P2.9: software landscape hub. Note: General overview NOT consumed here (it is GUI/OOD content reserved for § 7 Portal Overview); Modules content already lives in Environment Modules. (via create-page on MediaWiki MCP Server)

New page

Anunna offers software in several ways, depending on whether you need a ready-made package, your own custom setup, or a commercial product. This page is a map of the options and points to the page that covers each in detail.

== Pre-installed software: modules ==

Most software on the cluster is provided as [[Environment Modules | environment modules]], organised into yearly "buckets". Load a bucket and then the software you need — the module sets up your environment so the right versions of the program and its dependencies are available. Use <code>module key <name></code> to search for a package, and request additions through [[Requesting New Software]].

== Languages ==

The common scientific languages have their own pages covering the provided modules, how to manage packages, and how to run them in jobs and notebooks:

* [[Python]] — modules, virtual environments, Miniforge, and Jupyter kernels.
* [[R]] — modules, local package libraries, batch jobs, and parallel R.
* [[Julia]] — modules and package management.

== Your own software ==

If a package is not available as a module, you have a few options:

* [[Installing Personal Software]] — shell configuration, environment variables, and installing small tools into your own space.
* [[Apptainer]] — package an application and all its dependencies into a portable container. This is the most reproducible way to bring in software that is awkward to install directly.

== Commercial and licensed software ==

Some packages are commercial and restricted to eligible users — see [[Licensed Software]] for what is available and how to get access.

== Graphical applications ==

Several applications are available through your web browser via the Apps Portal, without using the command line — see [[General overview | the Apps Portal overview]].

== Requesting new software ==

If what you need is not available anywhere above, [[Requesting New Software | submit a software request]].

== See also ==

* [[Environment Modules]]
* [[Installing Personal Software]]
* [[Licensed Software]]
* [[Requesting New Software]]

CLC

Haars0011 — Tue, 16 Jun 2026 14:24:11 GMT

Phase 1 § 5 P1.5.8: typo/error fixes only (to to → to, readonly → read-only, drop stray username example, remove blank lines) (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 14:24, 16 June 2026
Line 24:		Line 24:
	Port: 6200		Port: 6200

	Username : your WUR username ~~(not haars001)~~		Username: your WUR username

	[[File:CLC License server credentials.png\|400px\|CLC license server connection credentials]]		[[File:CLC License server credentials.png\|400px\|CLC license server connection credentials]]
Line 45:		Line 45:

	On the old server there was about 100TB of data in use.		On the old server there was about 100TB of data in use.
	To force everybody to think about what they need for their day to day work, it was decided to make the old data available ~~readonly~~ through the OLD_[groupname] folders.		To force everybody to think about what they need for their day to day work, it was decided to make the old data available read-only through the OLD_[groupname] folders.

	If you need data from the old location, you can copy it to to your group folder.		If you need data from the old location, you can copy it to your group folder.
	The data transfer is done on the server, but it might still take a while to finish.		The data transfer is done on the server, but it might still take a while to finish.

	=== CLC User management ===		=== CLC User management ===
Line 73:		Line 73:

	Group members can be added or removed via the e-mail account.		Group members can be added or removed via the e-mail account.






	== Data access ==		== Data access ==

Licensed Software/MATLAB

Haars0011 — Tue, 16 Jun 2026 14:23:50 GMT

Phase 1 § 5 P1.5.8: rewrite — sentence-case headings, fix broken [url|text] links, syntaxhighlight matlab, fix MATLAB ... continuation; link into Licensed Software hub (via update-page on MediaWiki MCP Server)

Show changes

Matlab

Haars0011 — Tue, 16 Jun 2026 14:23:16 GMT

Haars0011 moved page Matlab to Licensed Software/MATLAB Phase 1 § 5 P1.5.8: move MATLAB under Licensed Software as a sub-page (via move-page on MediaWiki MCP Server)

New page

MATLAB is a non-free calculation language owned by Mathworks. The HPC has this installed as part of the WUR academic license, and so this is only available to WUR users.

== Getting Started with Parallel Computing using MATLAB on the Anunna HPC Cluster ==

This document provides the steps to configure MATLAB to submit jobs to a cluster, retrieve results, and debug errors.

=== CONFIGURATION – MATLAB client on the cluster ===
After logging into the cluster, configure MATLAB to run parallel jobs on your cluster by calling the shell script '''configCluster.sh'''. (after '''module load matlab''')
This only needs to be called once per version of MATLAB.
$ module load matlab
$ configCluster.sh
Jobs will now default to the cluster rather than submit to the login node.
=== INSTALLATION and CONFIGURATION – MATLAB client on the desktop ===

The Anunna MATLAB support package can be found as follows

Windows: https://git.wur.nl/WUR-MATLAB-tools/support_packages/-/raw/main/wur.nonshared.R2022a.zip?inline=false

Linux/macOS: https://git.wur.nl/WUR-MATLAB-tools/support_packages/-/raw/main/wur.nonshared.R2022a.tar.gz?inline=false

Download the appropriate archive file and start MATLAB. The archive file should be untarred/unzipped in the location returned by calling
>> userpath
Configure MATLAB to run parallel jobs on your cluster by calling '''configCluster'''. '''configCluster''' only needs to be called once per version of MATLAB.
>> configCluster
Submission to the remote cluster requires SSH credentials. You will be prompted for your ssh username and password or identity file (private key). The username and location of the private key will be stored in MATLAB for future sessions.
Jobs will now default to the cluster rather than submit to the local machine.
NOTE: If you would like to submit to the local machine then run the following command:
>> % Get a handle to the local resources
>> c = parcluster('local');
==== CONFIGURING JOBS====
Prior to submitting the job, we can specify various parameters to pass to our jobs, such as queue, e-mail, walltime, etc. The following is a partial list of parameters. See AdditionalProperties for the complete list. Only MemUsage and WallTime are required.

<pre>
>> % Get a handle to the cluster
>> c = parcluster;
[REQUIRED]

>> % Specify memory to use for MATLAB jobs, per core (default: 4gb)
>> c.AdditionalProperties.MemUsage = '6gb';

>> % Specify the walltime (e.g., 5 hours)
>> c.AdditionalProperties.WallTime = '05:00:00';

[OPTIONAL]

>> % Specify an account to use for MATLAB jobs
>> c.AdditionalProperties.AccountName = 'account-name';

>> % Assign a comment to the job
>> c.AdditionalProperties.Comment = 'a-comment';

>> % Request a specific GPU flavor (e.g., V100)
>> c.AdditionalProperties.Constraint = 'V100';

>> % Specify e-mail address to receive notifications about your job
>> c.AdditionalProperties.EmailAddress = 'user-id@wur.nl';

>> % Specify number of GPUs
>> c.AdditionalProperties.GpusPerNode = 1;

>> % Specify a QoS (default: std)
>> c.AdditionalProperties.QoS = 'the-qos';

>> % Specify a queue to use for MATLAB jobs
>> c.AdditionalProperties.QueueName = 'queue-name';

>> % Require exclusive nodes
>> c.AdditionalProperties.RequireExclusiveNode = true;

>> % Specify a reservation
>> c.AdditionalProperties.Reservation = 'a-reservation';

>> % Request there be (for example) 20 GB of local disk space in /tmp
>> c.AdditionalProperties.Tmp = 20g;
</pre>

Save changes after modifying AdditionalProperties for the above changes to persist between MATLAB sessions.
>> c.saveProfile

To see the values of the current configuration options, display AdditionalProperties.

>> % To view current properties
>> c.AdditionalProperties

Unset a value when no longer needed.
>> % Turn off email notifications
>> c.AdditionalProperties.EmailAddress = '';
>> c.saveProfile
==== INTERACTIVE JOBS - MATLAB client on the cluster ====
To run an interactive pool job on the cluster, continue to use parpool as you’ve done before.
Be aware that (depending on load on the cluster) it might take a while for your requested resources to be available.
>> % Get a handle to the cluster
>> c = parcluster;

>> % Open a pool of 64 workers on the cluster
>> pool = c.parpool(64);

Rather than running local on the local machine, the pool can now run across multiple nodes on the cluster.

>> % Run a parfor over 1000 iterations
>> parfor idx = 1:1000
a(idx) = …
end

Once we’re done with the pool, delete it.

>> % Delete the pool
>> pool.delete

==== INDEPENDENT BATCH JOB ====

Use the batch command to submit asynchronous jobs to the cluster. The batch command will return a job object which is used to access the output of the submitted job. See the MATLAB documentation for more help on batch.
<pre>
>> % Get a handle to the cluster
>> c = parcluster;

>> % Submit job to query where MATLAB is running on the cluster
>> job = c.batch(@pwd, 1, {}, …
'CurrentFolder','.', 'AutoAddClientPath',false);

>> % Query job for state
>> job.State

>> % If state is finished, fetch the results
>> job.fetchOutputs{:}

>> % Delete the job after results are no longer needed
>> job.delete
</pre>
To retrieve a list of currently running or completed jobs, call parcluster to retrieve the cluster object. The cluster object stores an array of jobs that were run, are running, or are queued to run. This allows us to fetch the results of completed jobs. Retrieve and view the list of jobs as shown below.
>> c = parcluster;
>> jobs = c.Jobs;
Once we’ve identified the job we want, we can retrieve the results as we’ve done previously.
fetchOutputs is used to retrieve function output arguments; if calling batch with a script, use load instead. Data that has been written to files on the cluster needs be retrieved directly from the file system (e.g. via ftp).

To view results of a previously completed job:
>> % Get a handle to the job with ID 2
>> job2 = c.Jobs(2);

NOTE: You can view a list of your jobs, as well as their IDs, using the above c.Jobs command.
>> % Fetch results for job with ID 2
>> job2.fetchOutputs{:}

==== PARALLEL BATCH JOB ====
Users can also submit parallel workflows with the batch command. Let’s use the following example for a parallel job, which is saved as '''parallel_example.m'''.
<pre>
function [t, A] = parallel_example(iter)

if nargin==0
iter = 8;
end

disp('Start sim')

t0 = tic;
parfor idx = 1:iter
A(idx) = idx;
pause(2)
idx
end
t = toc(t0);

disp('Sim completed')

save RESULTS A

end
</pre>
This time when we use the batch command, to run a parallel job, we’ll also specify a MATLAB Pool.
<pre>
>> % Get a handle to the cluster
>> c = parcluster;

>> % Submit a batch pool job using 4 workers for 16 simulations
>> job = c.batch(@parallel_example, 1, {16}, 'Pool',4, …
'CurrentFolder','.', 'AutoAddClientPath',false);

>> % View current job status
>> job.State

>> % Fetch the results after a finished state is retrieved
>> job.fetchOutputs{:}
ans =
8.8872
</pre>
The job ran in 8.89 seconds using four workers. Note that these jobs will always request N+1 CPU cores, since one worker is required to manage the batch job and pool of workers. For example, a job that needs eight workers will consume nine CPU cores.

We’ll run the same simulation but increase the Pool size. This time, to retrieve the results later, we’ll keep track of the job ID.

NOTE: For some applications, there will be a diminishing return when allocating too many workers, as the overhead may exceed computation time.
<pre>
>> % Get a handle to the cluster
>> c = parcluster;

>> % Submit a batch pool job using 8 workers for 16 simulations
>> job = c.batch(@parallel_example, 1, {16}, 'Pool', 8, …
'CurrentFolder','.', 'AutoAddClientPath',false);

>> % Get the job ID
>> id = job.ID
id =
4
>> % Clear job from workspace (as though we quit MATLAB)
>> clear job
</pre>
Once we have a handle to the cluster, we’ll call the findJob method to search for the job with the specified job ID.
<pre>
>> % Get a handle to the cluster
>> c = parcluster;

>> % Find the old job
>> job = c.findJob('ID', 4);

>> % Retrieve the state of the job
>> job.State
ans =
finished
>> % Fetch the results
>> job.fetchOutputs{:};
ans =
4.7270
</pre>
The job now runs in 4.73 seconds using eight workers. Run code with different number of workers to determine the ideal number to use.
Alternatively, to retrieve job results via a graphical user interface, use the Job Monitor (Parallel > Monitor Jobs).

==== DEBUGGING ====
If a serial job produces an error, call the getDebugLog method to view the error log file. When submitting independent jobs, with multiple tasks, specify the task number.
>> c.getDebugLog(job.Tasks(3))
For Pool jobs, only specify the job object.
>> c.getDebugLog(job)
When troubleshooting a job, the cluster admin may request the scheduler ID of the job. This can be derived by calling schedID
<pre>
>> schedID(job)
ans =
25539
</pre>
==== TO LEARN MORE ====
To learn more about the MATLAB Parallel Computing Toolbox, check out these resources:
* [https://www.mathworks.com/help/parallel-computing/examples.html|Parallel Computing Coding Examples]
* [http://www.mathworks.com/help/distcomp/index.html|Parallel Computing Documentation]
* [http://www.mathworks.com/products/parallel-computing/index.html|Parallel Computing Overview]
* [http://www.mathworks.com/products/parallel-computing/tutorials.html|Parallel Computing Tutorials]
* [http://www.mathworks.com/products/parallel-computing/videos.html|Parallel Computing Videos]
* [http://www.mathworks.com/products/parallel-computing/webinars.html|Parallel Computing Webinars]

Licensed Software

Haars0011 — Tue, 16 Jun 2026 14:23:10 GMT

Phase 1 § 5 P1.5.8 / Phase 2 P2.12: hub page for licensed software, linking to per-package pages (MATLAB subpage, CLC) (via create-page on MediaWiki MCP Server)

New page

Alongside the freely-available [[Environment Modules | modules]], Anunna hosts a few commercial, licensed software packages. Access to these is restricted — typically to WUR users covered by a WUR licence, or to members of specific groups — rather than open to everyone on the cluster.

Anunna currently hosts these licensed packages, each documented on its own page:

* [[Licensed Software/MATLAB | MATLAB]] — numerical computing language from MathWorks, available to WUR users under the WUR academic licence.
* [[CLC | CLC Genomics Server]] — genomics analysis server from Qiagen, available to specific WUR groups.

To request a licensed package that is not listed here, see [[Requesting New Software]].

== See also ==

* [[Environment Modules]]
* [[Requesting New Software]]
* [[Reservations]]

Parallel R code on SLURM

Haars0011 — Tue, 16 Jun 2026 14:08:58 GMT

Phase 1 § 5 P1.5.6: content merged into R Parallel R section (decision 4: R-specific parallel stays in § 5) (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 14:08, 16 June 2026
Line 1:		Line 1:
			#REDIRECT [[R#Parallel R]]
	~~== Using~~ R ~~code on SLURM for embarrassingly parallel calculations ==~~

	~~The most well-known~~ R packages that provide parallel functionality, e.g. doParallel or doSNOW, do not work properly on Anunna. Using these packages will be particularly problematic when you try to run (array) jobs over multiple nodes. However, the [https://cran.r-project.org/web/packages/rslurm/vignettes/rslurm.html rslurm package] allows you to do [https://en.wikipedia.org/wiki/Embarrassingly_parallel embarrassingly parallel] calculations on SLURM. The package automatically divides the computation over multiple nodes and writes the necessary submission scripts. It also includes functions to retrieve and combine the output from different nodes, as well as wrappers for common SLURM commands.

	~~=== Example code ===~~
	~~<code lang='R'>library(rslurm)~~
	~~sjob <- slurm_apply(test_func, pars, jobname = 'test_apply',~~
	~~nodes = 2, cpus_per_node = 2, submit = FALSE)</code>~~

	Please be aware that new Slurm jobs will have a few seconds of lead time before executing, so try to make sure that your new tasks are appropriately long-living (~60s is a good minimum). Otherwise most of your 'compute' time will be waiting for jobs to start and stop.

	~~== External links ==~~
	~~[https://cran.r-project.org/web/packages/rslurm/vignettes/rslurm.html Vignette for the rslurm package~~]

Control R environment using modules

Haars0011 — Tue, 16 Jun 2026 14:08:57 GMT

Phase 1 § 5 P1.5.6: stale pre-Lmod module-building workflow, superseded by buckets + R-bundle-CRAN; redirect to R (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 14:08, 16 June 2026
Line 1:		Line 1:
	~~== Setting up a semi-public repository ==~~		#REDIRECT [[R]]

	~~<source lang='bash'>~~
	~~mkdir /cm/shared/apps/WUR/ABGC/R/R_libraries/3.0.2~~
	~~</source>~~
	~~Note: need to do this only once per version; make sure that the folder does not already exist.~~

	~~== Create an R module ==~~

	~~<source lang='bash'>~~
	~~mkdir /cm/shared/apps/WUR/ABGC/modulefiles/R/~~
	~~</source>~~
	~~Note: need to do this only once per version; make sure that the folder does not already exist.~~

	~~<source lang='bash'>~~
	~~cp /cm/shared/modulefiles/R/3.0.2 /cm/shared/apps/WUR/ABGC/modulefiles/R/3.0.2_wur~~
	~~</source>~~
	~~Note: need to do this only once per version; make sure that the file does not already exist.~~

	~~<source lang='tcl'>~~
	~~#%Module1.0#######################################################################~~
	~~## R3 modulefile modified for WUR/ABGC use~~
	##
	~~proc ModulesHelp { } {~~

	~~puts stderr "\tAdds R v3.0.2 to your environment and sets WUR/ABGC libraries"~~
	}

	~~module-whatis "Adds R v3.0.2 to your environment and set WUR/ABGC libraries"~~

	~~set r3_root /cm/shared/apps/R3/~~
	~~set r3_wur_root /cm/shared/apps/WUR/ABGC/R/R_libraries/3.0.2/~~

	~~prepend-path PATH $r3_root/bin~~
	~~prepend-path MANPATH $r3_root/share/man~~
	~~prepend-path LD_LIBRARY_PATH $r3_root/lib64~~
	~~prepend-path R_LIBS_SITE $r3_wur_root~~

	~~</source>~~

	~~== Load Module ==~~

	~~<source lang='bash'>~~
	~~module avail~~
	~~</source>~~

	~~----------------------------------- /cm/shared/apps/WUR/ABGC/modulefiles -----------------------------------~~
	~~bwa/0.5.9 bwa/0.7.5a R/3.0.2_wur~~

	~~<source lang='bash'>~~
	~~module load R/3.0.2_wur~~
	~~</source>~~

	~~== Install R package and check install path ==~~

	~~<source lang='rsplus'>~~
	~~install.packages('car')~~
	~~</source>~~



	~~> installed.packages()~~
	~~Package LibPath~~
	~~car "car" "/cm/shared/apps/WUR/ABGC/R/R_libraries/3.0.2"~~

	~~== See also ==~~

	* [[Parallel_R_code_on_SLURM \| Running parallel workloads in R on Slurm]]
	* [[~~Domain_specific_software_on_B4Fcluster_installation_by_users \| Installing domain specific software: installation by users]]~~
	* [~~[Setting local variables]]~~
	* [[Installing_R_packages_locally \| Installing R ~~packages locally]]~~
	* [[Setting_up_Python_virtualenv \| Setting up and using a virtual environment for Python3 ]]

	~~== External links ==~~

Installing R packages locally

Haars0011 — Tue, 16 Jun 2026 14:08:56 GMT

Phase 1 § 5 P1.5.6: content merged into R (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 14:08, 16 June 2026
Line 1:		Line 1:
			#REDIRECT [[R#Local package library]]

	~~== Specifying a local library search location ==~~

	~~Specify a local library search location.~~

	~~You can use several library trees of add-on packages. The easiest way to tell R to use these via a 'dotfile' by creating the following file '$HOME/.Renviron' (watch the quotes and ~ character):~~
	~~<pre>~~
	~~R_LIBS_USER="~/R/library"~~
	~~</pre>~~
	This specifies a keyword (<code>R_LIBS_USER</code>) which points to a colon-separated list of directories at which R library trees are rooted. You do not have to specify the default tree for R packages.

	~~If necessary, create a place for your R libraries~~
	~~<pre>~~
	~~mkdir ~/R ~/R/library~~ # ~~Only need do this once~~
	~~</pre>~~
	~~Set your R library path~~
	~~<pre>~~
	~~echo 'R_LIBS_USER="~/~~R~~/library"' > $HOME/.Renviron~~
	~~</pre>~~
	~~== Installing to a local library search location ==~~

	~~Start up R:~~

	~~<pre>~~
	R # ~~Invoke R~~
	~~</pre>~~
	~~Then, from the R environment, install the packages you require while pointing at the root R-~~package ~~directory of choice. This example will install from CRAN.~~
	~~<pre>~~
	~~install.packages("name-of-your-package",lib="~/R/~~library")
	~~</pre>~~
	~~== Installing and using a local library from a JuPyteR notebook ==~~
	~~Click on the image.~~
	~~[[File:R_libpaths.png\|thumb~~]]
	~~== See also ==~~
	* [[Control_R_environment_using_modules \| Control R environment on the cluster using modules]]
	* [[Parallel_R_code_on_SLURM \| Using parallel R workloads under SLURM]]
	* [[Bioinformatics_tips_tricks_workflows \| Bioinformatics tips, tricks, and workflows]]

	~~== External links ==~~
	~~[http://csg.sph.umich.edu/docs/R/localpackages.html source for material for this aricle]~~

	~~[http://cran-mirror.cs.uu.nl CRAN homepage]~~

	~~[http://en.wikipedia.org/wiki/R_(programming_language) R article from Wikipedia~~]

R

Haars0011 — Tue, 16 Jun 2026 14:08:47 GMT

Phase 1 § 5 P1.5.6: merge Installing R packages locally + Control R environment using modules + Parallel R code on SLURM into R. Promoted R_LIBS_USER/.Renviron method, folded in Parallel R (rslurm), dropped stale pre-Lmod module-building content. (via update-page on MediaWiki MCP Server)

Show changes

Using conda to install a new kernel into your notebook

Haars0011 — Tue, 16 Jun 2026 14:01:22 GMT

Phase 1 § 5 P1.5.5: conda-kernel content merged into Python Jupyter kernels section (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 14:01, 16 June 2026
Line 1:		Line 1:
	~~As you can read~~ [[~~Setting_up_Python_virtualenv~~#~~Virtualenv_kernels_in_Jupyter\|here~~]]~~, you can add a new kernel to your Jupyter manually.~~		#REDIRECT [[Python#Jupyter kernels]]

	~~If you use conda, the following steps can be used to create the necessary files, and share your environment :~~

	~~Install:~~

	~~<nowiki>~~
	~~conda create -y -n kernel_test python=3 ipykernel && conda activate kernel_test~~
	~~python -m ipykernel install --user --name kernel_test</nowiki>~~

	~~Cleanup (make sure you have activated the right enviroment):~~

	~~<nowiki>~~
	~~jupyter kernelspec uninstall kernel_test~~
	~~conda deactivate && conda remove -y -n kernel_test</nowiki>~~

Virtual environment Python 3.4 or higher

Haars0011 — Tue, 16 Jun 2026 14:01:21 GMT

Phase 1 § 5 P1.5.5: near-duplicate venv guide, content merged into Python (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 14:01, 16 June 2026
Line 1:		Line 1:
	~~With many~~ Python packages available, which are often in conflict or requiring different versions depending on application, installing and controlling packages and versions is not always easy. In addition, so many packages are often used only occasionally, that it is questionable whether a system administrator of a centralized server system or a High Performance Compute (HPC) infrastructure can be expected to resolve all issues posed by users of the infrastructure. Even on a local system with full administrative rights managing versions, dependencies, and package collisions is often very difficult. The solution is to use a virtual environment, in which a specific set of packages can then be installed. As many different virtual environments can be created, and used side-by-side, as is necessary.		#REDIRECT [[Python#Virtual environments]]

	~~== creating a new virtual environment ==~~

	~~If you do not already have a directory in your <code>$HOME</code> dir where your virtual environments live, first make one (it is assumed that you will over the course of time create several virtual~~ environments ~~for different projects and different versions of Python side-by-side, best to organise them a bit).~~

	~~<pre>~~
	~~mkdir ~/my_envs~~
	~~</pre>~~

	~~Since python 3.12.3 is already the default, you can use that one or load another Python version 3.4 or above. To use python 3.4-3.12.0, you need to load legacy as well:~~
	~~<pre>~~
	~~module load legacy~~
	~~module load python/3.5.0~~
	~~</pre>~~

	~~And then simply create an environment with a reasonably descriptive name (remember, you may accumulate as many as you desire), in this example <code>/p35_myproj</code>.~~


	~~Using the default python (3.12.3):~~
	~~<pre>~~
	~~python3 -m venv ~/my_envs/p35_myproj~~
	~~</pre>~~

	~~when using python 3.4/3.5:~~
	~~<pre>~~
	~~pyvenv install ~/my_envs/p35_myproj~~
	~~</pre>~~

	~~== activating a virtual environment ==~~
	~~Once the environment is created, each time the environment needs to be activated, the following command needs to be issued:~~
	~~<pre>~~
	~~source ~/my_envs/p35_myproj/bin/activate~~
	~~</pre>~~

	~~This assumes that the folder that contains the virtual environment documents (in this case called <code>newenv</code>), is in the present working directory.~~
	~~When working on the virtual environment, the virtual environment name will be between brackets in front of the <code>user-host-prompt</code> string.~~
	~~<pre>~~
	~~(p35_myproj)user@host:~$~~
	~~</pre>~~

	~~Note that like with any command you can make an alias in your <code>~/.bashrc</code>. Just add something like this line to your <code>.bashrc</code>:~~

	~~<pre>~~
	~~alias p35myproj='source ~/my_envs/p35_myproj/bin/activate'~~
	~~</pre>~~

	~~== installing modules on the virtual environment ==~~
	Installing modules is the same as usual. The difference is that modules are in <code>/path/to/virtenv/lib</code>, which may be living somewhere on your home directory. An easy way of installing modules is using <code>pip</code>.

	~~Before you start installing modules, first update pip itself:~~
	~~<pre>~~
	~~pip install --upgrade pip~~
	~~</pre>~~

	~~you can then install other modules as you like, for instance numpy:~~

	~~<pre>~~
	~~pip install numpy~~
	~~</pre>~~

	~~<pre>~~
	~~(p35_myproj) [user@nfs01 ~]$ pip install numpy~~
	~~Collecting numpy~~
	~~Using cached numpy-1.10.4.tar.gz~~
	~~Installing collected packages: numpy~~
	~~Running setup.py install for numpy ... done~~
	~~Successfully installed numpy-1.10.4~~
	~~</pre>~~

	~~Similarly, installing packages from source works exactly the same as usual (note: only relevant for modules that can't be pulled through <code>pip</code>).~~
	~~<pre>~~
	~~python setup.py install~~
	~~</pre>~~

	~~== deactivating a virtual environment ==~~
	~~Quitting a virtual environment can be done by using the command <code>deactivate</code>, which was loaded using the <code>source</code> command upon activating the virtual environment.~~
	~~<pre>~~
	~~deactivate~~
	~~</pre>~~

	~~== Make IPython work under virtualenv ==~~
	~~IPython can simply be installed through pip.~~

	~~<pre>~~
	~~pip install ipython~~
	~~</pre>~~

	~~== See also ==~~
	* [[Anunna \| Anunna]]

	~~== External links ==~~
	* [https://docs.python.org/3/library/venv.html#module-venv Python docs on virtenv]

Setting up Python virtualenv

Haars0011 — Tue, 16 Jun 2026 14:01:19 GMT

Phase 1 § 5 P1.5.5: content merged into Python (built-in venv supersedes virtualenv/pyvenv) (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 14:01, 16 June 2026
Line 1:		Line 1:
	With many Python packages available, which are often in conflict or requiring different versions depending on application, installing and controlling packages and versions is not always easy. In addition, so many packages are often used only occasionally, that it is questionable whether a system administrator of a centralized server system or a High Performance Compute (HPC) infrastructure can be expected to resolve all issues posed by users of the infrastructure. Even on a local system with full administrative rights managing versions, dependencies, and package collisions is often very difficult. The solution is to use a virtual environment, in which a specific set of packages can then be installed. As many different virtual environments can be created, and used side-by-side, as is necessary.		#REDIRECT [[Python#Virtual environments]]

	~~NOTE: as of Python 3.3 virtual environment support is built-in. See this page for an~~ [[~~virtual_environment_Python_3.4_or_higher \| alternative set-up of your virtual environment if using~~ Python ~~3.4 or higher~~]].

	~~== Creating a new virtual environment ==~~
	It is assumed that the appropriate <code>virtualenv</code> executable for the Python version of choice is installed. A new virtual environment, in this case called <code>newenv</code> is created like so:
	~~<pre>~~
	~~module load python/my-favourite-version (e.g. 2.7.12)~~
	~~virtualenv newenv~~
	OR
	~~pyvenv newenv (For versions >3.4)~~
	~~</pre>~~

	~~When the new environment is created, one will see a message similar to this:~~
	~~<nowiki> New python executable in newenv/bin/python3~~
	~~Also creating executable in newenv/bin/python~~
	~~Installing Setuptools.........................................................................done.~~
	~~Installing Pip................................................................................done.</nowiki>~~

	~~== Activating a virtual environment ==~~
	~~Once the environment is created, each time the environment needs to be activated, the following command needs to be issued:~~
	~~<pre>~~
	~~source newenv/bin/activate~~
	~~</pre>~~
	~~This assumes that the folder that contains the virtual environment documents (in this case called <code>newenv</code>), is in the present working directory.~~
	~~When working on the virtual environment, the virtual environment name will be between brackets in front of the <code>user-host-prompt</code> string.~~
	~~<nowiki> (newenv)user@host:~$</nowiki>~~

	~~== Installing modules on the virtual environment ==~~
	Installing modules is the same as usual. The difference is that modules are in <code>/path/to/virtenv/lib</code>, which may be living somewhere on your home directory. When working from the virtual environment, the default <code>pip</code> will belong to the python version that is currently active. This means that the executable in <code>/path/to/virtenv/bin</code> are in fact the first in the <code>$PATH</code>.
	~~<pre>~~
	~~pip install numpy~~
	~~</pre>~~
	~~Similarly, installing packages from source works exactly the same as usual.~~
	~~<pre>~~
	~~python setup.py install~~
	~~</pre>~~

	~~== deactivating a virtual environment ==~~
	~~Quitting a virtual environment can be done by using the command <code>deactivate</code>, which was loaded using the <code>source</code> command upon activating the virtual environment.~~
	~~<pre>~~
	~~deactivate~~
	~~</pre>~~

	~~== Virtualenv kernels in Jupyter ==~~
	~~Want your own virtualenv kernel in a notebook? This can be done by making your own kernel specifications:~~

	~~(an alternative way to the manual way (using conda) is described [[Using conda to install a new kernel into your notebook\|here ]])~~

	* Make sure you have the ipykernel module in your venv. Activate it and pip install it:
	~~<nowiki>source ~/path/to/my/virtualenv/bin/activate && pip install ipykernel</nowiki>~~
	* Create the following directory path in your homedir if it doesn't already exist:
	~~<nowiki>mkdir -p ~/.local/share/jupyter/kernels/</nowiki>~~
	* Think of a nice descriptive name that doesn't clash with one of the already present kernels. I'll use 'testing'. Create this folder:
	~~<nowiki>mkdir ~/.local/share/jupyter/kernels/testing/</nowiki>~~
	* Add this file to this folder:
	~~<nowiki>vi ~/.local/share/jupyter/kernels/testing/kernel.json~~
	{
	~~"language": "python",~~
	~~"argv": [~~
	~~"/home/myhome/path/to/my/virtualenv/bin/python",~~
	~~"-m",~~
	~~"ipykernel",~~
	~~"-f",~~
	~~"{connection_file}"~~
	],
	~~"display_name": "testing"~~
	~~}</nowiki>~~
	* Reload Jupyterhub page. testing should now exist in your kernels list.

	~~You can do more complex things with this, such as construct your own Spark environment. This relies on having the module findspark installed:~~
	~~<nowiki> vi ~/.local/share/jupyter/kernels/mysparkkernel/kernel.json~~
	{
	~~"language": "python",~~
	~~"env": {~~
	~~"SPARK_HOME":~~
	~~"/shared/apps/spark/my-spark-version"~~
	},
	~~"argv": [~~
	~~"/home/myhome/my/spark/venv/bin/python",~~
	~~"-m",~~
	~~"ipykernel",~~
	~~"-c", "import findspark; findspark.init()",~~
	~~"-f",~~
	~~"{connection_file}"~~
	],
	~~"display_name": "My Spark kernel"~~
	~~}</nowiki>~~
	~~(You'll want to make sure your spark cluster has the same environment - start it after activating this venv inside your sbatch script)~~

	~~== Make IPython work under virtualenv ==~~
	~~IPython may not work initially under a virtual environment. It may produce an error message like below:~~

	~~<nowiki> File "/usr/bin/ipython", line 11~~
	~~print "Could not start qtconsole. Please install ipython-qtconsole"~~
	~~^</nowiki>~~

	~~This can be resolved by adding a soft link with the name <code>ipython</code> to the <code>bin</code> directory in the virtual environment folder.~~
	~~<pre>~~
	~~ln -s /path/to/virtenv/bin/ipython3 /path/to/virtenv/bin/ipython~~
	~~</pre>~~

	~~== External links ==~~
	* [https://pypi.python.org/pypi/virtualenv Python3 documentation for virtualenv]
	* [http://cemcfarland.wordpress.com/2013/03/09/getting-ipython3-working-inside-your-virtualenv/ Solving the IPython hickup under virtual environment]

Python

Haars0011 — Tue, 16 Jun 2026 14:01:12 GMT

Phase 1 § 5 P1.5.5: merge Setting up Python virtualenv + Virtual environment Python 3.4+ + Using conda... into Python. Filled empty Mamba heading with Miniforge, aligned variable to $myNobackup, fixed /bin/bin typo, dropped stale venv content. (via update-page on MediaWiki MCP Server)

Show changes

HPC Advanced/Preparation Exercise

Honfi001 — Tue, 16 Jun 2026 13:55:10 GMT

1.1 — Set up the variables

← Older revision		Revision as of 13:55, 16 June 2026
Line 24:		Line 24:

	<syntaxhighlight lang="bash">		<syntaxhighlight lang="bash">
			# Provided it does not exist
	# Create an empty ~/.bash_aliases if you do not already have one		# Create an empty ~/.bash_aliases if you do not already have one
	$ touch ~/.bash_aliases		$ touch ~/.bash_aliases

	# Load the anunna module ~~(this provides getLustreDir)~~		# Load the anunna module
	$ module load anunna		$ module load anunna

Line 116:		Line 117:
	$ pip freeze # for checking what is installed		$ pip freeze # for checking what is installed
	</syntaxhighlight>		</syntaxhighlight>

	{{Note\|'''Note on <code>datetime</code>:''' <code>datetime</code> is part of the Python '''standard library''' — it ships with the interpreter and does not actually need to be installed. The analyser imports the built-in module. The line above is kept for parity with the course slides; you only truly need <code>matplotlib</code> and <code>pandas</code>.}}

	== Part 3 (Step 1) — The Launcher Script <code>weather.sh</code> ==		== Part 3 (Step 1) — The Launcher Script <code>weather.sh</code> ==

HPC Advanced/Preparation Exercise

Honfi001 — Tue, 16 Jun 2026 13:48:31 GMT

Created page with "= HPC Basics Refresher — Weather Data Analyser = {{Note|'''Who is this for?''' This is a self-paced preparation exercise for people who are attending the '''HPC Advanced''' course but did '''not''' attend '''HPC Basics'''. Working through it end to end means you arrive at the advanced course already comfortable with environment variables, virtual environments, launcher scripts, interactive jobs, and SLURM batch submission on '''Anunna'''.}} '''The application:''' a s..."

New page

= HPC Basics Refresher — Weather Data Analyser =

{{Note|'''Who is this for?''' This is a self-paced preparation exercise for people who are attending the '''HPC Advanced''' course but did '''not''' attend '''HPC Basics'''. Working through it end to end means you arrive at the advanced course already comfortable with environment variables, virtual environments, launcher scripts, interactive jobs, and SLURM batch submission on '''Anunna'''.}}

'''The application:''' a small Python script that loads weather data from a Dutch weather station and draws some figures.

Source: <code>/lustre/shared/hpcCourses/Basics/weer_vanaf_2000.py</code>

By the end you will have:

* Set up handy Lustre path variables (<code>$myScratch</code>, <code>$myBkp</code>, <code>$myNoBkp</code>) and aliases
* Created a Python virtual environment on Lustre scratch
* Written an executable launcher script (<code>weather.sh</code>)
* Measured the job's memory requirement interactively
* Written and submitted a SLURM batch script (<code>weather.slurm</code>) and collected the figures

''Conventions in this document:'' lines starting with <code>$</code> are commands you type at the shell (do not type the <code>$</code>). <code><nowiki><placeholder></nowiki></code> means ''substitute your own value''.

== Part 1 — Environment Variables & Aliases ==

The Anunna <code>getLustreDir</code> helper writes your personal Lustre directories (<code>$myScratch</code>, <code>$myBkp</code>, <code>$myNoBkp</code>) into your environment so you never have to type long paths again.

=== 1.1 — Set up the variables ===

<syntaxhighlight lang="bash">
# Create an empty ~/.bash_aliases if you do not already have one
$ touch ~/.bash_aliases

# Load the anunna module (this provides getLustreDir)
$ module load anunna

# Inspect what getLustreDir does
$ getLustreDir -h

# Append the export lines to your ~/.bash_aliases
$ getLustreDir -e >> ~/.bash_aliases

# Check the result (cat, less, more or nano all work)
$ cat ~/.bash_aliases

# Reload your environment so the new variables take effect
$ source ~/.bashrc
</syntaxhighlight>

=== 1.2 — Test the variables ===

'''Test 1 — does this print your scratch folder location?'''

<syntaxhighlight lang="bash">
$ echo $myScratch
</syntaxhighlight>

'''Test 2 — does this take you to your scratch folder?'''

<syntaxhighlight lang="bash">
$ cd $myScratch
</syntaxhighlight>

If both work, your variables are live.

=== 1.3 — Bonus: convenience aliases ===

Add these lines to your <code>~/.bash_aliases</code> and reload your environment again:

<syntaxhighlight lang="bash">
alias cds="cd $myScratch"
alias cdb="cd $myBkp"
alias cdn="cd $myNoBkp"
</syntaxhighlight>

{{Note|'''Important:''' the alias lines must come '''after''' the variable definitions in <code>~/.bash_aliases</code>, because they reference those variables.}}

If your aliases still do not work after <code>source ~/.bashrc</code>, your <code>~/.bashrc</code> may not be sourcing <code>~/.bash_aliases</code> at all. Add this block to the '''end''' of your <code>~/.bashrc</code>:

<syntaxhighlight lang="bash">
if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi
</syntaxhighlight>

Then <code>source ~/.bashrc</code> once more.

== Part 2 (Step 0) — Python Virtual Environment ==

We isolate the analyser's dependencies in a virtual environment living on Lustre scratch.

=== 2.1 — Load the software stack and Python ===

<syntaxhighlight lang="bash">
$ module purge
$ module load 2024
$ module load Python/3.12.3
</syntaxhighlight>

=== 2.2 — Create the virtual environment (in Lustre scratch) ===

<syntaxhighlight lang="bash">
$ mkdir $myScratch/hpcCourse; cd $_
$ python -m venv $myScratch/hpcCourse/venv
$ source $myScratch/hpcCourse/venv/bin/activate
</syntaxhighlight>

{{Note|<code>cd $_</code> reuses the last argument of the previous command — here, the directory you just created.}}

=== 2.3 — Check you are using the venv's Python ===

<syntaxhighlight lang="bash">
$ which python # should point inside .../hpcCourse/venv/bin
$ python -V # should report Python 3.12.3
</syntaxhighlight>

=== 2.4 — Install the required libraries ===

<syntaxhighlight lang="bash">
$ pip install matplotlib pandas datetime
$ pip freeze # for checking what is installed
</syntaxhighlight>

{{Note|'''Note on <code>datetime</code>:''' <code>datetime</code> is part of the Python '''standard library''' — it ships with the interpreter and does not actually need to be installed. The analyser imports the built-in module. The line above is kept for parity with the course slides; you only truly need <code>matplotlib</code> and <code>pandas</code>.}}

== Part 3 (Step 1) — The Launcher Script <code>weather.sh</code> ==

=== Tasks ===

# Copy the Python script into your course folder:
#: <syntaxhighlight lang="bash" inline>cp /lustre/shared/hpcCourses/Basics/weer_vanaf_2000.py $myScratch/hpcCourse/</syntaxhighlight>
# Write a bash script called '''<code>weather.sh</code>''' that loads the modules and activates the virtual environment you created, and make it executable.
# The script should end with the run command below. '''Hint:''' use variables for paths.
#: <syntaxhighlight lang="bash" inline>python $myScratch/hpcCourse/weer_vanaf_2000.py 240</syntaxhighlight>
#: (<code>240</code> is the argument passed to the analyser — the number of months of data to plot, i.e. ~20 years.)

=== Example solution — <code>weather.sh</code> ===

<syntaxhighlight lang="bash">
#!/bin/bash
# weather.sh — load the environment and run the Weather Data Analyser

# Load the software stack and Python
module purge
module load 2024
module load Python/3.12.3

# Activate the virtual environment
source "$myScratch/hpcCourse/venv/bin/activate"

# Run the analyser (240 = months of data to plot, ~20 years)
python "$myScratch/hpcCourse/weer_vanaf_2000.py" 240
</syntaxhighlight>

Make it executable:

<syntaxhighlight lang="bash">
$ chmod +x $myScratch/hpcCourse/weather.sh
</syntaxhighlight>

== Part 4 (Step 2) — Find the Job Requirements ==

Before submitting a batch job you need to know how much memory it needs. We start with a deliberately small allocation and increase it until the job stops crashing.

=== Task ===

Find the job requirements (e.g. memory) of the Python script using <code>sinteractive</code>. Increase the amount of RAM until the job no longer crashes.

<syntaxhighlight lang="bash">
$ sinteractive --mem 100M --time=0-0:10 -c 1
$ cd $myScratch/hpcCourse
$ ./weather.sh
</syntaxhighlight>

If the job is killed (out-of-memory), exit the interactive session, re-launch <code>sinteractive</code> with a larger <code>--mem</code> value (e.g. <code>200M</code>, <code>500M</code>, <code>1G</code>, …) and run again. Repeat until <code>weather.sh</code> completes cleanly. '''Note the smallest <code>--mem</code> value that works''' — you will use it in Step 3.

== Part 5 (Step 3) — Write and Submit a SLURM Script ==

=== Tasks ===

# '''Write''' a SLURM script for the job using the resource requirements you determined in Step 2. Label it '''<code>weather.slurm</code>'''.
# '''Submit''' the job with <code>sbatch</code>.
# '''Check the status''' of your job and cancel it if needed.
# '''Check the figures''' generated by the Python script.

{{Note|'''Tip:''' a SLURM template is available at <code>/lustre/shared/hpcCourses/Basics/script_slurm.sh</code>}}

=== Example solution — <code>weather.slurm</code> ===

<syntaxhighlight lang="bash">
#!/bin/bash
#SBATCH --job-name=weather
#SBATCH --mem=<RAM-from-Step-2> # e.g. 500M — the value you found in Step 2
#SBATCH --time=0-0:10
#SBATCH --cpus-per-task=1
#SBATCH --output=weather-%j.out
#SBATCH --error=weather-%j.err

cd "$myScratch/hpcCourse"
./weather.sh
</syntaxhighlight>

=== Submit, monitor, and collect results ===

<syntaxhighlight lang="bash">
# Submit the job
$ sbatch weather.slurm

# Check the status of your jobs
$ squeue --me

# Cancel a job if needed (replace <jobid> with the ID from squeue / sbatch)
$ scancel <jobid>

# Once finished, inspect the output and the generated figures
$ ls $myScratch/hpcCourse
$ cat weather-<jobid>.out
</syntaxhighlight>

The analyser writes its figures into your course folder — open them to confirm the run succeeded.

== Checklist ==

* <code>echo $myScratch</code> prints your scratch path and <code>cd $myScratch</code> works
* <code>cds</code> / <code>cdb</code> / <code>cdn</code> aliases jump to the right folders
* Virtual environment activates and <code>which python</code> points inside it
* <code>weather.sh</code> is executable and runs the analyser interactively
* You know the minimum <code>--mem</code> the job needs (from Step 2)
* <code>weather.slurm</code> submits with <code>sbatch</code> and the figures are generated

You are now ready for the '''HPC Advanced''' course.

Locale settings

Haars0011 — Tue, 16 Jun 2026 13:45:24 GMT

Phase 1 § 5 P1.5.4: style polish — drop leading = title =, convert indented-code to syntaxhighlight, remove first-person example, add sections + See also (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 13:45, 16 June 2026
Line 1:		Line 1:
	~~= How to change~~ language ~~settings =~~		Locale settings control how Linux presents language-dependent things: the language of prompts and error messages, how dates, numbers and currency are formatted, and how "special" characters are handled.

	~~Language settings are~~ used ~~within Linux to decide things like~~ the ~~language~~ of ~~prompts~~, ~~date and monetary~~ settings, and ~~how to handle "special" characters~~.		Because Anunna is used by people with many different backgrounds, the cluster sets no default locale — the operating system's own defaults apply, so everything works out of the box. If you want different behaviour, set your preferred locale yourself. Put the settings in your <code>~/.bashrc</code>, and also inside any job scripts, since scripts do not normally read your <code>~/.bashrc</code>.

	As the ~~HPC is used by people with very diverse backgrounds, we do not set a default setting for this.~~		== Seeing the current settings ==
	~~Of course, the OS still has defaults, so everything still works.~~

	~~If you want to change~~ the ~~default,~~ the ~~best way is to add your preferred setting to your .bashrc, and also to run scripts, as they usually don't load your .bashrc .~~		To list the locale categories and the value each currently uses:

	~~To see the available categories and the language they use, use this:~~		<syntaxhighlight lang="bash">
	locale		locale
	~~To see the available language options, use this:~~		</syntaxhighlight>
	~~locale -a~~
	~~As you saw, there are two main categories, '''LANG''' and '''LC_*'''.~~
	~~If you want to change them, you will have to change them separately, like this:~~
	~~export LANG=nl_NL.utf8~~
	~~export LC_ALL=nl_NL.utf8~~

	~~After the above, you will have error messages in Dutch, and the currency symbol will be~~ the ~~Euro sign.~~		To list the locales available on the system:
	~~To see what~~ the ~~active settings are for a certain category, you can (e.g. MONETARY) do this~~:
	~~locale -k LC_MONETARY~~

	~~If you want to mix and match locales (use en_IE.utf8 for MONETARY and NUMERIC, and the rest is en_DK.utf8), do this:~~		<syntaxhighlight lang="bash">
	~~# Unset (clear) LC_ALL, as that overrides the changes~~		locale -a
	~~unset LC_ALL~~		</syntaxhighlight>
	~~# Set everything to English with Danish settings (correct dates)~~
	~~for item in $(~~locale ~~\| grep LC \| grep~~ -~~v LC_ALL \| cut -f1 -d'='); do export ${item}=en_DK.UTF-8;done~~
	~~# Now we can set NUMERIC and MONETARY to en_IE.utf8 so we get~~ a ~~dot as the decimal separator~~
	~~export LC_NUMERIC=en_IE.utf8~~
	~~export LC_MONETARY=en_IE.utf8~~

	My locale (~~haars001~~) ~~looks~~ like ~~this~~:		To see the detailed keywords of one category (for example monetary formatting):
	LANG=en_IE.UTF-8
	LANGUAGE=		<syntaxhighlight lang="bash">
	LC_CTYPE=en_DK.UTF-8		locale -k LC_MONETARY
	LC_NUMERIC=en_IE.UTF-8		</syntaxhighlight>
	LC_TIME=en_DK.UTF-8
	LC_COLLATE=en_DK.UTF-8		There are two kinds of setting: <code>LANG</code>, the overall default, and the individual <code>LC_*</code> category variables (such as <code>LC_NUMERIC</code> or <code>LC_TIME</code>) that override <code>LANG</code> for one category each.
	LC_MONETARY=en_IE.UTF-8
	LC_MESSAGES=en_DK.UTF-8		== Changing your locale ==
	LC_PAPER=en_DK.UTF-8
	LC_NAME=nl_NL.utf8		Set <code>LANG</code> (and optionally <code>LC_ALL</code>, which forces every category at once):
	LC_ADDRESS=nl_NL.utf8
	LC_TELEPHONE=nl_NL.utf8		<syntaxhighlight lang="bash">
	LC_MEASUREMENT=en_DK.UTF-8		export LANG=nl_NL.utf8
	LC_IDENTIFICATION=en_DK.UTF-8		export LC_ALL=nl_NL.utf8
	LC_ALL=		</syntaxhighlight>

			After this you would get error messages in Dutch and the euro sign as the currency symbol.

			Note that <code>LC_ALL</code> overrides everything else, so leave it unset if you want to mix categories (see below).

			== Mixing categories ==

			A common wish is to mix locales — for example English-language messages but Danish date and number formatting (which gives unambiguous <code>YYYY-MM-DD</code> dates), with an Irish locale for the decimal separator so numbers use a dot. Because <code>LC_ALL</code> overrides individual categories, first clear it, set a base for all categories, then override the few you want:

			<syntaxhighlight lang="bash">
			# LC_ALL overrides per-category settings, so clear it first
			unset LC_ALL

			# Set every category to English with Danish conventions (e.g. correct dates)
			for item in $(locale \| grep LC \| grep -v LC_ALL \| cut -f1 -d'='); do
			export ${item}=en_DK.UTF-8
			done

			# Override numeric and monetary formatting to get a dot as the decimal separator
			export LC_NUMERIC=en_IE.utf8
			export LC_MONETARY=en_IE.utf8
			</syntaxhighlight>

			With that in place, <code>locale</code> reports a mixed setup like:

			<syntaxhighlight lang="text">
			LANG=en_IE.UTF-8
			LANGUAGE=
			LC_CTYPE=en_DK.UTF-8
			LC_NUMERIC=en_IE.UTF-8
			LC_TIME=en_DK.UTF-8
			LC_COLLATE=en_DK.UTF-8
			LC_MONETARY=en_IE.UTF-8
			LC_MESSAGES=en_DK.UTF-8
			LC_PAPER=en_DK.UTF-8
			LC_NAME=nl_NL.utf8
			LC_ADDRESS=nl_NL.utf8
			LC_TELEPHONE=nl_NL.utf8
			LC_MEASUREMENT=en_DK.UTF-8
			LC_IDENTIFICATION=en_DK.UTF-8
			LC_ALL=
			</syntaxhighlight>

			== See also ==

			* [[Installing Personal Software]]

Requesting new software

Haars0011 — Tue, 16 Jun 2026 13:42:04 GMT

Haars0011 moved page Requesting new software to Requesting New Software Phase 1 § 5 P1.5.9: rename to match menu leaf casing (Requesting New Software), consistent with other § 5 / § 4 page titles (via move-page on MediaWiki MCP Server)

New page

Anyone can request the addition of new GUI-based software to the Anunna HPC environment, delivered via Open OnDemand, by following the procedure below.

=== Procedure ===

# Navigate to: https://ideas.anunna.wur.nl/
# In the menu bar, select ''Software Requests''.
# Search to determine whether the software you require has already been requested.
# Evaluation and Planning
## If an existing request is found, please vote for that request to indicate your support.
## If no existing request is available, select '''Submit Feedback''' and provide a clear description of the software you would like to see added to the portal. Include relevant details such as:
##* Software name and version
##* Intended use case (research, teaching, project)
##* Estimated number of users
##* Licensing requirements (if applicable)

=== Evaluation and Planning ===
The Anunna team evaluates submitted requests, provides feedback where needed, and assesses technical feasibility and licensing implications.

If approved and technically feasible, the request is added to the product backlog and scheduled for implementation in a future development sprint based on priority and available capacity.

Installing Personal Software

Haars0011 — Tue, 16 Jun 2026 13:40:26 GMT

← Older revision		Revision as of 13:40, 16 June 2026
Line 52:		Line 52:

	export myScratch=/lustre/scratch/$affiliation/$USER		export myScratch=/lustre/scratch/$affiliation/$USER
	export myBackup=/lustre/backup~~/GUESTS~~/$affiliation/$USER		export myBackup=/lustre/backup/$affiliation/$USER
	export myNobackup=/lustre/nobackup/$affiliation/$USER		export myNobackup=/lustre/nobackup/$affiliation/$USER

Line 124:		Line 124:

	<syntaxhighlight lang="bash">		<syntaxhighlight lang="bash">
	module load sl7-libs/main		module load legacy sl7-libs/main
	</syntaxhighlight>		</syntaxhighlight>Be aware that this bad practice, if you really need to keep old software running, you are better off putting it inside a container. See the [[Apptainer]] page

	=== Older binaries in a Jupyter kernel ===		=== Older binaries in a Jupyter kernel ===

Old binaries

Haars0011 — Tue, 16 Jun 2026 13:34:47 GMT

Phase 1 § 5 P1.5.3: content merged into Installing Personal Software (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 13:34, 16 June 2026
Line 1:		Line 1:
	~~On Linux, most binaries rely on shared libraries that are loaded by the OS before the binary is executed.~~		#REDIRECT [[Installing Personal Software#Running older binaries]]

	This allows them to share common runtimes, and avoid having to redo the same work multiple times. This is useful for optimisation and security, as debugging only has to be done in one place for multiple applications.

	However, a significant number of these libraries are automatically inserted by the OS, and as the cluster upgrades and changes some of these will no longer be automatically available. This will make older installs fail to execute, giving, for instance, errors related to glibc, or missing symbols.

	~~Thankfully, the entire library from previous OS builds is made available on the shared filesystem, granting~~ older binaries ~~the ability to access them whilst also running on a younger OS.~~

	There is a special environment variable: <code>LD_LIBRARY_PATH</code> which tells the linker (ld) where extra to go find libraries. We use this extensively in the underlying module system on Anunna to control which libraries can be used. One such module, <code>sl7_libs</code> automatically adds the older libraries in to older binaries, and has been added as a prerequisite for most older installs.


	~~If you've compiled something yourself that isn't a module, you may find yourself needing this module. Simply:~~

	~~<code>~~
	~~module load sl7-libs/main~~
	~~</code>~~

	~~To add this path.~~


	~~== Jupyter ==~~

	~~This may also extend to custom-built kernels on Jupyter. Here, however, you can't add this module, as instantiating a kernel is done though <code>kernel.json</code> instead of bash.~~

	~~To add the needed libraries, you need to modify your notebook to look like the following:~~
	~~<code>~~
	{
	~~"language": "python",~~
	~~"argv": [~~
	~~"/path/to/my/venv/bin/python",~~
	~~"-m",~~
	~~"ipykernel",~~
	~~"-f",~~
	~~"{connection_file}"~~
	],
	~~"display_name": "myvenv",~~
	~~"env" : {"LD_LIBRARY_PATH": "/usr/lib:/usr/lib64:/usr/lib/x86_64-linux-gnu:/shared/legacyapps/sl7-libs/lib:/shared/legacyapps/sl7-libs/lib64" }~~
	}
	~~</code>~~

	~~When editing JSON, please be mindful that all elements in an object must be separated by commas, and that only doublequotes may be used.~~


	~~To test your JSON, try the following:~~

	~~<code>~~
	~~cat ~/.local.share/jupyter/kernels/mykernel/kernel.json \| jq~~
	~~</code>~~

	~~If <code>jq</code> repeats your JSON, then it can parse it and you are good to go.~~

Setting local variables

Haars0011 — Tue, 16 Jun 2026 13:34:46 GMT

Phase 1 § 5 P1.5.3: content merged into Installing Personal Software (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 13:34, 16 June 2026
Line 1:		Line 1:
	~~== Environment Variables ==~~		#REDIRECT [[Installing Personal Software]]

	~~== Modify <code>.bashrc</code> and <code>.bash_profile</code> ==~~

	~~=== Adding custom directories to the system PATH ===~~

	~~<pre>~~

	~~PATH=$PATH:$HOME/bin:$HOME/bin/bin~~

	~~export PATH~~
	~~</pre>~~

	~~=== Increase number of commands remembered in the history ===~~

	~~<pre>~~
	# ~~Maximum numbers of lines that can be written to the file~~
	~~export HISTFILESIZE=100000~~

	~~# Change this to a reasonable number of lines to save~~
	~~export HISTSIZE=100000~~
	~~</pre>~~

	~~== See also ==~~
	* [[Anunna \| Anunna]]
	* [[Lx6_and_Lx7_compute_nodes \| Lx6 and Lx7 compute nodes]]
	* [[Create_shortcut_log-in_command \| Create a shortcut for the ssh log-in command]]
	* [[~~Installing_R_packages_locally \|~~ Installing ~~R packages locally~~]]

	~~== External links ==~~

Setting TMPDIR

Haars0011 — Tue, 16 Jun 2026 13:34:45 GMT

Phase 1 § 5 P1.5.3: content merged into Installing Personal Software (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 13:34, 16 June 2026
Line 1:		Line 1:
	~~'''Note: all nodes are partioned with a large /tmp (+- 400G).'''~~		#REDIRECT [[Installing Personal Software#Custom temporary directory (TMPDIR)]]

	Many programs require writing intermediary or temporary information. A process may even require writing to a temporary location without a user knowing it. For instance, the command <code>sort</code>, part of the <code>bash</code> toolkit, requires a lot of temporary file space when sorting large volumes of data. Often programs take the system default, which is usually <code>/tmp</code> on Linux systems. The <code>/tmp</code> partition is however often too limited in size and can get filled up. When this happens all users that require write access to <code>/tmp</code> will experience problems in running jobs, which can range from unexpected quitting of processes, to erroneous output.

	~~== Overriding the system default - works for many applications (but not all) ==~~

	Users can set a custom temporary folder location by setting the <code>TMPDIR</code> environment variable. A custom temporary folder location is best placed in the 'scratch' space on the /lustre filesystem, because this will ensure periodic tidying up of the custom temporary directory thereby reducing the opportunity for very large temporary files that have gone unnoticed to remain on the filesystem. In addition, this is in line with protocols for the default system temporary directory <code>/tmp</code> as this directory is also periodically purged of older files.

	~~First, create a temporary directory on user designated space on on the 'scratch' partition:~~
	~~<pre>~~
	~~mkdir /lustre/scratch/WUR/ABGC/~~[~~user]/tmp~~
	~~</pre>~~

	Set the <code>TMPDIR</code> variable to point at the custom directory in either <code>~/.bash_profile</code> or <code>~/.bashrc</code> using a command-line editor of choice (vi, emacs, nano, etc), adding the following line of code:
	~~<pre>~~
	~~export TMPDIR=/lustre/scratch/WUR/ABGC/~~[~~user]/tmp~~
	~~</pre>~~

	~~The~~ temporary directory ~~will be set to the custom location once you log in. For the current open terminal to set the new location immediately, without need to log out and in again:~~
	~~<pre>~~
	~~source ~/.bash_profile~~
	~~</pre>~~

	~~Note that certain~~ (~~compiled~~) ~~apps may in fact ignore the <code>TMPDIR</code> environment variable. These can include Java-apps and c++/g++ compiled apps.~~

	~~== Setting custom temporary directory for Java applications ==~~

	Java applications often do not respond properly to re-setting of the system default by manipulating the <code>TMPDIR</code> environment variable. Java behaviour can be modified by setting the <code>_JAVA_OPTIONS</code> environment variable:
	~~<pre>~~
	~~export _JAVA_OPTIONS=-Djava.io.tmpdir=/lustre/scratch/WUR/ABGC/[user]/tmp~~
	~~</pre>~~
	Note that this does not - strictly speaking - manipulates a temporary directory specific environment variable; rather it sets a Java specific environment variable that allows to pass options to Java on runtime.

	~~== See also ==~~
	~~[[Main_Page#Being_in_control_of_Environment_parameters \| Controling environment on the Agrogenomics cluster~~]]

	~~== External links ==~~

Aliases and local variables

Haars0011 — Tue, 16 Jun 2026 13:34:44 GMT

Phase 1 § 5 P1.5.3: DRAFT completed and folded into Installing Personal Software (canonical $myScratch convention) (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 13:34, 16 June 2026
Line 1:		Line 1:
	~~'''DRAFT'''~~		#REDIRECT [[Installing Personal Software#Aliases and local variables]]

	* motivation for aliases and variables
	* Brief explanation of what aliases are
	* Some basic commands

	~~===Example ~/.bash_aliases===~~

	~~‎<pre>~~
	#~~!/bin/bash~~
	#~~Define editor~~

	~~editor='nano' #or vim~~

	~~# Bash files commands~~
	~~alias ebc="${editor} ${HOME}/.bashrc"~~
	~~alias sbc="source ${HOME}/.bashrc"~~
	~~alias eba="${editor} ${HOME}/.bash_aliases"~~
	~~alias sba="source ${HOME}/.bash_aliases"~~

	~~# ls aliases~~
	~~alias ll="ls -alth"~~
	~~alias sl='ls'~~

	~~#location~~ variables
	~~# Note! that the location for the lustre folders depends on your affiliation~~
	~~# The <affiliation> field below is a place holder and it will break it not modified~~
	~~# For WUR researchers in a commitment group it will be~~
	~~# affiliation=WUR/<group>~~
	~~for external users belonging to an organization it will be~~
	~~# affiliation=<nameOfOrganization>~~

	~~# Modify this~~
	~~affiliation=~~

	~~export mySCRATCH=/lustre/scratch/$affiliation/$USER~~
	~~export myBKP=/lustre/backup/GUESTS/$affiliation/$USER~~
	~~export myNBKP=/lustre/nobackup/$affiliation/$USER~~

	#
	~~alias cds="cd $myScratch"~~
	~~alias cdb="cd $myBkp"~~
	~~alias cdn="cd $myNBkp"~~
	‎
	~~#Apoptainer cache location~~
	~~export APPTAINER_CACHEDIR=$myScratch/.apptainer-cache</pre>~~



	~~In order to make this effective, make sure that the following lines are in your ~/.bashrc~~

	~~‎<pre>~~
	~~if [ -f ~/.bash_aliases~~ ]~~; then~~
	~~. ~/.bash_aliases~~
	fi
	~~</pre>~~

Installing Personal Software

Haars0011 — Tue, 16 Jun 2026 13:34:36 GMT

Phase 1 § 5 P1.5.3 / Phase 2 P2.10: new hub merging Old binaries + Setting TMPDIR + Setting local variables + completed Aliases DRAFT. Canonical $myScratch/$myBackup/$myNobackup variable convention. (via create-page on MediaWiki MCP Server)

New page

This page covers the personal touches that make Anunna comfortable to work on: shell configuration, aliases, environment variables, a custom temporary directory, and a workaround for running older binaries. None of this is required to use the cluster, but most regular users set up at least some of it.

For installing actual software, the recommended routes are language- or tool-specific:

* '''Python''' — virtual environments and Jupyter kernels: see [[Python]].
* '''R''' — local package libraries: see [[R]].
* '''Containers''' — anything else, packaged reproducibly: see [[Apptainer]].
* '''Cluster-wide modules''' — request a shared install: see [[Environment Modules]].

== Shell configuration files ==

Your shell reads a couple of files when it starts:

* <code>~/.bashrc</code> — read by interactive non-login shells. This is the usual place for aliases and most environment variables.
* <code>~/.bash_profile</code> — read by login shells. Often it just sources <code>~/.bashrc</code> so both kinds of shell behave the same.

Keeping your aliases and variables in a separate <code>~/.bash_aliases</code> file (sourced from <code>~/.bashrc</code>) keeps things tidy. Add this to <code>~/.bashrc</code> so the file is picked up:

<syntaxhighlight lang="bash">
if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi
</syntaxhighlight>

== Aliases and local variables ==

An '''alias''' is a short name for a longer command; a '''local variable''' stores a value (such as a path) you reuse often. Defining a handful of both saves a lot of typing.

The example below is a complete <code>~/.bash_aliases</code>. It defines convenience aliases plus three variables that point at your personal directories on the [[Filesystems | Lustre filesystem]] — <code>$myScratch</code>, <code>$myBackup</code>, and <code>$myNobackup</code>. Other pages (for example [[Apptainer]]) assume these variables exist, so this is the recommended place to set them.

<syntaxhighlight lang="bash">
#!/bin/bash

# Preferred editor
editor='nano' # or vim

# Edit / source the bash config files
alias ebc="${editor} ${HOME}/.bashrc"
alias sbc="source ${HOME}/.bashrc"
alias eba="${editor} ${HOME}/.bash_aliases"
alias sba="source ${HOME}/.bash_aliases"

# ls shortcuts
alias ll="ls -alth"

# Personal Lustre locations.
# The 'affiliation' depends on your group:
# WUR researchers in a commitment group: affiliation=WUR/<group>
# External users: affiliation=<organisation>
# Set this before the exports below — leaving it empty will break the paths.
affiliation=

export myScratch=/lustre/scratch/$affiliation/$USER
export myBackup=/lustre/backup/GUESTS/$affiliation/$USER
export myNobackup=/lustre/nobackup/$affiliation/$USER

# Jump to those locations
alias cds="cd $myScratch"
alias cdb="cd $myBackup"
alias cdn="cd $myNobackup"

# Keep the Apptainer cache off your home quota (see Apptainer page)
export APPTAINER_CACHEDIR=$myScratch/.apptainer-cache
</syntaxhighlight>

After editing the file, either log in again or run <code>source ~/.bash_aliases</code> to apply the changes to your current shell.

== Environment variables ==

Beyond the variables above, two common tweaks go in <code>~/.bashrc</code>.

Add a personal <code>bin</code> directory to your <code>PATH</code> so your own scripts run by name:

<syntaxhighlight lang="bash">
export PATH=$PATH:$HOME/bin
</syntaxhighlight>

Keep more shell history:

<syntaxhighlight lang="bash">
# Lines kept in the history file on disk
export HISTFILESIZE=100000
# Lines kept in memory for the current session
export HISTSIZE=100000
</syntaxhighlight>

== Custom temporary directory (TMPDIR) ==

Many programs write intermediate or temporary files, sometimes without telling you — <code>sort</code>, for instance, needs a lot of scratch space for large inputs. By default they use <code>/tmp</code>. Every compute node has a large local <code>/tmp</code> (around 400 GB), but it is shared, and a job that fills it can cause other users' jobs to fail with anything from a crash to silently wrong output.

To send temporary files somewhere with more room, set the <code>TMPDIR</code> environment variable to a directory in your scratch space. Scratch is a good choice because it is periodically tidied up, so stray temporary files do not linger.

First create the directory:

<syntaxhighlight lang="bash">
mkdir -p $myScratch/tmp
</syntaxhighlight>

Then set <code>TMPDIR</code> in <code>~/.bash_profile</code> or <code>~/.bashrc</code>:

<syntaxhighlight lang="bash">
export TMPDIR=$myScratch/tmp
</syntaxhighlight>

It takes effect on your next login; to apply it to the current shell immediately, <code>source</code> the file you edited.

=== Java applications ===

Some compiled applications — Java programs in particular, and some C/C++ binaries — ignore <code>TMPDIR</code>. For Java, set the temporary directory through <code>_JAVA_OPTIONS</code> instead:

<syntaxhighlight lang="bash">
export _JAVA_OPTIONS=-Djava.io.tmpdir=$myScratch/tmp
</syntaxhighlight>

This is not strictly a temporary-directory variable; it passes a runtime option to the JVM that happens to set the temporary directory.

== Running older binaries ==

Most Linux binaries depend on shared libraries loaded by the operating system at runtime. As the cluster's OS is upgraded, some of those libraries change or disappear, and an older binary may then fail with errors about <code>glibc</code> or missing symbols.

The libraries from previous OS builds are kept on the shared filesystem so that older binaries can still find them. The <code>LD_LIBRARY_PATH</code> environment variable tells the linker where to look for libraries, and a module — <code>sl7-libs</code> — sets it up for you. It is already a prerequisite of most older module installs, so usually you do not need to do anything.

If you have compiled something yourself that is not a module and it fails this way, load the module by hand:

<syntaxhighlight lang="bash">
module load sl7-libs/main
</syntaxhighlight>

=== Older binaries in a Jupyter kernel ===

A custom [[Jupyter]] kernel cannot load a module, because the kernel is started from a <code>kernel.json</code> file rather than a shell. Instead, set <code>LD_LIBRARY_PATH</code> directly in the kernel's environment block:

<syntaxhighlight lang="json">
{
"language": "python",
"argv": [
"/path/to/my/venv/bin/python",
"-m",
"ipykernel",
"-f",
"{connection_file}"
],
"display_name": "myvenv",
"env": {
"LD_LIBRARY_PATH": "/usr/lib:/usr/lib64:/usr/lib/x86_64-linux-gnu:/shared/legacyapps/sl7-libs/lib:/shared/legacyapps/sl7-libs/lib64"
}
}
</syntaxhighlight>

When editing JSON, remember that every entry in an object is separated by a comma and only double quotes are allowed. Check that the file is valid by piping it through <code>jq</code>:

<syntaxhighlight lang="bash">
cat ~/.local/share/jupyter/kernels/mykernel/kernel.json | jq
</syntaxhighlight>

If <code>jq</code> prints your JSON back, it parses correctly.

== See also ==

* [[Environment Modules]]
* [[Locale settings]]
* [[Python]]
* [[R]]
* [[Apptainer]]
* [[Filesystems]]

Using environment modules

Haars0011 — Tue, 16 Jun 2026 13:21:01 GMT

Phase 1 § 5 P1.5.2: content merged into Environment Modules (superseded pre-Lmod content dropped) (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 13:21, 16 June 2026
Line 1:		Line 1:
	~~=== Environment Modules ===~~		#REDIRECT [[Environment Modules]]
	[http://modules.sourceforge.net/ Environment modules] are a simple way to allow multiple potentially clashing programs to coexist on a large shared machine such as an HPC. It allows a user to specify exactly which programs are loaded, and even which version of each program, whilst simultaneously allowing the administrator the ability to automatically configure the appropriate environment variables for the system itself.

	~~== Viewing Modules ==~~
	~~Upon logging in to Anunna, you should find that when you do:~~
	~~module list~~

	~~You will see something like this:~~
	~~<source lang='bash'>~~
	~~-bash-4.1$ module list~~
	~~Currently Loaded Modulefiles:~~
	~~1) shared 2) slurm/2.5.7~~
	~~</source>~~

	~~This is a list of all loaded modules in your shell session. To get a list of all available modules, simply~~
	~~module available~~

	~~And this will show you the (very exhaustive) list of modules on Anunna:~~

	~~<source lang='bash'>~~
	~~-bash-4.1$ module avail~~

	~~---------------------------- /shared/modulefiles ----------------------------~~
	~~acml/gcc/64/5.3.1 netcdf/gcc/64/4.1.3~~
	~~acml/gcc/fma4/5.3.1 netcdf/gcc/64/4.3.0~~
	~~acml/gcc/mp/64/5.3.1 netcdf/gcc/64/4.3.2~~
	~~acml/gcc/mp/fma4/5.3.1 netcdf/gcc/64/4.3.3~~
	~~acml/gcc-int64/64/5.3.1 netcdf/gcc/64/4.3.3.1~~
	~~acml/gcc-int64/fma4/5.3.1 netcdf/intel/64/4.1.3~~
	~~...~~
	~~</source>~~

	Let's look at each of these module names. Each module is named for the application it provides, plus a subfolder of which compiler it was compiled with (if compiled), the number of address bits or options (if compiled), and the version.

	~~If you want to see a list for a specific module, you can~~
	~~module avail netcdf~~

	~~And the complete list of versions will be shown.~~

	~~== Loading Modules ==~~
	~~To load a module, simply~~
	~~module load foo~~

	~~And the most recent version of module foo will automatically be loaded. If foo is compiled, it will automatically select the gcc version. If you want to specify a certain version, then~~
	~~module load foo/gcc/64/1.0.0~~

	Will load foo version 1, compiled with gcc. Be advised that this may not always work, as some modules are not compatible with each other, but a message will be shown if this is the case. Additionally, some modules will automatically load other modules with them for them to operate.

	~~== Unloading Modules ==~~
	~~If you want to remove a module that you've loaded, then~~
	~~module unload foo~~

	~~Will remove all module foo's loaded.~~


	~~== Example ==~~
	~~Consider this simple python3 script that should calculate Pi to 1 million digits:~~
	~~<source lang='python'>~~
	from decimal import *
	~~D=Decimal~~
	~~getcontext().prec=10000000~~
	~~p=sum(D(1)/16*k(D(4)/(8k+1)-D(2)/(8k+4)-D(1)/(8k+5)-D(1)/(8k+6))for k in range(411))~~
	~~print(str(p)[:10000002])~~
	~~</source>~~

	~~This script will not run at all in the default 2.4 version of Python on the cluster. In order for this script to run you must use Python3. To do this, first list all versions of Python:~~
	~~<source lang='bash'>~~
	~~-bash-4.1$ module avail python~~

	~~---------------------------- /shared/modulefiles ----------------------------~~
	~~python/2.7.6 python/3.3.3 python/3.4.2~~
	~~</source>~~

	~~Then you can load the specific version you need:~~
	~~module load python/3.3.3~~

	~~Now you have access to the executable python3.~~

	~~== See also ==~~
	* [[~~Environment_Modules \|~~ Environment Modules]]
	* [[Control_R_environment_using_modules \| Control R environment using modules]]
	* [[Create_shortcut_log-in_command \| Create a shortcut for the ssh log-in command]]
	* [[Installing_R_packages_locally \| Installing R packages locally]]

	~~== External links ==~~
	* http://modules.sourceforge.net
	* https://modules.readthedocs.io/en/latest/ (documentation)
	* http://www.admin-magazine.com/HPC/Articles/Environment-Modules

Modules

Haars0011 — Tue, 16 Jun 2026 13:21:00 GMT

Phase 1 § 5 P1.5.2: content merged into Environment Modules (canonical menu leaf) (via update-page on MediaWiki MCP Server)

Show changes

Environment Modules

Haars0011 — Tue, 16 Jun 2026 13:20:51 GMT

Phase 1 § 5 P1.5.2: merge Modules + Environment Modules + Using environment modules into the canonical Environment Modules page. Base content from Modules (Lmod/buckets), salvaged switching+conflicts concept, dropped pre-Lmod stale content. (via update-page on MediaWiki MCP Server)

Show changes

Array jobs

Haars0011 — Tue, 16 Jun 2026 09:56:56 GMT

Haars0011 moved page Array jobs to Array Jobs Phase 1 § 4 cosmetic: rename Array jobs → Array Jobs for casing consistency with sibling pages (Batch Jobs, Interactive Jobs, Cancelling Jobs, Monitoring Jobs) (via move-page on MediaWiki MCP Server)

New page

SLURM can simplify your efforts if you are planning on submitting multiple independent jobs in parallel. Rather than having to use sbatch multiple times, you can instead use an array job to run your job.

Take the following example:

<pre>
#SBATCH --output=output_%A.%a.txt
#SBATCH --error=error_%A.%a.txt
#SBATCH --time=10
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=1
#SBATCH --mem-per-cpu=4000
#SBATCH --array=0-9%4

echo $SLURM_ARRAY_TASK_ID

</pre>
Let's break this down step by step:

<pre>
#SBATCH --output=output_%A.%a.txt
#SBATCH --error=error_%A.%a.txt
</pre>
This makes sure your job outputs to a file called output_<Jobnumber>.<Arrayid>.txt, allowing you to track which array ID returned what.

<pre>
#SBATCH --array=0-9%4
</pre>
This defined the array job itself. This specifies to run ten jobs, with array id's of 0 to 9, but not to allow more than 4 to run at once. The syntax for this allows you to specify exactly what ID's to use, for example:
<pre>
#SBATCH --array=3,7-11
</pre>
will only run array tasks with ID's of 3, 7, 8, 9, 10 and 11.

<pre>
echo $SLURM_ARRAY_TASK_ID
</pre>
This will print to stdout (and get redirected to output_%A.%a.txt) the environment variable set by SLURM that indicates which Array ID this process has.

So, once this job is run, we will end up with ten files, all called output_<jobid>.<n>.txt, containing the number n.

== Two dimensional arrays? ==
Running an array such as above will result in a one dimensional string of jobs, for example, with --array=0-9, then
<pre>
SLURM_ARRAY_TASK_ID=[ 0 1 2 3 4 5 6 7 8 9 ]
</pre>
for each job. What if you need two variables to change instead of one?

Well, there's a simple function called modulo that can solve this. Let's use an example with a modulo of 10, and an example number of 93:
<pre>
A=$((93 / 10)) # A = 9
B=$((93 % 10)) # B = 3
</pre>

As you can see, this splits the number in half, allowing a job array of 0-99 to be made into two variables, traversing a 2D array. Bear in mind this always starts at 0, so if you need, say, A to be 1-5, and B to be 3-8, then:

<pre>
#SBATCH --array=0-29 ## 5*6 entries, thus 30, including 0 this is 0-29
A=$((SLURM_ARRAY_TASK_ID/5+1)) # A = [0-4]+1 = [1-5]
B=$((SLURM_ARRAY_TASK_ID%6+3)) # B = [0-5]+3 = [3-8]
mywork $A $B
</pre>

Fair Use Policy

Haars0011 — Tue, 16 Jun 2026 09:55:06 GMT

Phase 2 P2.8: create stub for Fair Use Policy — placeholder pending full policy text (via create-page on MediaWiki MCP Server)

New page

This page will document the Anunna fair-use expectations: what counts as reasonable cluster behaviour and what crosses the line. It is currently a placeholder; the full policy is being drafted.

Until the policy is written, the rules of thumb embedded in other pages still apply:

* Do not run heavy work on the login nodes — submit jobs through SLURM. See [[Scheduler Overview (Slurm)]].
* Keep reservations to at most three nodes so you don't disrupt the rest of the cluster. See [[Reservations]].
* Clean up <code>/tmp</code> on a compute node after your job ends. See [[Batch Jobs]].

== See also ==

* [[Scheduler Overview (Slurm) | Scheduler overview]]
* [[Reservations]]
* [[Batch Jobs]]

Node usage graph

Haars0011 — Tue, 16 Jun 2026 09:55:02 GMT

Phase 1 § 4 redirect: content merged into Monitoring Jobs (P1.4.7) (via update-page on MediaWiki MCP Server)

Show changes

SACCT

Haars0011 — Tue, 16 Jun 2026 09:55:01 GMT

Phase 1 § 4 redirect: content merged into Monitoring Jobs (P1.4.7) (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 09:55, 16 June 2026
Line 1:		Line 1:
	~~The command~~ [~~http://slurm.schedmd.com/sacct.html sacct] is meant to show your usage of Anunna.~~		#REDIRECT [[Monitoring Jobs]]

	~~For instance at the login screen the command: sacct -a gives the following result:~~

	~~<syntaxhighlight lang="bash">~~
	~~user001@login200:~$ sacct -a~~
	~~</syntaxhighlight>~~[~~[File:sacct capture.jpg]]~~

	~~It is a standard view to see all the users jobs of that day.~~
	~~Better is to modify this command with special parameters to see what you are using from Anunna.<syntaxhighlight lang="bash">~~
	~~user001@login200:~$ sacct -P -X --delimiter=',' -S 2026-01-01 -E 2026-02-01 \~~
	~~--format=comment%15,User,Partition%20,JobID,JobName,ncpus,nnodes,NodeList,Start,alloccpus,cputime%12,cputimeraw,state > usage_report_$(date -I).csv~~

	~~</syntaxhighlight>The csv-file can be uploaded in Excel. This gives you the next overview.~~
	~~Cputimeraw is the time of cpu-usage in seconds. The parameters "-S 2026-01-01 -E 2026-02-01" give you the start date and the end date of period you want to present.~~

	~~[[File:sacct uitgebreid.jpg~~]]

Creating sbatch script

Haars0011 — Tue, 16 Jun 2026 09:55:00 GMT

Phase 1 § 4 redirect: content merged into Batch Jobs (P1.4.4) (via update-page on MediaWiki MCP Server)

Show changes

Monitoring job execution

Haars0011 — Tue, 16 Jun 2026 09:54:58 GMT

Phase 1 § 4 redirect: content merged into Monitoring Jobs (P1.4.7) (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 09:54, 16 June 2026
Line 1:		Line 1:
			#REDIRECT [[Monitoring Jobs]]
	~~== Output stream redirection ==~~

	~~The primary way to monitor job execution is through the ''stdout'' and ''stderr'' streams. These are redirected to~~ [~~https://wiki.hpcagrogenomics.wur.nl/index.php/Creating_sbatch_script#output_.28stderr.2Cstdout.29_directed_to_file text files specified in the SLURM script].~~

	~~For this purpose the <code>tail</code> command is particularly useful. To continuously follow the output to a text file use:~~

	~~<code>tail -f output_987654.txt</code>~~

	~~To obtain the last X lines of a text file use:~~

	~~<code>tail -n X output_987654.txt</code>~~

	~~Replacing X by the desired number of lines.~~

	~~If the output file gets too long and you wish to read from the begining you may combine the commands <code>cat</code> and <code>less</code>:~~

	~~<code>cat output_987654.txt \| less</code>~~

	~~Use the Q key to exit <code>less</code>.~~

	== Monitoring ~~resource usage ==~~

	While the output streams may suffice in most cases, certain programmes might not provide much feedback. This could be the case with a programme that rellies on modules that are not verbose. In such situations it is best to monitor resource usage to gauge job execution. Two possible options are described below.

	~~=== Using sstat ===~~

	<code>sstat</code> is a SLURM tool that can be used to obtain instantaneous information on resource usage, CPU load, memory, etc. To use it start by changing your SLURM script so that your programme is launched with the <code>srun</code> command (this should be the last line in the script):

	~~<code>srun python3 calc_pi.py</code>~~

	~~Note down the job number. During execution you can then use <code>sstat</code>, passing the job number with the <code>-j</code> flag:~~

	~~<code>sstat --format=AveCPU,AveRSS,MaxRSS -P -j 987654</code>~~

	~~<code>sstat</code> can provide information on many different variables, for more details check [https://slurm.schedmd.com/sstat.html the manual~~].

	~~=== Using top ===~~

	~~Another way is to log the output of the [http://man7.org/linux/man-pages/man1/top.1.html <code>top</code>~~] ~~command. This requires adding an extra command to your SLURM script, again using <code>srun</code> (where "user001" should be replaced by your user name):~~

	~~<code>srun --overcommit --ntasks=1 top -b -u user001 &~~
	~~python3 calc_pi.py</code>~~

	~~This will log the output of <code>top</code> to the sdtout stream file specific in the SLURM script every 3 seconds. Using the <code>tail</code> command you will be able to see logs like:~~

	~~<pre>top - 18:09:12 up 53 days, 22:53, 0 users, load average: 27,04, 27,63, 26,53~~
	~~Tasks: 1068 total, 4 running, 1064 sleeping, 0 stopped, 0 zombie~~
	~~%Cpu(s): 41,9 us, 0,2 sy, 0,0 ni, 57,9 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st~~
	~~KiB Mem : 10439453+total, 18650486+free, 43690281+used, 42053763+buff/cache~~
	~~KiB Swap: 26214400+total, 26214393+free, 52 used. 54182425+avail Mem~~

	~~PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND~~
	~~29260 user001 20 0 15,6g 15,2g 17392 R 1777 1,5 4014:16 R~~
	~~29447 user001 20 0 178604 12900 1676 R 1,6 0,0 6:33.17 top~~
	~~28627 user001 20 0 113184 1520 1260 S 0,0 0,0 0:00.01 slurm_scri+~~
	~~29253 user001 20 0 245096 4792 1976 S 0,0 0,0 0:00.66 srun~~
	~~29357 user001 20 0 36124 688 16 S 0,0 0,0 0:00.00 srun</pre>~~

Monitoring executions

Haars0011 — Tue, 16 Jun 2026 09:54:57 GMT

Phase 1 § 4 redirect cleanup: re-point from Monitoring job execution to Monitoring Jobs (post-merge target) (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 09:54, 16 June 2026
Line 1:		Line 1:
	#REDIRECT [[Monitoring ~~job execution~~]]		#REDIRECT [[Monitoring Jobs]]

Scheduler Overview (Slurm)

Haars0011 — Tue, 16 Jun 2026 09:48:47 GMT

Phase 1 § 4 P1.4.1: trim to overview only — content split into Partitions / Queues, Choosing a node (constraints), Batch Jobs, Interactive Jobs, Cancelling Jobs, Monitoring Jobs (separate pages). This page is now the entry point with QoS overview and topic index. (via update-page on MediaWiki MCP Server)

Show changes

Talk:Using Slurm

Haars0011 — Tue, 16 Jun 2026 09:48:13 GMT

Haars0011 moved page Talk:Using Slurm to Talk:Scheduler Overview (Slurm) Phase 1 § 4 P1.4.1: rename Using Slurm → Scheduler Overview (Slurm) as part of the § 4 refactor (via move-page on MediaWiki MCP Server)

New page

Let's talk....

== Good examples ==

We need some good examples for the SLURM page, or maybe a set of pages that derive from this one that depict some tutorial-style examples.

Using Slurm

Haars0011 — Tue, 16 Jun 2026 09:48:13 GMT

Haars0011 moved page Using Slurm to Scheduler Overview (Slurm) Phase 1 § 4 P1.4.1: rename Using Slurm → Scheduler Overview (Slurm) as part of the § 4 refactor (via move-page on MediaWiki MCP Server)

New page

The resource allocation / scheduling software on Anunna is [http://en.wikipedia.org/wiki/Simple_Linux_Utility_for_Resource_Management SLURM]: '''S'''imple '''L'''inux '''U'''tility for '''R'''esource '''M'''anagement.

== Queues and defaults ==

=== Quality of Service ===
When submitting a job, you may optionally assign a different Quality of Service to it. You can do this with:

<pre>
#SBATCH --qos=std
</pre>

By default, jobs will use std, the standard quality.

Optionally, you may elect to reduce the priority of your jobs to low. This comes with a limit of how long each job can be (8h) to prevent the cluster from being locked up entirely with low priority jobs.

The high quality provides a higher priority to jobs (20) than std (10), or low (1). It is naturally more expensive.

The highest priority goes to jobs in interactive quality (100), but you may not submit many jobs or many large jobs as this quality. This is exclusively for the use of immediate running jobs, ones that are going to have hands-on users behind them.

Jobs may be restarted and rescheduled if a job with higher priority needs cluster resources, but as of right now, this is not occurring.

=== Queues ===
The cluster consists of multiple partitions of nodes that you can submit to. The primary one is 'main'. There are other partitions as needed - current plans include 'gpu'.

You can see the partitions available with `sinfo`:

=== Defaults ===
The default partition is 'main'. This will work for most jobs.

The default qos is 'std'.

The default cpu count is 1.

The default run time for a job is '''1 hour'''.

The maximum run time for a job is '''3 weeks'''.

The default memory limit is '''100MB per node'''.

== Submitting jobs: sbatch ==

=== Example ===
Consider this simple python3 script that should calculate Pi to 1 million digits:
<pre>
from decimal import *
D=Decimal
getcontext().prec=10000000
p=sum(D(1)/16**k*(D(4)/(8*k+1)-D(2)/(8*k+4)-D(1)/(8*k+5)-D(1)/(8*k+6))for k in range(411))
print(str(p)[:10000002])
</pre>

=== Loading modules ===
In order for this script to run, the first thing that is needed is that Python3, which is not the default Python version on the cluster, is load into your environment. Availability of (different versions of) software can be checked by the following command:
module avail

In the list you should note that python3 is indeed available to be loaded, which then can be loaded with the following command:
module load python/3.3.3

=== Batch script ===
[[Creating_sbatch_script | Main Article: Creating a sbatch script]]

The following shell/slurm script can then be used to schedule the job using the sbatch command:
<pre>
#!/bin/bash
#SBATCH --comment=773320000
#SBATCH --time=1200
#SBATCH --mem=2048
#SBATCH --cpus-per-task=1
#SBATCH --output=output_%j.txt
#SBATCH --error=error_output_%j.txt
#SBATCH --job-name=calc_pi.py
#SBATCH --mail-type=ALL
#SBATCH --mail-user=email@org.nl

time python3 calc_pi.py
</pre>

=== Submitting ===
The script, assuming it was named 'run_calc_pi.sh', can then be posted using the following command:
<pre>
sbatch run_calc_pi.sh
</pre>

=== Submitting multiple jobs (simple) ===
Assuming there are 10 job scripts, name runscript_1.sh through runscript_10.sh, all these scripts can be submitted using the following line of shell code:
<pre>for i in `seq 1 10`; do echo $i; sbatch runscript_$i.sh;done
</pre>

=== Submitting multiple jobs (complex) ===
Lets's say you have three job scripts that depend on each other:

<pre>job_1.sh #A simple initialisation script</pre>
<pre>job_2.sh #An array task</pre>
<pre>job_3.sh #Some finishing script, single run, after everything previous has finished</pre>

You can create a script to simultaneously submit each job with a dependency on each other:

<pre>#!/bin/bash
JOB1=$(sbatch job_1.sh| rev | cut -d ' ' -f 1 | rev) #Get me the last space-separated element

if ! [ "z$JOB1" == "z" ] ; then
echo "First job submitted as jobid $JOB1"
JOB2=$(sbatch --dependency=afterany:$JOB1 job_2.sh| rev | cut -d ' ' -f 1 | rev)

if ! [ "z$JOB2" == "z" ] ; then
echo "Second job submitted as jobid $JOB2, following $JOB1"
JOB3=$(sbatch --dependency=afterany:$JOB2 job_3.sh| rev | cut -d ' ' -f 1 | rev)

if ! [ "z$JOB3" == "z" ] ; then
echo "Third job submitted as jobid $JOB3, following after every element of $JOB2"

fi
fi
fi
</pre>

This will ensure that the subsequent jobs occur after any finishing of the former (even if they failed).

Please see [https://slurm.schedmd.com/sbatch.html#OPT_dependency the sbatch documentation] for other options available to you. Note that aftercorr makes a subsequent array jobs array elements start after the correspondingly numbered ones from the previous job.

=== Submitting array jobs ===
<pre>
#SBATCH --array=0-10%4
</pre>
SLURM allows you to submit multiple jobs using the same template. Further information about this can be found [[Array_jobs|here]].

=== Using /tmp ===
There is a local disk of ~300G that can be used to temporarily stage some of your workload attached to each node. This is free to use, but please remember to clean up your data after usage.

In order to be sure that you're able to use space in /tmp, you can add
<pre>
#SBATCH --tmp=<required size>
</pre>
To your sbatch script. This will prevent your job from being run on nodes where there is no free space, or it's aimed to be used by another job at the same time.

=== Using GPU ===

==== Nvidia GPUs ====
There are six GPU nodes with Nvidia GPUs, in order to run a job that uses a GPU on one of these nodes, you can add

<pre>
#SBATCH --gres=gpu:<num gpus>
#SBATCH --partition=gpu
</pre>
To your sbatch script. Without this parameter, your job won't run on one of these nodes.
Be sure to add the gres line, otherwise your job will either fail, or it will run on the CPU instead of on the GPU.

As we have different flavours of GPU's, you might want to select a type/manufacturer.

If you don't, you will get one that is available.

To see which types are available, run this :
<pre>
scontrol show -o node | grep -o -e "NodeName=\w*" -e "ActiveFeatures=[[:alnum:][:punct:]]*" | paste - - | column -t | grep gpu
</pre>
To select a certain type, use the flag:
<pre>
#SBATCH --constraint
</pre>
Example:
<pre>
# This will limit this job to the A100 GPUs
#SBATCH --constraint='nvidia&A100'
</pre>

A rough estimate is that the A100/80G cards are about twice as fast as the A6000/48G or the V100/16G. But this all depends on whether your analyses actually needs the RAM and can completely fill the GPU.
We have set up the scheduler in such a way that the A100s are chosen first, and then the A6000s, and lastly the V100s
The pricing for all is the same.

==== AMD GPUs ====
Besides the Nvidia GPUs, the cluster also has 2 nodes with AMD GPUs.

The way to use them is the same as for the Nvidia GPUs, just use the '''gpu_amd''' partition to select them.

== Monitoring submitted jobs ==
Once a job is submitted, the status can be monitored using the <code>squeue</code> command. The <code>squeue</code> command has a number of parameters for monitoring specific properties of the jobs such as time limit.

=== Generic monitoring of all running jobs ===
<pre>
squeue
</pre>

You should then get a list of jobs that are running at that time on the cluster, for the example on how to submit using the 'sbatch' command, it may look like so:
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
3396 ABGC BOV-WUR- megen002 R 27:26 1 node004
3397 ABGC BOV-WUR- megen002 R 27:26 1 node005
3398 ABGC BOV-WUR- megen002 R 27:26 1 node006
3399 ABGC BOV-WUR- megen002 R 27:26 1 node007
3400 ABGC BOV-WUR- megen002 R 27:26 1 node008
3401 ABGC BOV-WUR- megen002 R 27:26 1 node009
3385 research BOV-WUR- megen002 R 44:38 1 node049
3386 research BOV-WUR- megen002 R 44:38 1 node050
3387 research BOV-WUR- megen002 R 44:38 1 node051
3388 research BOV-WUR- megen002 R 44:38 1 node052
3389 research BOV-WUR- megen002 R 44:38 1 node053
3390 research BOV-WUR- megen002 R 44:38 1 node054
3391 research BOV-WUR- megen002 R 44:38 3 node[049-051]
3392 research BOV-WUR- megen002 R 44:38 3 node[052-054]
3393 research BOV-WUR- megen002 R 44:38 1 node001
3394 research BOV-WUR- megen002 R 44:38 1 node002
3395 research BOV-WUR- megen002 R 44:38 1 node003

=== Monitoring time limit set for a specific job ===
The default time limit is set at one hour. Estimated run times need to be specified when running jobs. To see what the time limit is that is set for a certain job, this can be done using the <code>squeue</code> command.
<pre>
squeue -l -j 3532
</pre>
Information similar to the following should appear:
Fri Nov 29 15:41:00 2013
JOBID PARTITION NAME USER STATE TIME TIMELIMIT NODES NODELIST(REASON)
3532 ABGC BOV-WUR- megen002 RUNNING 2:47:03 3-08:00:00 1 node054

=== Query a specific active job: scontrol ===
Show all the details of a currently active job, so not a completed job.
<pre>
login ~]$ scontrol show jobid 4241
JobId=4241 Name=WB20F06
UserId=megen002(16795409) GroupId=domain users(16777729)
Priority=1 Account=(null) QOS=normal
JobState=RUNNING Reason=None Dependency=(null)
Requeue=1 Restarts=0 BatchFlag=1 ExitCode=0:0
RunTime=02:55:25 TimeLimit=3-08:00:00 TimeMin=N/A
SubmitTime=2013-12-09T13:37:29 EligibleTime=2013-12-09T13:37:29
StartTime=2013-12-09T13:37:29 EndTime=2013-12-12T21:37:29
PreemptTime=None SuspendTime=None SecsPreSuspend=0
Partition=research AllocNode:Sid=login0:21799
ReqNodeList=(null) ExcNodeList=(null)
NodeList=node023
BatchHost=node023
NumNodes=1 NumCPUs=4 CPUs/Task=1 ReqS:C:T=*:*:*
MinCPUsNode=1 MinMemoryNode=0 MinTmpDiskNode=0
Features=(null) Gres=(null) Reservation=(null)
Shared=OK Contiguous=0 Licenses=(null) Network=(null)
Command=/lustre/scratch/WUR/ABGC/...
WorkDir=/lustre/scratch/WUR/ABGC/...
</pre>

=== Check on a pending job ===
A submitted job could result in a pending state when there are not enough resources available to this job.
In this example I sumbit a job, check the status and after finding out is it '''pending''' I'll check when is probably will start.
<pre>
[@login jobs]$ sbatch hpl_student.job
Submitted batch job 740338

[@login jobs]$ squeue -l -j 740338
Fri Feb 21 15:32:31 2014
JOBID PARTITION NAME USER STATE TIME TIMELIMIT NODES NODELIST(REASON)
740338 ABGC_Stud HPLstude bohme999 PENDING 0:00 1-00:00:00 1 (ReqNodeNotAvail)

[@login jobs]$ squeue --start -j 740338
JOBID PARTITION NAME USER ST START_TIME NODES NODELIST(REASON)
740338 ABGC_Stud HPLstude bohme999 PD 2014-02-22T15:31:48 1 (ReqNodeNotAvail)
</pre>
So it seems this job will problably start the next day, but's thats no guarantee it will start indeed.

== Removing jobs from a list: scancel ==
If for some reason you want to delete a job that is either in the queue or already running, you can remove it using the 'scancel' command. The 'scancel' command takes the jobid as a parameter. For the example above, this would be done using the following code:
<pre>
scancel 3401
</pre>

== Allocating resources interactively: sinteractive ==
sinteractive is a tiny wrapper on srun to create interactive jobs quickly and easily. It allows you to get a shell on one of the nodes, with similar limits as you would do for a normal job. To use it, simply run:
<pre>
sinteractive -c <num_cpus> --mem <amount_mem> --time <minutes> -p <partition>
</pre>
You will then be presented with a new shell prompt on one of the compute nodes (run 'hostname' to see which!). From here, you can test out code in an interactive fashion as needs be.

Be advised though - not filling in the above fields will get you a shell with 1 CPU and 100Mb of RAM for 1 hour. This is useful for quick testing, however.

=== sinteractive source ===
<pre>
#!/bin/bash
srun "$@" -I60 -N 1 -n 1 --pty bash -i
</pre>

=== interactive Slurm - using salloc ===
If you don't want your shell to be transported but want a new remote shell, do:
<pre>
salloc -p ABGC_Low $SHELL
</pre>
Now your shell will stay on the login node, but you can do:
<pre>
srun <command> &
</pre>
To submit tasks to this new shell!

Be aware that the time limit of salloc is default 1 hour. If you intend to run jobs for longer times than this, you need to edit the settings for it. See: https://computing.llnl.gov/linux/slurm/salloc.html

== Get overview of past and current jobs: sacct ==
To do some accounting on past and present jobs, and to see whether they ran to completion, you can do:
<pre>
sacct
</pre>
This should provide information similar to the following:

JobID JobName Partition Account AllocCPUS State ExitCode
------------ ---------- ---------- ---------- ---------- ---------- --------
3385 BOV-WUR-58 research 12 COMPLETED 0:0
3385.batch batch 1 COMPLETED 0:0
3386 BOV-WUR-59 research 12 CANCELLED+ 0:0
3386.batch batch 1 CANCELLED 0:15
3528 BOV-WUR-59 ABGC 16 RUNNING 0:0
3529 BOV-WUR-60 ABGC 16 RUNNING 0:0

Or in more detail for a specific job:
<pre>
sacct --format=jobid,jobname,comment,partition,ntasks,alloccpus,elapsed,state,exitcode -j 4220
</pre>
This should provide information about job id 4220:

JobID JobName Comment Partition NTasks AllocCPUS Elapsed State ExitCode
------------ ---------- ---------- ---------- -------- ---------- ---------- ---------- --------
4220 PreProces+ research 3 00:30:52 COMPLETED 0:0
4220.batch batch 1 1 00:30:52 COMPLETED 0:0

'''Job Status Codes'''

Typically your job will be either in the Running state of PenDing state. However here is a breakdown of all the states that your job could be in.

{| class="wikitable"
|-
!Code!!State!!Description
|-
|CA ||CANCELLED|| Job was explicitly cancelled by the user or system administrator. The job may or may not have been initiated.
|-
|CD|| COMPLETED|| Job has terminated all processes on all nodes.
|-
|CF|| CONFIGURING|| Job has been allocated resources, but are waiting for them to become ready for use (e.g. booting).
|-
|CG|| COMPLETING|| Job is in the process of completing. Some processes on some nodes may still be active.
|-
|F|| FAILED|| Job terminated with non-zero exit code or other failure condition.
|-
|NF|| NODE_FAIL|| Job terminated due to failure of one or more allocated nodes.
|-
|PD|| PENDING|| Job is awaiting resource allocation.
|-
|R|| RUNNING|| Job currently has an allocation.
|-
|S|| SUSPENDED|| Job has an allocation, but execution has been suspended.
|-
|TO|| TIMEOUT|| Job terminated upon reaching its time limit.
|-
|-
|}

== Running MPI jobs on Anunna ==

[[MPI_on_B4F_cluster | Main article: MPI on Anunna]]

== See also ==
* [[Tariffs | Costs associated with resource usage]]
* [[B4F_cluster | Anunna]]
* [[BCM_on_B4F_cluster | BCM on Anunna]]
* [[SLURM_Compare | SLURM compared to other common schedulers]]
* [[Setting_up_Python_virtualenv | Setting up and using a virtual environment for Python3 ]]

== External links ==
* [http://slurm.schedmd.com Slurm official documentation]
* [http://en.wikipedia.org/wiki/Simple_Linux_Utility_for_Resource_Management Slurm on Wikipedia]
* [http://www.youtube.com/watch?v=axWffyrk3aY Slurm Tutorial on Youtube]

Monitoring Jobs

Haars0011 — Tue, 16 Jun 2026 09:41:49 GMT

Phase 1 § 4 P1.4.7: merge Using Slurm § Monitoring + Monitoring job execution + SACCT + Node usage graph into Monitoring Jobs (via create-page on MediaWiki MCP Server)

New page

Once you have submitted a job, you usually want to keep an eye on it: is it queued or running, on which node, using how much memory, producing the output you expected. SLURM exposes this through a small collection of commands; each one answers a different question, and together they cover everything from "is it running" to "what did it cost me last month".

This page is a reference for the four common needs:

* '''Is the job in the queue, and where in the queue?''' — <code>squeue</code> and <code>scontrol</code>.
* '''Is the running job doing what I want?''' — the output streams from your script, plus <code>sstat</code> or <code>top</code> for live resource usage.
* '''What did finished jobs actually use?''' — <code>sacct</code>.
* '''How busy is the cluster overall?''' — <code>node_usage_graph</code>.

For submitting jobs see [[Batch Jobs]] and [[Interactive Jobs]]; to stop a job, see [[Cancelling Jobs]].

== Listing your jobs ==

<code>squeue</code> shows every job currently known to the scheduler. The most common form is just:

<syntaxhighlight lang="bash">
squeue
</syntaxhighlight>

To restrict it to your own jobs:

<syntaxhighlight lang="bash">
squeue -u $USER
</syntaxhighlight>

The <code>-l</code> flag adds the time limit set on each job (useful for spotting a misconfigured time request):

<syntaxhighlight lang="bash">
squeue -l -j <jobid>
</syntaxhighlight>

== Detailed information for one job ==

<code>scontrol show jobid</code> dumps everything SLURM knows about a job — start time, allocated nodes, command line, partition, account, exit code:

<syntaxhighlight lang="bash">
scontrol show jobid <jobid>
</syntaxhighlight>

This works for jobs that are currently in the system (running, pending, completing). Once a job has cleared the queue, use <code>sacct</code> (below) to get its accounting record.

== When will a pending job start? ==

If <code>squeue</code> shows your job as <code>PD</code> (pending) with a reason like <code>ReqNodeNotAvail</code>, SLURM has an estimate for when it can start:

<syntaxhighlight lang="bash">
squeue --start -j <jobid>
</syntaxhighlight>

The <code>START_TIME</code> column is an estimate — it can shift forward or backward as other jobs finish or new jobs arrive — but it is the best signal SLURM has.

== Tracking output streams ==

The output and error files declared in your batch script (see [[Batch Jobs]]) are written in real time. The most useful tool to follow them is <code>tail</code>:

<syntaxhighlight lang="bash">
tail -f output_<jobid>.txt
</syntaxhighlight>

This keeps the file open and prints new lines as your job writes them. Press <code>Ctrl-C</code> to stop following. To see only the last N lines instead of following:

<syntaxhighlight lang="bash">
tail -n <N> output_<jobid>.txt
</syntaxhighlight>

For a long output file you want to page through, use <code>less</code>:

<syntaxhighlight lang="bash">
less output_<jobid>.txt
</syntaxhighlight>

Press <code>q</code> to quit.

== Live resource usage ==

The output streams tell you what your code is logging; they don't tell you what it is actually using. For CPU load and memory while a job is running, you have two options.

=== sstat ===

<code>sstat</code> reports instantaneous resource usage. To use it your batch script needs to launch the work step under <code>srun</code> (so that SLURM tracks it as a job step). Example final line of the script:

<syntaxhighlight lang="bash">
srun python3 calc_pi.py
</syntaxhighlight>

Then, with the job ID from the submission, query a few useful fields:

<syntaxhighlight lang="bash">
sstat --format=AveCPU,AveRSS,MaxRSS -P -j <jobid>
</syntaxhighlight>

The full list of available fields is in [https://slurm.schedmd.com/sstat.html the sstat manual].

=== Logging top inside the job ===

If you want a continuous record of what the OS sees while the job runs, run <code>top</code> alongside your work and let its output land in the job's stdout. Add this near the start of the script (replace the username):

<syntaxhighlight lang="bash">
srun --overcommit --ntasks=1 top -b -u user001 &
python3 calc_pi.py
</syntaxhighlight>

The <code>&</code> backgrounds <code>top</code> so the real workload starts immediately. <code>top -b</code> runs in batch mode (no terminal control) and writes one snapshot every three seconds. The result in your output file looks like:

<syntaxhighlight lang="text">
top - 18:09:12 up 53 days, 22:53, 0 users, load average: 27,04, 27,63, 26,53
Tasks: 1068 total, 4 running, 1064 sleeping, 0 stopped, 0 zombie
%Cpu(s): 41,9 us, 0,2 sy, 0,0 ni, 57,9 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29260 user001 20 0 15,6g 15,2g 17392 R 1777 1,5 4014:16 R
29447 user001 20 0 178604 12900 1676 R 1,6 0,0 6:33.17 top
</syntaxhighlight>

== Historical accounting with sacct ==

<code>sacct</code> reports on jobs that have left the queue. It reads from the accounting database, so it works for both finished and still-running jobs, including ones from months back.

The simplest form lists today's jobs:

<syntaxhighlight lang="bash">
sacct -a
</syntaxhighlight>

For a real report — for instance an entire month, with the fields you actually care about, written out as CSV — pass <code>--format</code>, a date range, and the parsable flags:

<syntaxhighlight lang="bash">
sacct -P -X --delimiter=',' \
-S 2026-01-01 -E 2026-02-01 \
--format=comment%15,User,Partition%20,JobID,JobName,ncpus,nnodes,NodeList,Start,alloccpus,cputime%12,cputimeraw,state \
> usage_report_$(date -I).csv
</syntaxhighlight>

The flags break down as:

* <code>-P</code> writes parsable output (no column alignment, just delimited fields).
* <code>-X</code> hides the per-step rows and keeps just one row per job.
* <code>-S</code> / <code>-E</code> set the start and end of the window. Without these <code>sacct</code> only looks at today.
* <code>--format</code> selects the columns; the <code>%NN</code> suffix sets a width.
* <code>cputimeraw</code> is the field you usually want for cost analysis — total CPU-seconds.

The resulting CSV opens directly in Excel or any spreadsheet. The full field list is in [https://slurm.schedmd.com/sacct.html the sacct manual].

== Cluster-wide view: node_usage_graph ==

To see how busy the cluster as a whole is — which nodes are crunching, which are drained, which are reserved — use <code>node_usage_graph</code>. It is a small wrapper around <code>sacct</code> that renders a per-node bar chart in your terminal.

<syntaxhighlight lang="bash">
module load legacy
module load anunna
node_usage_graph
</syntaxhighlight>

The output is one row per node. Each row contains up to two strips of characters: the top strip shows CPU activity, the bottom shows memory:

<syntaxhighlight lang="text">
node: |0% 100%|
fat002: CCCCCCCCC
MMMMMmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
node003:CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
MM
node010:
node040:DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
node042:RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
</syntaxhighlight>

Letters mean:

* <code>C</code> — CPU reserved and in use
* <code>c</code> — CPU reserved but idle
* <code>M</code> — Memory reserved and in use
* <code>m</code> — Memory reserved but unused
* <code>D</code> — Drained node (unavailable for new jobs)
* <code>R</code> — Reserved node (held for a specific user or event — see [[Reservations]])
* <code>P</code> — Powered off (energy saving)

<code>node_usage_graph</code> shows current allocation but not the queue depth. For "how busy is the queue?" stick with <code>squeue</code>.

== Job status codes ==

<code>squeue</code> shows a two-letter code in the <code>ST</code> column. The most common are <code>R</code> (running), <code>PD</code> (pending), and <code>CG</code> (completing). The full list:

{| class="wikitable"
|-
! Code !! State !! Description
|-
| <code>CA</code> || CANCELLED || Job was explicitly cancelled by the user or a system administrator. The job may or may not have been initiated.
|-
| <code>CD</code> || COMPLETED || Job has terminated all processes on all nodes.
|-
| <code>CF</code> || CONFIGURING || Job has been allocated resources, but is waiting for them to become ready for use (e.g. booting).
|-
| <code>CG</code> || COMPLETING || Job is in the process of completing. Some processes on some nodes may still be active.
|-
| <code>F</code> || FAILED || Job terminated with a non-zero exit code or other failure condition.
|-
| <code>NF</code> || NODE_FAIL || Job terminated due to failure of one or more allocated nodes.
|-
| <code>PD</code> || PENDING || Job is awaiting resource allocation.
|-
| <code>R</code> || RUNNING || Job currently has an allocation.
|-
| <code>S</code> || SUSPENDED || Job has an allocation, but execution has been suspended.
|-
| <code>TO</code> || TIMEOUT || Job terminated upon reaching its time limit.
|}

== See also ==

* [[Batch Jobs]]
* [[Interactive Jobs]]
* [[Cancelling Jobs]]
* [[Reservations]]
* [[Using Slurm | Scheduler overview]]
* [https://slurm.schedmd.com/squeue.html squeue documentation]
* [https://slurm.schedmd.com/scontrol.html scontrol documentation]
* [https://slurm.schedmd.com/sstat.html sstat documentation]
* [https://slurm.schedmd.com/sacct.html sacct documentation]

Batch Jobs

Haars0011 — Tue, 16 Jun 2026 09:28:22 GMT

Phase 1 § 4 P1.4.4: merge Creating sbatch script + Using Slurm § Submitting into Batch Jobs (via create-page on MediaWiki MCP Server)

New page

A batch job is the standard way to run unattended work on Anunna. You write a shell script that declares the resources you need (CPUs, memory, wall time) and the commands you want to run, then hand the script to <code>sbatch</code>. SLURM queues the job, runs it on a compute node when resources are free, and writes the output to a file you specified.

This page covers the mechanics: how a batch script is laid out, what each <code>#SBATCH</code> directive does, and how to submit one or many jobs at once. For node selection (partition, GPU, hardware constraints) see [[Choosing a node (constraints)]]; for tracking submitted jobs see [[Monitoring job execution | Monitoring jobs]].

== A worked example ==

Suppose you have a Python script <code>calc_pi.py</code> that calculates π to one million digits:

<syntaxhighlight lang="python">
from decimal import *
D = Decimal
getcontext().prec = 10000000
p = sum(D(1)/16**k * (D(4)/(8*k+1) - D(2)/(8*k+4) - D(1)/(8*k+5) - D(1)/(8*k+6)) for k in range(411))
print(str(p)[:10000002])
</syntaxhighlight>

To run it on the cluster you need to (1) load the right Python module and (2) wrap the script in a batch submission file.

=== Loading modules ===

Check which Python versions are available:

<syntaxhighlight lang="bash">
module avail Python
</syntaxhighlight>

Pick one and load it from the appropriate year bucket — see [[Modules]] for the bucket-and-version convention.

=== Batch script ===

Save the following as <code>run_calc_pi.sh</code>:

<syntaxhighlight lang="bash">
#!/bin/bash
#SBATCH --comment=773320000
#SBATCH --time=1200
#SBATCH --mem=2048
#SBATCH --cpus-per-task=1
#SBATCH --output=output_%j.txt
#SBATCH --error=error_output_%j.txt
#SBATCH --job-name=calc_pi.py
#SBATCH --mail-type=ALL
#SBATCH --mail-user=email@org.nl

module load 2023
module load Python/3.11.3

time python3 calc_pi.py
</syntaxhighlight>

=== Submitting ===

Submit the job:

<syntaxhighlight lang="bash">
sbatch run_calc_pi.sh
</syntaxhighlight>

SLURM responds with a job ID. Track progress with [[Monitoring job execution | <code>squeue</code> and <code>sacct</code>]], or cancel with [[Cancelling Jobs | <code>scancel</code>]].

== Skeleton script ==

A reasonable starting template:

<syntaxhighlight lang="bash">
#!/bin/bash

#-----------------------------Mail address-----------------------------
#SBATCH --mail-user=
#SBATCH --mail-type=ALL
#-----------------------------Output files-----------------------------
#SBATCH --output=output_%j.txt
#SBATCH --error=error_output_%j.txt
#-----------------------------Other information------------------------
#SBATCH --comment=
#SBATCH --qos=
#-----------------------------Required resources-----------------------
#SBATCH --time=0-0:0:0
#SBATCH --ntasks=
#SBATCH --cpus-per-task=
#SBATCH --mem-per-cpu=

#-----------------------------Environment, Operations and Job steps----
# load modules

# export variables

# your job
</syntaxhighlight>

== Common #SBATCH directives ==

For partition, hardware constraints, and GPU requests see [[Choosing a node (constraints)]]. The directives below are the ones you use to size the job and control its bookkeeping.

=== Time limit ===

<syntaxhighlight lang="bash">
#SBATCH --time=1200
</syntaxhighlight>

Acceptable time formats: <code>minutes</code>, <code>minutes:seconds</code>, <code>hours:minutes:seconds</code>, <code>days-hours</code>, <code>days-hours:minutes</code>, <code>days-hours:minutes:seconds</code>. A time limit of zero disables the limit. The example above caps the job at 1200 minutes.

=== Memory ===

<syntaxhighlight lang="bash">
#SBATCH --mem=2048
</syntaxhighlight>

SLURM enforces a memory limit per job. The default is deliberately small — 100 MB per node — so most real work needs an explicit value. The argument is in MB (or use a suffix: <code>K</code>, <code>M</code>, <code>G</code>, <code>T</code>).

Pick a value slightly larger than what your job actually needs. Too low and the job is killed; too high and it is harder for SLURM to find a place to run it. A starting heuristic is 4000 MB per core; tune from there. To see what a finished job actually used:

<syntaxhighlight lang="bash">
sacct -o MaxRSS -j <jobid>
</syntaxhighlight>

The value is in KB; divide by 1024 to get MB. If the job finished a while ago, broaden the search with <code>-S YYYY-MM-DD</code>.

For multi-node jobs the value is the maximum used on any one node; uneven task distribution can make this fluctuate between runs.

=== Number of tasks and CPUs ===

<syntaxhighlight lang="bash">
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=1
</syntaxhighlight>

<code>sbatch</code> does not launch tasks itself — it reserves resources and runs the batch script. <code>--ntasks</code> tells SLURM the upper bound on job steps that may run inside the allocation; <code>--cpus-per-task</code> reserves that many CPUs for each task. The default is one task per node, but setting <code>--cpus-per-task</code> changes the default task count.

To pin the job to a single node:

<syntaxhighlight lang="bash">
#SBATCH --nodes=1
</syntaxhighlight>

If only one number is given for <code>--nodes</code>, SLURM treats it as both minimum and maximum.

=== Local disk on the compute node ===

<syntaxhighlight lang="bash">
#SBATCH --tmp=<required size>
</syntaxhighlight>

Each compute node has a local disk of around 300 GB at <code>/tmp</code> that you can use for staging. The disk is shared with other jobs on the node, so request the amount you need so SLURM places your job on a node where it is actually available. Clean up after yourself when the job ends.

=== Output and error files ===

<syntaxhighlight lang="bash">
#SBATCH --output=output_%j.txt
#SBATCH --error=error_output_%j.txt
</syntaxhighlight>

Redirect the batch script's standard output and standard error to files. The default for both is <code>slurm-%j.out</code>. The pattern <code>%j</code> is replaced with the job ID.

=== Job name ===

<syntaxhighlight lang="bash">
#SBATCH --job-name=calc_pi.py
</syntaxhighlight>

A short label that appears next to the job ID in <code>squeue</code>. Defaults to the script name, or <code>sbatch</code> if the script came from standard input.

=== Email notifications ===

<syntaxhighlight lang="bash">
#SBATCH --mail-type=ALL
#SBATCH --mail-user=yourname001@wur.nl
</syntaxhighlight>

Valid <code>--mail-type</code> values are <code>BEGIN</code>, <code>END</code>, <code>FAIL</code>, <code>REQUEUE</code>, and <code>ALL</code>. Combine with <code>--mail-user</code> to choose the recipient.

=== Comment / project accounting ===

<syntaxhighlight lang="bash">
#SBATCH --comment=773320000
</syntaxhighlight>

The comment is an arbitrary string that ends up in accounting records. For WUR users this is the place to put a project number or KTP number. The comment can be changed after submission with <code>scontrol</code>.

== Submitting many jobs at once ==

=== Simple loop ===

To submit ten independent scripts <code>runscript_1.sh</code> through <code>runscript_10.sh</code>:

<syntaxhighlight lang="bash">
for i in $(seq 1 10); do
echo "$i"
sbatch "runscript_${i}.sh"
done
</syntaxhighlight>

=== Job dependencies ===

To make one job wait for another to finish, capture the job ID returned by <code>sbatch</code> and pass it to the next submission via <code>--dependency</code>:

<syntaxhighlight lang="bash">
#!/bin/bash
JOB1=$(sbatch --parsable job_1.sh)
echo "Submitted $JOB1"

JOB2=$(sbatch --parsable --dependency=afterany:$JOB1 job_2.sh)
echo "Submitted $JOB2 (waits for $JOB1)"

JOB3=$(sbatch --parsable --dependency=afterany:$JOB2 job_3.sh)
echo "Submitted $JOB3 (waits for $JOB2)"
</syntaxhighlight>

The <code>--parsable</code> flag makes <code>sbatch</code> print just the job ID, which is convenient for capturing into a shell variable. <code>afterany</code> triggers the next job whether the previous one succeeded or failed; <code>afterok</code> only triggers on success. For array job dependencies, <code>aftercorr</code> matches array elements one-to-one.

See [https://slurm.schedmd.com/sbatch.html#OPT_dependency the sbatch documentation] for the full list of dependency types.

== Array jobs ==

If you need to run the same script many times with a varying parameter, an array job is far more efficient than a submission loop. Add:

<syntaxhighlight lang="bash">
#SBATCH --array=0-10%4
</syntaxhighlight>

This submits 11 jobs (indices 0–10) with at most 4 running at once. See [[Array jobs]] for details.

== See also ==

* [[Partitions / Queues]]
* [[Choosing a node (constraints)]]
* [[Interactive Jobs]]
* [[Array jobs]]
* [[Cancelling Jobs]]
* [[Monitoring job execution | Monitoring jobs]]
* [[Using Slurm | Scheduler overview]]
* [https://slurm.schedmd.com/sbatch.html sbatch documentation]

Interactive Jobs

Haars0011 — Tue, 16 Jun 2026 09:19:32 GMT

Phase 1 § 4 P1.4.5: split Interactive Jobs out of Using Slurm § sinteractive + § salloc (via create-page on MediaWiki MCP Server)

New page

For quick exploration on a compute node — testing a snippet, profiling memory usage, debugging an environment — request an interactive shell instead of submitting a batch job. SLURM offers two commands for this: <code>sinteractive</code>, which drops you straight into a shell on a compute node, and <code>salloc</code>, which reserves resources you can use from the login node.

== sinteractive ==

<code>sinteractive</code> is a thin wrapper on <code>srun</code> that requests an allocation and gives you a shell on the allocated node:

<syntaxhighlight lang="bash">
sinteractive -c <num_cpus> --mem <amount_mem> --time <minutes> -p <partition>
</syntaxhighlight>

After SLURM allocates resources you land at a new shell prompt on a compute node — run <code>hostname</code> to confirm which one. From there, run commands as you would in any shell; the allocation ends when you exit.

If you run <code>sinteractive</code> with no flags, you get a default allocation of 1 CPU, 100 MB of memory, and 1 hour of wall time. That is fine for a quick test but too small for real work.

=== Wrapper source ===

The wrapper itself is a four-line shell script:

<syntaxhighlight lang="bash">
#!/bin/bash
srun "$@" -I60 -N 1 -n 1 --pty bash -i
</syntaxhighlight>

The flags translate to: time out the allocation request after 60 seconds (<code>-I60</code>), one node (<code>-N 1</code>), one task (<code>-n 1</code>), and a pseudo-terminal running an interactive bash (<code>--pty bash -i</code>).

== salloc ==

<code>salloc</code> requests resources without immediately running anything. Use it when you want to keep your shell on the login node and dispatch tasks into the allocation as you go:

<syntaxhighlight lang="bash">
salloc -p main --time=2:00:00
</syntaxhighlight>

Once the allocation is granted, launch tasks with <code>srun</code>:

<syntaxhighlight lang="bash">
srun <command>
</syntaxhighlight>

The default <code>salloc</code> wall time is 1 hour. For longer sessions add <code>--time</code> as in the example above.

== See also ==

* [[Partitions / Queues]]
* [[Choosing a node (constraints)]]
* [[Cancelling Jobs]]
* [[Using Slurm | Scheduler overview]]
* [https://slurm.schedmd.com/salloc.html salloc documentation]

Cancelling Jobs

Haars0011 — Tue, 16 Jun 2026 09:06:57 GMT

Phase 1 § 4 P1.4.8: split Cancelling Jobs out of Using Slurm § scancel (via create-page on MediaWiki MCP Server)

New page

To stop a job before it finishes — whether it is still waiting in the queue or already running — use <code>scancel</code>. Pass the job ID as the argument:

<syntaxhighlight lang="bash">
scancel 3401
</syntaxhighlight>

Replace <code>3401</code> with the job ID returned by <code>sbatch</code> when you submitted, or the ID shown by <code>squeue</code>. SLURM signals the job to stop; you don't need to confirm it ran.

== See also ==

* [[Monitoring job execution | Monitoring jobs]]
* [[Using Slurm | Scheduler overview]]

Choosing a node (constraints)

Haars0011 — Tue, 16 Jun 2026 09:06:56 GMT

Phase 1 § 4 P1.4.3: split Choosing a node (constraints) out of Using Slurm § Defaults + § Using GPU (via create-page on MediaWiki MCP Server)

New page

SLURM picks a node for your job based on the partition you choose and the constraints you set. If you don't tell SLURM what you need, it uses defaults; for anything that exceeds a default, you have to be explicit.

== Defaults ==

If you submit a job without any directives, SLURM assumes:

* '''Partition:''' main
* '''Quality of Service:''' std
* '''CPUs:''' 1
* '''Wall time:''' 1 hour
* '''Maximum wall time:''' 3 weeks
* '''Memory:''' 100 MB per node

For anything beyond these limits, set the relevant <code>#SBATCH</code> directive in your sbatch script.

== Selecting GPU hardware ==

The cluster has nodes with NVIDIA GPUs (partition <code>gpu</code>) and nodes with AMD GPUs (partition <code>gpu_amd</code>). To run on a GPU node you need to do two things in your sbatch script: select the right partition, and request the GPU as a generic resource.

=== NVIDIA GPUs ===

Six nodes with NVIDIA GPUs are available in the <code>gpu</code> partition. Request one with:

<syntaxhighlight lang="bash">
#SBATCH --partition=gpu
#SBATCH --gres=gpu:1
</syntaxhighlight>

Replace <code>1</code> with the number of GPUs you need. The <code>--gres</code> line is mandatory — without it, your job will either fail or run on the CPU instead of the GPU.

If you don't ask for a particular GPU model, SLURM picks whatever is free. The scheduler is configured to prefer A100s first, then A6000s, then V100s. The price per GPU-hour is the same regardless of model.

To restrict the job to a specific model, add a <code>--constraint</code> directive. To see the constraint names available for GPU nodes, run:

<syntaxhighlight lang="bash">
scontrol show -o node | grep -o -e "NodeName=\w*" -e "ActiveFeatures=[[:alnum:][:punct:]]*" | paste - - | column -t | grep gpu
</syntaxhighlight>

Then constrain the job to one of the listed models:

<syntaxhighlight lang="bash">
# Restrict to A100 GPUs
#SBATCH --constraint='nvidia&A100'
</syntaxhighlight>

A rough rule of thumb: the A100/80 GB cards are about twice as fast as the A6000/48 GB or V100/16 GB. Whether you can take advantage of that depends on whether your workload can actually use the extra memory and saturate the GPU.

=== AMD GPUs ===

Two nodes with AMD GPUs are available in the <code>gpu_amd</code> partition. The mechanics are identical to NVIDIA — request the partition and a GPU as a generic resource:

<syntaxhighlight lang="bash">
#SBATCH --partition=gpu_amd
#SBATCH --gres=gpu:1
</syntaxhighlight>

== See also ==

* [[Partitions / Queues]]
* [[Using Slurm | Scheduler overview]]
* [[Tariffs | Costs associated with resource usage]]

Partitions / Queues

Haars0011 — Tue, 16 Jun 2026 09:06:55 GMT

Phase 1 § 4 P1.4.2: split Partitions / Queues out of Using Slurm § Queues (via create-page on MediaWiki MCP Server)

New page

The SLURM scheduler on Anunna divides compute nodes into separate '''partitions''' (sometimes called queues). When you submit a job, you choose which partition it runs in by setting <code>--partition</code> on your sbatch script.

== Available partitions ==

* '''main''' — the default partition for CPU jobs. Use this unless you have a specific reason to pick another.
* '''gpu''' — for jobs that need NVIDIA GPUs.
* '''gpu_amd''' — for jobs that need AMD GPUs.

To see the partitions currently available on the cluster, run:

<syntaxhighlight lang="bash">
sinfo
</syntaxhighlight>

This lists every partition together with its state and the nodes that belong to it.

== Selecting a partition ==

The default partition is '''main'''. If you don't specify <code>--partition</code>, your job runs there. To select a different one, add a directive to your sbatch script:

<syntaxhighlight lang="bash">
#SBATCH --partition=gpu
</syntaxhighlight>

For GPU partitions you also need to request the GPU itself as a generic resource — see [[Choosing a node (constraints)]] for the details.

== See also ==

* [[Choosing a node (constraints)]]
* [[Using Slurm | Scheduler overview]]

Main Page

Haars0011 — Tue, 16 Jun 2026 08:37:13 GMT

Phase 0 cleanup: remove dead links (P0.1) — drop Services, Downtime, Globally installed software heading, Domain specific software on B4Fcluster, Lustre PFS layout, Bioinformatics tips tricks workflows, Manual GitLab; redirect old log_in_to_B4F_cluster ref to Log in to Anunna (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 08:37, 16 June 2026
Line 27:		Line 27:
	== Gaining access to Anunna==		== Gaining access to Anunna==
	Access to the cluster and file transfer are traditionally done via [http://en.wikipedia.org/wiki/Secure_Shell SSH and SFTP].		Access to the cluster and file transfer are traditionally done via [http://en.wikipedia.org/wiki/Secure_Shell SSH and SFTP].
	* [[~~log_in_to_B4F_cluster~~ \| Logging into cluster using ssh]]		* [[Log_in_to_Anunna \| Logging into cluster using ssh]]
	* [[file_transfer \| File transfer options]]		* [[file_transfer \| File transfer options]]
	* [[Services \| Alternative access methods, and extra features and services on Anunna]]
	* [[Filesystems \| Data storage methods on Anunna]]		* [[Filesystems \| Data storage methods on Anunna]]

Line 38:		Line 37:

	* [[Courses]] that have happened and are happening		* [[Courses]] that have happened and are happening
	* [[Downtime]] that will affect all users
	* [[Meetings]] that may affect the policies of Anunna		* [[Meetings]] that may affect the policies of Anunna

Line 65:		Line 63:
	* [[Using_Slurm \| Submit jobs with Slurm]]		* [[Using_Slurm \| Submit jobs with Slurm]]
	* [[node_usage_graph \| Be aware of how much work the cluster is under right now with 'node_usage_graph']]		* [[node_usage_graph \| Be aware of how much work the cluster is under right now with 'node_usage_graph']]

	~~==== [[Globally installed software]] ====~~

	==== [[ABGC_modules \|ABGC specific modules]] ====		==== [[ABGC_modules \|ABGC specific modules]] ====

	==== Installation of software by users ====		==== Installation of software by users ====
	* [[Domain_specific_software_on_B4Fcluster_installation_by_users \| Installing domain specific software: installation by users]]
	* [[Setting local variables]]		* [[Setting local variables]]
	* [[Installing_R_packages_locally \| Installing R packages locally]]		* [[Installing_R_packages_locally \| Installing R packages locally]]
Line 101:		Line 96:

	= Miscellaneous =		= Miscellaneous =
	* [[Bioinformatics_tips_tricks_workflows \|Bioinformatics tips, tricks, and workflows]]
	* [[Parallel_R_code_on_SLURM \| Running parallel R code on SLURM]]		* [[Parallel_R_code_on_SLURM \| Running parallel R code on SLURM]]
	* [[Manual GitLab \| GitLab: Create projects and add scripts]]
	* [[Monitoring_executions \| Monitoring job execution]]		* [[Monitoring_executions \| Monitoring job execution]]
	* [[Shared_folders \| Working with shared folders in the Lustre file system]]		* [[Shared_folders \| Working with shared folders in the Lustre file system]]
Line 111:		Line 104:
	= See also =		= See also =
	* [[Maintenance_and_Management \| Maintenance and Management]]		* [[Maintenance_and_Management \| Maintenance and Management]]
	* [[Lustre_PFS_layout \| Lustre Parallel File System layout]]

	= External links =		= External links =

Submit job with qsub

Haars0011 — Mon, 15 Jun 2026 14:21:32 GMT

Haars0011 deleted page Submit job with qsub content was: "a protocol for submitting using 'qsub'", and the only contributor was "Hjmegens" (talk)

Obfuscating runs

Haars0011 — Mon, 15 Jun 2026 14:20:51 GMT

Haars0011 deleted page Obfuscating runs content was: "<source lang='bash'> #!/bin/bash #SBATCH --exclusive #SBATCH --nodes=1 #SBATCH --mem=10000 #SBATCH --comment="cv testjob" #SBATCH -p student RND=`< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c${1:-32};echo;` ln -s `which sleep` $RND echo "Using $RND as binary name" ./$RND 10 </source>", and the only contributor was "Megen002" (talk)

Events

Haars0011 — Mon, 15 Jun 2026 14:20:29 GMT

Haars0011 deleted page Events content was: "This page contains a list of events of potential interest to the ABGC community. {| class="wikitable" |- ! What? ! When? ! Where? ! Description ! remarks |- | Illumina Sequencing Seminar | Wednesday, December 7, 2011 | Radix Building (Wageningen Campus), room W0.1 | | |- | etc | etc | etc | etc | |- | etc | etc | etc | etc | |}", and the only contributor was "Hjmegens" (talk)

List of users

Haars0011 — Mon, 15 Jun 2026 14:20:14 GMT

Haars0011 deleted page List of users content was: " == Active users == List of users. Alphabetical order (last/family name). Provide some background information by adding information to the 'User:username' page. * Wes Barris (Cobb) * John Bastiaansen (WUR/ABGC) * Rianne van Binsbergen (WUR/ABGC) * Mirte Bosse (WUR/ABGC) * Aniek Bouwman (WUR/ABGC) * Pim Brascamp (WUR/ABGC) * User:Calus001 | Mario Calus (WUR..."

Cuda

Haars0011 — Mon, 15 Jun 2026 14:19:47 GMT

Haars0011 deleted page Cuda content was: "CUDA® is a parallel computing platform and programming model invented by NVIDIA. It is a module designed to allow you to write code for NVIDIA graphics processing units (GPUs).", and the only contributor was "Dawes001" (talk)

Anunna

Haars0011 — Mon, 15 Jun 2026 14:19:31 GMT

Haars0011 deleted page Anunna content was: "Anunna is a new cluster derived from parts of the HPC AgroGenomics cluster as of January 2019, combined with new infrastructure.", and the only contributor was "Hjmegens" (talk)

Manual GitLab

Haars0011 — Mon, 15 Jun 2026 14:18:37 GMT

Haars0011 deleted page Manual GitLab content was: "Manual GitLab@WUR: Create projects and add files == Signing up == If you haven't done so already, install git in your local machine and sign up at GitLab@WUR: https://git.wageningenur.nl == Example of local commands to execute == <source lang='bash'> ## This shows an example, step by step, to create a project and add files into that project. ## Configuration: # 1. Create a folder in your machine, e.g.: mkdir ~/Git_Stuff # 2. configuration step 1: git config --global us..."