bwHPC Wiki - User contributions [en]

HPC Glossary/Batch system

2026-06-03T14:25:45Z

S Fischer: /* Resource Management Systems on bwHPC Clusters */

← This page is part of the [[HPC Glossary]]
----

When we speak of a '''batch system''' on compute clusters, we mean the system that knows which compute nodes are used by whom and when they will become available. It also knows about all waiting jobs and determines which job are going to start next on which node whenever a node bekomes available.

== Why do we need a Resource Management System? ==

An HPC cluster is a multi-user system. Users have compute jobs with different demands on number of processor cores, memory, disk space and run-time. Some users run a program only occasionally for a big task, other users must run many simulations to finish their projects.

The cluster only provides a limited number of compute resources with certain features. Free access for all users to all compute nodes without time limit will not work. Therefore we need a resource management system (batch system) for the scheduling and the distribution of compute jobs on suitable compute resources.
The use of a resource management system pursues several objectives:

* Fair distribution of resources among users
* Compute jobs should start as soon as possible
* Full load and efficient usage of all resources
[[image:distributing_jobs1.svg]]

== How does a Resource Management System work? ==
A resource management system or batch system manages the compute nodes, jobs and queues and basically consists of two components:

* A resource manager which is responsible for the node status and for the distribution of jobs over the compute nodes.
* workload manager (scheduler) which is in charge of job scheduling, job managing, job monitoring and job reporting.

A resource management system works as follows:

* The user creates a job script containing requests for compute resources and submits the script to the resource management system.
* The scheduler parses the job script for resource requests and determines where to run the job and how to schedule it.
* The scheduler delegates the job to the resource manager.
* The resource manager executes the job and communicates the status information to the scheduler.

== How does a Job Scheduler work?==

The job scheduling process is influenced by many and sometimes contrasting parameters which are used as metrics for the scheduling algorithm. The objectives of a resource management system are approached in the following way:

* Fair distribution of resources among users: Ensure that all users get a fair share of processing time for their jobs.
* Compute jobs should start as soon as possible: Minimize the time jobs have to wait until they start.
* Full load and efficient usage of all resources: Aim for the highest possible utilization with the available jobs, because cluster resources are very expensive

The following simple example illustrates how a scheduler works.
Let us consider a system with 4 nodes. Each node has 4 processor cores.

Here the cluster is empty. No jobs are scheduled:

[[image:Scheduling-workload0.svg]]

Now jobs with different resource requests are scheduled:

* one job which needs two nodes (blue)
* one job which needs one node (red)
* multiple jobs, which need only one core (yellow, orange)
* some jobs are short running, others are long running (see time axis)

[[image:Scheduling-workload1.svg]]

Up to now enough resources are available so that all jobs can start instantly.

More jobs are submitted. Now not all job can start immediately on the available hardware resources. Some jobs are scheduled to run at a later time.

* Big jobs (in terms of hardware resources) often have to wait longer, because they cannot be scheduled flexibly.
* Long running jobs can delay the scheduling of big jobs, because they block needed hardware resources.
* Small and short jobs can be scheduled to fill gaps.
* If a job stops prematurely, short jobs can be rescheduled to start earlier (back filling).

[[image:Scheduling-workload2.svg]]

In addition to cores and time a scheduler has to consider many more metrics like memory, co-processors, fair share, and priority. Scheduling is a multi-dimensional optimization problem.

== Resource Management Systems on bwHPC Clusters ==

Slurm: complete resource management system with integrated resource manager and scheduler

All bwHPC cluster follow a fairshare policy. The waiting time of jobs depends on:

* your job's resource requests: Jobs with large resource requests wait longer for free resources.
* your usage history: High resource usage in a short time leads to a lower job priority.
* your university's share (bwUniCluster only): If the usage exceeds the university's share, the job priority decreases.

bwHPC clusters have specific configurations for the resource management system concerning:

* Job submission and monitoring commands (via Slurm)
* Queues and limits for the available hardware
* Node access policy:
** shared: compute nodes can be shared by jobs of different users
** single user: compute nodes can be shared by jobs of a single user
** single job: compute nodes are allocated exclusively for a single job

FAQ: How many jobs can run on a single node at the same time?

This depends on the node access policy:

* On "shared nodes", more than one job can run simultaneously if the requested resources are available, and these jobs may have been submitted by different users.
* On "single user nodes", more than one job can run simultaneously, but the jobs have to be submitted by one and the same user
* On "single job nodes", the access is exclusive for one job, irrespective of the number of requested cores.

Energy Efficient Cluster Usage

2026-05-29T09:10:12Z

S Fischer: /* Summary: General Recommendations */

= Introduction =

Energy consumption of data centers has been increasing continuously throughout the last decade. In 2020, the energy consumption of all data centers in Germany amounted to around [https://www.bundestag.de/resource/blob/863850/423c11968fcb5c9995e9ef9090edf9e6/WD-8-070-21-pdf-data.pdf 3 percent] of the total electricity produced. Accompanying this large energy consumption are large-scale emissions of CO2 to the atmosphere and thus significant contributions to climate change.
To illustrate this, an average compute job running on a single node for one day may easily consume 10 kWh or even more. That translates roughly to brewing 700 cups of coffee.
Assuming that a typical bwHPC cluster has a few hundred compute nodes, this amounts to the energy consumption of a village for each cluster.

Although a large amount of this energy consumption is an intrinsic requirement of running large HPC clusters (even when it's processors are idle, a cluster uses a lot of energy), efficient use of the available resources is important. Using as many resources as possible does not make a power user. Using them wisely does.
In the following, a basic introduction to some of the most important aspects of energy-efficient HPC usage from a user perspective is given.

We can generally distinguish three tasks when optimizing for running HPC jobs efficiently.

→ What do I want to do and why do I need an HPC Cluster for it?

→ How many and which kind of hardware resources do I require for it?

→ How do I optimize my code to use these resources most efficiently?

= What do I want to do and why do I need an HPC Cluster for it? =

The bwHPC clusters are used to almost full capacity, and running a job on an HPC node consumes a lot of energy, as shown above.
Therefore, users are requested to run only necessary jobs.

Please consider testing new setups and their output for validity prior to submitting jobs that require lots of resources. This also includes projects where a lot of (smaller) similar jobs are submitted.

Make sure to double-check your jobs prior to the submission, as having to discard the output data of an HPC project due to faulty input files is wasting a lot of computational resources.

Finally, identifying the specific resource requirements for a given job is important to allocate the optimal amount for your compute job, and to decide if an HPC cluster is needed at all.

= How many and which kind of hardware resources do I require for it =

Resource allocation is a crucial part when working on an HPC cluster.
As this is dependent on both the job as well as the specific cluster hardware and architecture available.

'''
A small number of jobs and few resources'''

→ Submit to the scheduler. No extended testing and resource scaling analysis are needed.

'''
Medium-sized projects'''

→ Run only necessary jobs: Please consider testing new setups and their output for validity prior to submitting a huge amount of similar jobs

→ Start small: Run your problem on a small set of resources first.

→ Use the proper tools for development: If you develop your own code, please use the proper tools for debugging and parallel performance analysis. See: [[Development#Documentation_in_the_Wiki|Development]].

→ A look at the job feedback can help you determine if you are using the cluster efficiently

'''Large projects'''

→ Same approach as for medium-sized projects.

→ Run a scaling analysis for your project with regard to how many resources work best. See: [[Scaling]].

'''Many short jobs'''

→ Handling via the scheduler is inefficient.

→ Simple parallelization by hand is advisable. See: A basic introduction to [[Development/Parallel_Programming | Parallel Programming]].

= How do I optimize my code to use these resources most efficiently? =

The above recommendations will help use the cluster resources more efficiently.
Regarding software development, power efficiency correlates obviously heavily with '''computing performance''', but also with memory usage, i.e. the amount of memory used, but also memory efficiency.

Here, we have gathered a few results based on other research:
→ Use an efficient programming language such as Rust, C, and C++ -- well any compiled language. Do not use any interpreted language like Perl or Python. Since Machine Learning is a hot topic, this deserves a few words: Any ML-Python code using Tensorflow or other libraries will make heavy usage of NumPy and other math packages, which will use C-based implementations. Please make sure, you use the provided Python modules, which are optimized to use Intel MKL and other mathematical libraries.

Further reading:
Rui Pereira, et al: "''Energy efficiency across programming languages: how do energy, time, and memory relate?''", SLE 2017: Proc. of the 10th ACM SIGPLAN Int. Conf. on SW Language Eng., Oct. 2017, pp. 256–267, [https://doi.org/10.1145/3136014.3136031 doi:10.1145/3136014.3136031]

→ Analyse memory access patterns

→ For small tight loops checking for locks, use the <code>pause</code> instruction.

= Summary: General Recommendations =

* Choose the most '''efficient algorithms''' for the given problem.
* Run only '''necessary''' jobs: Please consider testing new setups and their output for validity prior to submitting a huge amount of similar jobs.
* Start '''small''': Run your problem on a small number of parallel entities (be it processes or threads) first.
* '''Estimate''' the runtime of the parallel job as '''exactly''' as possible to increase the efficiency of the scheduling of the whole system.
* Use the proper tools for development: If you develop your own code, please use the proper tools for debugging and parallel performance analysis. More information is available on the bwHPC Wiki.
* A look at the '''job feedback''' can help you determine if you are using the cluster efficiently.

BwUniCluster3.0/Jupyter

2026-05-04T12:25:13Z

S Fischer: fixed broken links

Jupyter can be used as an alternative to accessing HPC resources via SSH. For this purpose only a web browser is required. Within the website source code of different programming languages can be edited and executed. Furthermore different user interfaces and terminals are available.

= Short description of Jupyter =

Jupyter is a web application, central component of Jupyter is the '''Jupyter Notebook'''. It is a document, which can contain formatted text, executable code sections and (interactive) visualizations (image, sound, video, 3D views).

The Jupyter notebooks are executed in an interactive session on the compute nodes of the respective cluster. Access is via any modern web browser. Data is prepared and visualized on the server and therefore does not have to be transmitted over the network. Only the resulting text, image, sound and video data is transmitted. Starting point of a Jupyter session is the HOME directory of the user on the respective cluster.

'''JupyterLab''' is a modern user interface, within which one or more Jupyter notebooks can be opened, edited and executed. The individual notebooks can be arranged as tabs or tiled. JupyterLab is the standard user interface. Besides JupyterLab the classic notebook user interface is available, in which only one Jupyter notebook per browser tab can be opened at a time.

A '''Jupyter Kernel''' describes a separate process, in which one Jupyter Notebook is executed at a time. Different kernels are available for different programming languages or language versions.

Before a Jupyter session is started, the access authorization must be checked first. This is done via '''JupyterHub''', where the resources are selected, for example the number of CPU cores, GPUs or the required main memory.

A detailed documentation of the Jupyter project can be found at [https://jupyter.readthedocs.io https://jupyter.readthedocs.io].

= Access requirements =

{|style="background:#deffee; width:100%;"
|style="padding:5px; background:#cef2e0; text-align:left"|
[[Image:Attention.svg|center|25px]]
|style="padding:5px; background:#cef2e0; text-align:left"|
Access to Jupyter is '''limited to IP addresses from the BelWü network'''.
All home institutions of our current users are connected to BelWü, so if you are on your campus network (e.g. in your office or on the Campus WiFi) you should be able to connect to bwUniCluster 3.0 without restrictions.
If you are outside one of the BelWü networks (e.g. at home), a VPN connection to the home institution or a connection to an SSH jump host at the home institution must be established first.
|}

To use Jupyter on the HPC resources of SCC, the access requirements for [https://wiki.bwhpc.de/e/Registration/bwUniCluster bwUniCluster 3.0] apply. A [https://wiki.bwhpc.de/e/Registration/bwUniCluster registration] is required. Please note, You should've completed registration and tested your login once using [https://wiki.bwhpc.de/e/Registration/SSH Secure Shell (ssh)].

= Login process =

Login takes place at
* bwUniCluster 3.0: [https://uc3-jupyter.scc.kit.edu uc3-jupyter.scc.kit.edu]
* SDIL: [https://sdil-jupyter.scc.kit.edu sdil-jupyter.scc.kit.edu]
* HoreKa: [https://hk-jupyter.scc.kit.edu hk-jupyter.scc.kit.edu]
* HAICORE: [https://haicore-jupyter.scc.kit.edu haicore-jupyter.scc.kit.edu]

For login, your username, your password and a 2-factor authentication are required.

You will first find yourself on a landing page that also gives more information about the currently installed software versions.
By pressing the login button you will be redirected to the JupyterHub page. Click on Enter JupyterHub to start the login process. Select the organization (e.g. KIT) that has granted you access to the HPC system and press Continue. In the Login section that appears, enter your username and password (not the service password).
After pressing the Login button you will be redirected to the second factor query page. Enter the one-time password (e.g. from KIT Token or Google Authenticator App) and press Validate. Now you are done with the login process and can start selecting your computing resources.

[[File:Jupyter_Anmeldung.gif|700px]]

= Selection of the compute resources =

The Jupyter notebooks are executed in an interactive session on the compute nodes of the HPC clusters. Just like accessing an interactive session with SSH, resource allocation is done by the Workload Manager Slurm. The selection of resources for Jupyter is realized via drop-down menus. Only jobs with a maximum of one node are possible.

Available resources for selection are

* Number of CPU cores
* Number of GPUs
* Runtime
* Partition/Queue
* Amount of main memory

If Auto-Reservation is selected the automatic Jupyter reservation of the cluster is enabled.

In normal mode, the grayed-out fields contain reasonable presets, depending on the number of required CPU cores or GPUs respectively. The presets can be bypassed in advanced mode, where further options are available.

Advanced Mode can be activated by clicking on the checkbox of the same name. The following additional options then become available:

* Specification of a reservation
* LSDF mount option
* BEEOND mount option

After the selection is made, the interactive job is started with the spawn button. As when requesting interactive compute resources with the `salloc` command, waiting times may occur. These are usually the longer the larger the requested resources are.
Even if the chosen resources are available immediately, the spawning process may take up to one minute.

[[File:Ressources_neu.gif|500px]]

Please note that in advanced mode, resource combinations can be selected that are impossible to be met. In this case, an error message will appear when the job is spawned.

[[File:Jupyter_Falsche_ressourcen.gif|500px]]

The spawning timeout is currently set to 10 minutes. With a normal workload of the HPC facility, this time is usually sufficient to get interactive resources.

== Prioritized access to computing resources on bwUniCluster 3.0 ==
The use of Jupyter requires the immediate availability of computing resources since the JupyterLab server is started within an interactive Slurm session. To improve the availability of CPUs/GPUs for interactive supercomputing with Jupyter, '''automatic reservation''' for CPU (cpu_il) and GPU (gpu_a100_il) resources has been set up on '''bwUniCluster 3.0'''. It is active '''between 8am and 8pm''' every weekday. The reservation is automatically active if

* no other reservation is set manually
* Auto-Reservation is enabled

To give you a better overview of the currently available resources, a status indicator has been implemented. It appears when selecting the number of required CPUs/GPUs and shows whether a Jupyter job of the selected size can currently be started or not. Green means the selected CPU/GPU resources are available instantly. Yellow means only a single additional job of the selected size can be started. Red means there are no GPU resources left that could satisfy the selected amount of resources.

If there are no more resources available within the reservation, you can try selecting a different amount of CPUs/GPUs or activate Advanced Mode and select a different partition. Availability can be estimated using sinfo_t_idle, which is available when logging in via SSH.

= JupyterLab =

JupyterLab is the standard user interface. In the following only its essential functions are briefly introduced. A detailed documentation is available at
[https://jupyterlab.readthedocs.io https://jupyterlab.readthedocs.io].

== Menu bar ==

The menu bar at the upper edge of JupyterLab has higher-level menus that display the actions available in JupyterLab along with their shortcut keys. The default menus are:

* File: Actions related to files and directories
* Edit: Actions related to editing documents and other activities
* View: actions that change the appearance of JupyterLab
* Run: Actions to execute code in various activities like notebooks and code consoles
* Kernel: Actions to manage kernels that are separate processes for executing code
* Tabs: a list of open documents and activities in the Dock Panel
* Settings: general settings and an editor for advanced settings
* Help: a list of help links to JupyterLab and the kernel

== Left sidebar ==

In the left sidebar there are foldable tabs. The most relevant ones are:

* File browser: Switch to directories and open files with left mouse button, context menu with right mouse button
* Running kernels: Overview of running kernels
* Command overview
* Tab Overview
* Lmod software selection: Search and load/unload Lmod software modules

== Main working area ==
The main working area in JupyterLab allows to arrange, resize and divide documents (notebooks, text files, etc.) and other activities (terminals, code consoles, etc.) in tabs. By holding down the left mouse button, the tabs can be grabbed and repositioned.

In a new JupyterLab session the Launcher tab is opened first. It contains buttons for starting new notebooks, code consoles and other functions. When a notebook is open, a new Launcher tab can be started by pressing the plus symbol in the file browser tab of the left sidebar, by calling ''File > New Launcher'' in the upper menu bar or by the key combination ''Ctrl+Shift+L''.

== Classic Notebook ==

The classic Jupyter Notebook user interface offers only one open Jupyter Notebook or terminal per browser tab. From the JupyterLab user interface the classic display can be reached in the menu bar under ''Help > Launch Classic Notebook''. Clicking on the JupyterHub logo in the upper left corner will take you back to the JupyterLab interface.

= Log out =

You can log out from a running Jupyter session by calling ''File > Log Out'' in the upper menu bar.

{| style="width: 100%; margin:4px 0 0 0; background:none; border-spacing: 0px;"
| style="width:100%; border:1px solid #BBBBBB; background:#fff5fa; vertical-align:top; color:#000;" |
{| style="width:100%; vertical-align:top; border:0px solid #BBBBBB; padding:4px;" |
|-
|{{Red}}| Attention
|-
|
Please note that your interactive session will continue in the background!

|}
|}

As long as the interactive session is running, you can re-enter it at any time. Depending on the duration of your absence, it may be necessary to re-enter your one-time password and possibly KIT password.

If you want to end the interactive session before it has reached its runtime, you can do so via the Hub Control Panel. Under ''File > Hub Control Panel'' in the upper menu bar, it is opened in a new browser tab. By pressing the ''Stop My Server'' button the session will be terminated. You can now log out using the ''Logout'' button in the upper right corner or start a new session directly using the ''Start My Server'' button, for example with a changed resource selection.

[[File:logout_small.gif|750px]]

= Selection of software =

For the selection of the required Lmod software modules the corresponding tab ''Softwares'' is available in the left sidebar. The list of available modules can be narrowed down by entering the search field. The desired module is loaded by pressing the ''Load'' button. In the list with the loaded modules you can remove them with the ''Unload'' button.

{| style="width: 100%; margin:4px 0 0 0; background:none; border-spacing: 0px;"
| style="width:100%; border:1px solid #BBBBBB; background:#f5fffa; vertical-align:top; color:#000;" |
{| style="width:100%; vertical-align:top; border:0px solid #BBBBBB; padding:4px;" |
|-
|{{Green}}| Note
|-
|
On already opened Jupyter Notebooks, newly loaded software modules become active only after restarting the kernel (''Kernel > Restart Kernel'' in the upper menu bar). Terminals must be closed and reopened.
|}
|}

[[File:software_small.gif|750px]]

== Software Stacks for Jupyter ==
Currently 3 special Jupyter software stacks are available via Lmod:

* <code>jupyter/minimal</code>
*: Minimal installation of JupyterLab

* <code>jupyter/base</code>
*: Basic installation of JupyterLab.
*: For a complete list of pre-installed packages, please refer to [https://uc3-jupyter.scc.kit.edu/software-modules/#pre-installed-software-packages this site].

* <code>jupyter/tensorflow</code> (default at login, will be deprecated with the advent of bwUniCluster 3.0)
*: Preinstalled software packages for machine learning applications. Includes among others TensorFlow, Keras, Torch, Pandas, Matplotlib, SKLearn.
*: For a complete list of pre-installed packages and their respective version, please refer to [https://uc3-jupyter.scc.kit.edu/software-modules/#pre-installed-software-packages this site].

* <code>jupyter/ai</code> (will be the new default at login für bwUniCluster 3.0, contains all latest and greatest software for AI workflows)
*: Preinstalled software packages for machine learning applications. Includes among others TensorFlow, Keras, Torch, Torchvision, Lighning, Pandas, Matplotlib, SKLearn.
*: For a complete list of pre-installed packages and their respective version, please refer to [https://uc3-jupyter.scc.kit.edu/software-modules/#pre-installed-software-packages this site].

* <code>jupyter/extensions</code>
*: Same packages as tensorflow + extensions

These software stacks can be used both when accessing the cluster via JupyterHub, as well as for conventional access via SSH via module load.

A continuously updated list with the installed packages can be found on the corresponding subpage of the respective cluster:

* bwUniCluster 3.0: [https://uc3-jupyter.scc.kit.edu/software-modules uc3-jupyter.scc.kit.edu/software-modules]
* HoreKa: [https://hk-jupyter.scc.kit.edu/software-modules hk-jupyter.scc.kit.edu/software-modules]

= Installation of further software =
The software provided by the Lmod modules jupyter/minimal, jupyter/base and jupyter/tensorflow can be easily supplemented by additional Python packages. There are 2 procedures for this.

<ul>
<li>User-Installation (not recommended)<br>
<code>pip install --user <packageName> </code><br>
The additional packages are installed under $HOME/.local/lib/python3.11/site-packages/ which is part of PYTHONPATH.
</li>
<li>Virtual environments (recommended)<br>
The user can create and use virtual environments (cf. Virtual environments). Packages provided by the jupyter Lmod modules remain visible and usable.
</li>
</ul>

== Virtual environments ==

Python virtual environments allow to use different versions of a package and to keep your local site-packages (accessible under <code>$PYTHONPATH</code>) free from conflicts.

=== Creation of virtual environment ===

<pre>
python -m venv <myEnv>
source <myEnv>/bin/activate
pip install <packageName>
deactivate
</pre>

The additional packages are installed under <code><myEnv>/lib/python3.11/site-packages/</code>.

=== Usage of virtual environment ===

In order to use the virtual environment, it has to be activated via <code>source <myEnv>/bin/activate</code>. <code>PYTHONPATH</code> is set accordingly. Deactivation of the venv is done via <code>deactivate</code>.

=== Usage of virtual environment in JupyterLab ===

To be able to use the virtual environments within JupyterLab, a corresponding kernel has to be installed:

<pre>
source <myEnv>/bin/activate
python -m ipykernel install \
--user \
--name myEnv \
--display-name "Python (myEnv)"
</pre>

After installing the kernel (and possibly refreshing the browser window), a button named "myEnv" is available in JupyterLab. The kernel can also be selected from the drop-down menu.

'''Attention'''
The (Lmod) base module you used in the Creation of virtual environment step must be loaded to use the venv. However, to be on the safe side, you can also use the system Python (<code>/usr/bin/python3.11</code>) at creation time, which is available even without any <code>jupyter/{base,tensorflow}</code> module loaded.

== Examples on Data processing, Machine Learning & Visualization ==

In the [https://github.com/hpcraink/workshop-parallel-jupyter/ workshop repository] the usage and best practices on Python in general, and the packages NumPy, Pandas, SciKit and Dask are provided, containing running examples based on open data. It also explains, how Jupyter interacts with pre-installed and your own provided environments.

== R language ==

In order to use R language in JupyterLab, the Lmod module <code>math/R</code> has to be loaded (blue button in JupyterLab or <code>module add math/R</code> in terminal) and a corresponding kernel has to be installed.

<pre>
R
install.packages('IRkernel')
IRkernel::installspec()
</pre>

After installing the kernel , a button named "R" is available in JupyterLab. The kernel can also be selected from the drop-down menu.

'''Attention:'''
Don't forget to load the <code>math/R</code> module (blue button) before using the kernel.

== Julia language ==

In order to use Julia language in JupyterLab, the Lmod module <code>math/julia/1.10.8</code> has to be loaded (blue button in JupyterLab or <code>module math/julia/1.10.8</code> in terminal). When the module is loaded from the JupytherLab UI, the corresponding kernel will be installed. If you use the terminal, this has to be done manually

<pre>
julia
]
add IJulia
</pre>

After installing the kernel, a button named "Julia 1.10.8" is available in JupyterLab. The kernel can also be selected from the drop-down menu.

'''Attention:'''
Don't forget to load the <code>math/julia/1.10.8</code> module (blue button) before using the kernel.

= Jupyter Container Mode =

The container integration on the jupyterhub is done via pyxis. In order to use it the checkmark for container mode has to be clicked. Available options are:

* <code> --container-image:</code> The container image to use. Corresponds to the pyxis option --container-image
* <code> --container-name:</code> The name of the image to use. Corresponds to the pyxis option --container-name. Already downloaded containers in ~/.local/share/enroot can be startet by simply specifing their name.
* <code> --container-mount-home:</code> Corresponds to the pyxis option --container-mount-home. Mounts the home-directory

'''Attention:'''
Make sure Python3.11 and pip are installed in the Container or the notebook will not spawn. This can be checked via command python3.11 -m pip list inside your container

It is advised to create the container prior via e.G. enroot and install all necessary software. For more information see [https://wiki.bwhpc.de/e/BwUniCluster2.0/Containers#SLURM_Integration here]

----