NEMO2

2026-07-09T16:26:52Z

M Janczyk:

[[File:Serverraum-2024-09.jpg|center|800px]]

The '''bwForCluster NEMO 2''' is dedicated to research in the bwHPC domains Neuroscience, Elementary Particle Physics, Microsystems Engineering and Material Science (NEMO).




{| style=" background:#ffa833; width:100%;"
| style="padding:8px; background:#f80; font-size:120%; font-weight:bold; text-align:left" | Copying Data from NEMO2 While SSH Login is Disabled
|-
|
[[NEMO2/SSH-Login-Disabled-Data-Transfer|Create command SSH keys for rsync]]
|}


{| style=" background:#FEF4AB; width:100%;"
| style="padding:8px; background:#FFE856; font-size:120%; font-weight:bold; text-align:left" | News and Events
|-
|
* [https://www.nemo.uni-freiburg.de/news/ NEMO News]
* [https://www.nemo.uni-freiburg.de/nemo/stat/ NEMO Status, Usage and (Maintenance) Announcements]
|}

{| style=" background:#eeeefe; width:100%;"
| style="padding:8px; background:#dedefe; font-size:120%; font-weight:bold; text-align:left" | Training & Support
|-
|
* [[NEMO2/Start|Getting Started]]
* [https://training.bwhpc.de E-Learning Courses]
* Contact and [[NEMO2/Support|Support]]
|}

{| style=" background:#deffee; width:100%;"
| style="padding:8px; background:#cef2e0; font-size:120%; font-weight:bold; text-align:left" | User Documentation
|-
|
* [[Registration]] for one of the bwHPC clusters
* [[NEMO2/Login|Login]]
* [[NEMO2/Hardware|Hardware and Architecture]]
* [[NEMO2/Hardware#File_Systems|File Systems]]
** [[NEMO2/Workspaces|Workspaces]]
** [[NEMO2/SDS_hd|Using SDS@hd on NEMO2]]
* Cluster Specific Software:
** [[NEMO2/Modules|Available Modules (Wiki)]] or [https://www.nemo.uni-freiburg.de/easybuild-modules/ Available Modules (HTML, incl. search)] on NEMO2
** [[NEMO2/Easybuild Modules|Easybuild Modules]] (hints for building your own software!)
** [[Conda]]
** [[NEMO2/Containers|Containers]] (Enroot and Apptainer/Singularity)
* [[NEMO2/Slurm|Submitting and managing Jobs with Slurm]] ([[HPC_Glossary#Batch_System|Batch System]])
* [[Development]]
|}

{| style=" background:#e6e9eb; width:100%;"
| style="padding:8px; background:#d1dadf; font-size:120%; font-weight:bold; text-align:left" | Cluster Funding
|-
|
* Please [[NEMO2/Acknowledgement|acknowledge]] the NEMO2 in your publications.
|}

NEMO2/SSH-Login-Disabled-Data-Transfer

2026-07-09T16:19:28Z

M Janczyk: M Janczyk moved page SSH-Login-Disabled-Data-Transfer to NEMO2/SSH-Login-Disabled-Data-Transfer without leaving a redirect

2026-05-20T13:07:44Z

M Janczyk: /* Sharing Workspaces */

NEMO2/Workspaces

2026-05-20T13:01:56Z

M Janczyk: /* Sharing Workspaces */

<div style="border: 3px solid #ffc107; padding: 15px; background-color: #fff3cd; margin: 10px 0;">
'''Note:''' This is the updated Workspaces guide for NEMO2. For other clusters please use: [[Workspace]].
</div>

'''Workspace tools''' provide temporary storage on NEMO's fast parallel filesystem (Weka).
They are meant for data that needs to persist longer than a single job, but not permanently.

For advanced features — user config (<tt>~/.ws_user.conf</tt>), reminders, quotas, workspace handover, and more — see [[NEMO2/Workspaces/Advanced_Features|Advanced Features]].

== What are Workspaces? ==

'''Use workspaces for:'''
* Jobs generating intermediate data
* Data shared between multiple compute nodes
* Multi-step workflows

'''Don't use workspaces for:'''
* Permanent storage (use HOME or project directories)
* Single-node temporary files (use <tt>$TMPDIR</tt> instead)

== Important - Read First ==

* No Backup: Data is '''not backed up''' and will be '''automatically deleted''' after expiration
* Time-limited: Maximum lifetime is 100 days, up to 100 extensions
* Email Reminders: You receive email notifications before expiration
* Backup Important Data: Copy results to permanent storage before expiration

== Command Overview ==

* <tt>ws_allocate</tt> - Create or extend workspace
* <tt>ws_list</tt> - List your workspaces
* <tt>ws_find</tt> - Find workspace path (for scripts)
* <tt>ws_extend</tt> - Extend workspace lifetime
* <tt>ws_release</tt> - Release (delete) workspace
* <tt>ws_restore</tt> - Restore expired/released workspace
* <tt>ws_register</tt> - Create symbolic links

All commands support <tt>-h</tt> for help.

== Quick Start ==

{| class="wikitable"
|-
!style="width:40%" | Task
!style="width:60%" | Command
|-
|Create workspace (100 days)
|<tt>ws_allocate myWs 100</tt>
|-
|Create group workspace
|<tt>ws_allocate -G groupname myWs 100</tt>
|-
|List all workspaces
|<tt>ws_list</tt>
|-
|See what expires soon
|<tt>ws_list -Rr</tt>
|-
|Find path (for scripts)
|<tt>ws_find myWs</tt>
|-
|Extend by 100 days
|<tt>ws_extend myWs 100</tt>
|-
|Delete workspace (permanent, next nightly run)
|<tt>ws_release myWs</tt>
|-
|Restore expired workspace (30d grace)
|<tt>ws_restore -l</tt> then <tt>ws_restore oldname newname</tt>
|}

== Creating Workspaces ==

Create a workspace with a '''name''' and '''lifetime''' in days:

$ ws_allocate myWs 100

Returns:

/work/classic/$USER-myWs

'''Capture path in variable:'''

$ WORKSPACE=$(ws_allocate myWs 100)
$ cd "$WORKSPACE"

'''Important:''' Running the same command again is safe - returns the existing workspace path.

== Listing Workspaces ==

$ ws_list # List all workspaces
$ ws_list -Rr # Sort by remaining time, soonest first
$ ws_list -g # Show group workspaces

== Extending Workspaces ==

$ ws_extend myWs 100 # Extend by 100 days from now

'''Alternative:''' <tt>ws_allocate -x myWs 100</tt>

Each extension consumes one of your available extensions (100 total).

== Releasing Workspaces ==

$ ws_release myWs

The workspace becomes inaccessible immediately and is permanently deleted at the next nightly expirer run. '''Do not rely on recovering a released workspace.'''

== Restoring Workspaces ==

Recover workspaces that '''expired naturally''' (reached end of lifetime) within the 30-day grace period:

$ ws_restore -l # (1) List restorable workspaces
$ ws_allocate restored 100 # (2) Create target workspace
$ ws_restore username-myWs-0 restored # (3) Restore

'''Important:''' Use the '''full name''' from <tt>ws_restore -l</tt> (with username and timestamp), not the short name.
Released workspaces (via <tt>ws_release</tt>) can also be restored, but only until the next nightly expirer run — after that they are permanently deleted.

== Sharing Workspaces ==

=== Group workspace (recommended) ===

<syntaxhighlight lang="bash">
ws_allocate -g myWs 100 # Group-readable (read-only for group)
ws_allocate -G projectgroup myWs 100 # Group-writable (recommended for teams)
ws_allocate -G bw12a001 myWs 100 # Example: project group bw12a001
</syntaxhighlight>

Anyone in the group can use <tt>ws_list -g</tt> to see the workspace and extend it with:

<syntaxhighlight lang="bash">
ws_allocate -x -u owner myWs 100
</syntaxhighlight>

Using <tt>-G</tt> also enables smooth handover when team members leave — see [[NEMO2/Workspaces/Advanced_Features#Workspace_Handover|Workspace Handover]].

'''Set default group in <tt>~/.ws_user.conf</tt>:'''

<pre>
groupname: bw12a001
</pre>

{{Note|Your project group name (e.g. <tt>bw12a001</tt>) is typically assigned by your HPC site. Use <tt>groups</tt> on the command line to list all groups you belong to.}}

=== Share after creation ===

If you didn't use <tt>-g</tt>/<tt>-G</tt> at creation, share read-only with <tt>ws_share</tt>:

<syntaxhighlight lang="bash">
ws_share share myWs alice bob # Grant read access
ws_share list myWs # Show who has access
ws_share unshare myWs alice # Remove access
</syntaxhighlight>

'''Advanced sharing:''' [[NEMO2/Workspaces/Advanced_Features#Sharing|Sharing guide]] for ACL-based per-user permissions.

NEMO2/Workspaces/Advanced Features

2026-05-20T12:59:06Z

M Janczyk: /* ACLs (per-user fine-grained) */

For basic daily usage see the main [[NEMO2/Workspaces|Workspaces]] guide.

__TOC__

== Creating Workspaces ==

$ ws_allocate myWs 100

Returns the workspace path, e.g. <tt>/work/classic/$USER-myWs</tt>.
Running the same command again is safe — it returns the existing workspace path.

'''Capture path in variable:'''

$ WORKSPACE=$(ws_allocate myWs 100)
$ cd "$WORKSPACE"

'''Common options:'''

$ ws_allocate -g myWs 100 # Group-readable workspace
$ ws_allocate -G projectgroup myWs 100 # Group-writable workspace
$ ws_allocate -r 7 myWs 100 # Reminder 7 days before expiry
$ ws_allocate -c "ML training data" myWs 100 # Add comment (shown in ws_list -l)
$ ws_allocate -x myWs 100 # Extend existing workspace
$ ws_allocate -x -u alice myWs 100 # Extend Alice's group workspace
$ ws_allocate -r 7 -x myWs 0 # Update reminder only (no extension)

{| class="wikitable"
|-
!style="width:20%" | Option
!style="width:80%" | Description
|-
|<tt>-g</tt>
|Group-readable workspace
|-
|<tt>-G <groupname></tt>
|Group-writable workspace. Set default in <tt>~/.ws_user.conf</tt>
|-
|<tt>-m <email></tt>
|Custom email for reminders (overrides identity provider email)
|-
|<tt>-r <days></tt>
|Reminder n days before expiration
|-
|<tt>-c <comment></tt>
|Comment shown in <tt>ws_list -l</tt>
|-
|<tt>-x</tt>
|Extend existing workspace
|-
|<tt>-u <username></tt>
|Target another user's workspace (requires <tt>-G</tt>)
|}

'''Using workspaces in batch jobs:'''

Create the workspace once on the login node, then use <tt>ws_find</tt> in the job script:

<pre>
#!/bin/bash
#SBATCH --job-name=my_job

WORKSPACE=$(ws_find myProject)
cd "$WORKSPACE"

./my_program --input input.dat --output results.dat
</pre>

=== User Defaults: ~/.ws_user.conf ===

Set defaults so you never forget important options. The file is in YAML format:

<pre>
duration: 100
reminder: 7
groupname: projectgroup
</pre>

<div style="border: 3px solid #dc3545; padding: 15px; background-color: #f8d7da; margin: 10px 0;">
'''Important:''' The first line must be a setting, not a comment. Some versions interpret a leading <tt>#</tt> as an email address.
</div>

With the config above, <tt>ws_allocate myWs</tt> automatically creates a 100-day workspace with a 7-day reminder for the default group — no extra flags needed.

{| class="wikitable"
|-
!style="width:25%" | Setting
!style="width:75%" | Description
|-
|<tt>duration:</tt>
|Default lifetime in days
|-
|<tt>reminder:</tt>
|Days before expiration for reminder
|-
|<tt>groupname:</tt>
|Default group for <tt>-G</tt> (see [[#Sharing|Sharing]])
|-
|<tt>mail:</tt>
|Override notification email (optional)
|}

== Listing Workspaces ==

$ ws_list # All your workspaces
$ ws_list -Rr # Sort by remaining time (soonest first)
$ ws_list -g # Include group workspaces

Example output:

<pre>
id: myWs
workspace directory : /work/classic/$USER-myWs
remaining time : 6 days 23 hours
creation time : Thu Apr 17 09:23:41 2025
expiration time : Mon May 26 09:23:41 2025
available extensions : 98
</pre>

{| class="wikitable"
|-
!style="width:15%" | Option
!style="width:85%" | Description
|-
|<tt>-l</tt>
|Long listing (shows creation time, comment, extensions remaining)
|-
|<tt>-R</tt>
|Show remaining time as human-readable
|-
|<tt>-r</tt>
|Reverse sort order
|-
|<tt>-s</tt>
|Sort by creation time
|-
|<tt>-g</tt>
|Include group workspaces (not just owned)
|}

== Finding Workspace Paths ==

Returns the full path — primarily useful in scripts:

$ ws_find myWs
/work/classic/$USER-myWs

$ WORKSPACE=$(ws_find myWs)
$ cd "$WORKSPACE"

== Extending Workspaces ==

$ ws_extend myWs 100 # Extend by 100 days (same as ws_allocate -x)

'''Note:''' Expiry is recalculated from ''now''. Extending too early reduces remaining time; extending near expiry gives maximum benefit.

Group members can extend each other's workspaces:

$ ws_allocate -x -u alice myWs 100 # Requires workspace created with -G

Each extension uses one of the 100 available extensions. Check remaining extensions with <tt>ws_list -l</tt>.

== Releasing Workspaces ==

$ ws_release myWs

The workspace directory is immediately moved out of reach. The data is permanently deleted at the next nightly expirer run — <tt>ws_restore</tt> is possible until then.

<div style="border: 3px solid #dc3545; padding: 15px; background-color: #f8d7da; margin: 10px 0;">
Do '''not''' rely on being able to restore a released workspace. If you have important data, archive it before releasing.
</div>

<tt>--delete-data</tt> skips even that window and deletes immediately ('''cannot be restored'''). Only use this if you are certain the data is no longer needed.

== Restoring Workspaces ==

Restore workspaces that '''expired naturally''' (reached end of lifetime) within the 30-day grace period:

$ ws_restore -l # (1) List restorable workspaces
$ ws_allocate restored 100 # (2) Create target workspace
$ ws_restore username-myWs-0 restored # (3) Restore

Use the '''full name''' from <tt>ws_restore -l</tt> (includes username prefix and timestamp), not the short name.

<div style="border: 3px solid #ffc107; padding: 12px; background-color: #fff3cd; margin: 10px 0;">
'''Released workspaces''' (deleted with <tt>ws_release</tt>) can be restored with <tt>ws_restore</tt> until the next nightly expirer run — after that they are permanently deleted.
</div>

If the workspace is not listed, it has been '''permanently deleted''' — not recoverable by anyone.

{| class="wikitable"
|-
!style="width:20%" | Option
!style="width:80%" | Description
|-
|<tt>-l</tt>
|List restorable workspaces
|-
|<tt>-u <username></tt>
|Restore another user's workspace (requires permission)
|}

== Workspace Links ==

Creates a directory of symlinks to all your workspaces for quick navigation:

$ ws_register ~/workspaces
$ ls ~/workspaces/
myWs -> /work/classic/$USER-myWs

Re-run after creating new workspaces to keep the links up to date.

== Sharing ==

<div style="border: 3px solid #dc3545; padding: 15px; background-color: #f8d7da; margin: 10px 0;">
'''NEVER use <tt>chmod 777</tt> / <tt>chmod o+rwx</tt>!'''
Making workspaces world-readable is a security policy violation — use the methods below.
</div>

=== Group workspaces (recommended) ===

$ ws_allocate -g myWs 100 # Group-readable (read-only for group)
$ ws_allocate -G projectgroup myWs 100 # Group-writable (recommended for teams)

Set <tt>groupname</tt> in <tt>~/.ws_user.conf</tt> so you don't have to type it every time.

Benefits: team members can extend the workspace, <tt>ws_list -g</tt> shows it to everyone in the group, and new files automatically inherit group ownership.

=== Read-only sharing after creation ===

Share an existing workspace read-only with specific users outside your group:

$ ws_share share myWs alice bob # Grant read access
$ ws_share unshare myWs alice # Remove access
$ ws_share list myWs # Show who has access

=== ACLs (per-user and per-group fine-grained) ===

Use <tt>setfacl</tt> when <tt>-g</tt>/<tt>-G</tt> and <tt>ws_share</tt> do not cover your needs.

==== User ACLs ====

<syntaxhighlight lang="bash">
DIR=$(ws_find my_workspace)
setfacl -Rm user:alice:rX,default:user:alice:rX "$DIR" # Read-only for alice
setfacl -Rm user:bob:rwX,default:user:bob:rwX "$DIR" # Read-write for bob
</syntaxhighlight>

==== Group ACLs ====

<syntaxhighlight lang="bash">
setfacl -Rm group:readgroup:rX,default:group:readgroup:rX "$DIR" # Read-only for group
setfacl -Rm group:projectgroup:rwX,default:group:projectgroup:rwX "$DIR" # Read-write for group
</syntaxhighlight>

==== Inspect & Remove ====

<syntaxhighlight lang="bash">
getfacl "$DIR" # View current ACLs (users and groups)
setfacl -Rb "$DIR" # Remove all ACLs
</syntaxhighlight>

{| class="wikitable"
! Option !! Description
|-
| <tt>-R</tt> || Apply recursively to all subdirectories and files
|-
| <tt>default:</tt> || New files automatically inherit the ACL entry
|-
| <tt>X</tt> || Execute permission only on directories and executable files
|}

== Workspace Handover ==

When a team member leaves or transfers a project, their workspaces can be handed over without data loss.

=== Preparation (before someone leaves) ===

<tt>-G groupname</tt> can only be set '''at creation time'''. Always create shared research data with it from the start:

$ ws_allocate -G projectgroup -c "ML training data – contact alice" myWs 100

This ensures:
* Group members can see the workspace with <tt>ws_list -g</tt>
* Any group member can extend it: <tt>ws_allocate -x -u alice myWs 100</tt>
* Data remains accessible after the original owner's account is deactivated

To ensure someone else receives expiry reminders, there are two options:

* Add their email to <tt>~/.ws_user.conf</tt> of the owner (or use <tt>-m email</tt> at allocate time):

<pre>
mailaddress: alice@uni-freiburg.de,backup@uni-freiburg.de
</pre>

* Or actively take over the reminders as the new responsible person:

$ ws_allocate -r 7 -u alice -x myWs 0 # Redirect reminders to yourself

=== After the owner has left ===

If the workspace was created with <tt>-G groupname</tt>, a group member can keep it alive:

$ ws_list -g # Find group workspaces
$ ws_allocate -x -u formercolleague myWs 100 # Extend (while still restorable)

If the workspace has already expired, an authorized group member or administrator can restore it:

$ ws_restore -u formercolleague -l # List their restorable workspaces
$ ws_allocate newname 100
$ ws_restore -u formercolleague formercolleague-myWs-0 newname

=== Workspaces without group access ===

If the workspace was created without <tt>-g</tt>/<tt>-G</tt>, contact the HPC support team for assistance during the grace period (30 days after expiry).

== Reminders ==

Reminders are automatic. The notification goes to your identity provider email address.

Customize reminder timing at workspace creation:

$ ws_allocate -r 7 myWs 100 # Reminder 7 days before expiry

Custom email address:

$ ws_allocate -m custom@example.com myWs 100

Update reminder timing (or take over reminders) without extending:

$ ws_allocate -r 7 -x myWs 0 # Change timing only
$ ws_allocate -r 7 -u alice -x myWs 0 # Take over reminders for Alice's workspace

The last command is useful when taking responsibility for a colleague's workspace.

== Quotas & Limits ==

{| class="wikitable"
|-
!style="width:35%" | Parameter
!style="width:65%" | Value
|-
|Default lifetime
|30 days
|-
|Maximum lifetime
|100 days
|-
|Maximum extensions
|100 times
|-
|Storage quota
|5 TiB per workspace
|-
|Grace period (expired workspaces)
|30 days (recoverable with <tt>ws_restore</tt>)
|-
|Grace period (released workspaces)
|next nightly expirer run ('''not reliably recoverable''')
|}

Check quota:

$ nemoquota # HOME + workspace quotas
$ df --si $(ws_find myWs) # Size of a specific workspace

Released workspaces count toward quota until the nightly cleanup runs. Use <tt>ws_release --delete-data</tt> for immediate relief ('''irreversible''').

== Best Practices ==

# Set up <tt>~/.ws_user.conf</tt> — defaults save time and prevent mistakes
# Use <tt>-G groupname</tt> for research data — essential for handover and collaboration
# Create workspaces on the login node — use <tt>ws_find</tt> in job scripts, don't create inside jobs
# Monitor with <tt>ws_list -Rr</tt> — sort by remaining time to catch workspaces about to expire
# Archive before expiry — workspaces are not backed up
# Clean up finished workspaces — <tt>ws_release</tt> frees quota and reduces clutter

Single-node temporary files belong in <tt>$TMPDIR</tt>, not workspaces.

NEMO2/Containers

2026-05-19T08:42:54Z

M Janczyk:

NEMO supports two container runtimes for different use cases.
Neither requires root privileges and both integrate with the cluster's shared filesystems (<tt>/home</tt>, <tt>/work</tt>).

== Overview ==

{| class="wikitable"
|-
!
! [[NEMO2/Containers/Enroot|Enroot + Pyxis]] (recommended)
! [[NEMO2/Containers/Apptainer|Apptainer / Singularity]]
|-
| '''Image source'''
| Docker Hub, NGC, any OCI registry
| Docker Hub, NGC, any OCI registry; SIF files
|-
| '''Image format'''
| SquashFS (<tt>.sqsh</tt>)
| SIF (<tt>.sif</tt>)
|-
| '''Slurm integration'''
| Native via Pyxis plugin (<tt>--container-name</tt> etc.)
| Manual — wrap in batch script
|-
| '''GPU support'''
| Automatic, no extra flags needed
| Via <tt>--nv</tt> flag
|-
| '''Installation'''
| System-wide, always available
| System-wide, always available
|-
| '''Best for'''
| Docker-based workflows, GPU workloads, Slurm batch jobs
| Existing SIF images, reproducible science, portability
|}

== When to use what ==

; Enroot + Pyxis
: Use this if you want to run Docker images directly from a registry, submit containerised jobs via <tt>srun</tt>/<tt>sbatch</tt>, or need tight GPU integration.
: [[NEMO2/Containers/Enroot|→ Enroot & Pyxis details]]

; Apptainer / Singularity
: Use this if you have an existing <tt>.sif</tt> image, need a self-contained portable image you can copy between systems, or are working with workflows that already use Apptainer/Singularity.
: [[NEMO2/Containers/Apptainer|→ Apptainer details]]

== Note on Docker ==

Plain Docker is '''not available''' on NEMO. Both Enroot and Apptainer can pull Docker/OCI images directly from registries without a local Docker installation.

NEMO2

2026-05-12T16:02:22Z

M Janczyk:

[[File:Serverraum-2024-09.jpg|center|800px]]

The '''bwForCluster NEMO 2''' is dedicated to research in the bwHPC domains Neuroscience, Elementary Particle Physics, Microsystems Engineering and Material Science (NEMO).



{| style=" background:#FEF4AB; width:100%;"
| style="padding:8px; background:#FFE856; font-size:120%; font-weight:bold; text-align:left" | News and Events
|-
|
* [https://www.nemo.uni-freiburg.de/news/ NEMO News]
* [https://www.nemo.uni-freiburg.de/nemo/stat/ NEMO Status, Usage and (Maintenance) Announcements]
|}

{| style=" background:#eeeefe; width:100%;"
| style="padding:8px; background:#dedefe; font-size:120%; font-weight:bold; text-align:left" | Training & Support
|-
|
* [[NEMO2/Start|Getting Started]]
* [https://training.bwhpc.de E-Learning Courses]
* Contact and [[NEMO2/Support|Support]]
|}

{| style=" background:#deffee; width:100%;"
| style="padding:8px; background:#cef2e0; font-size:120%; font-weight:bold; text-align:left" | User Documentation
|-
|
* [[Registration]] for one of the bwHPC clusters
* [[NEMO2/Login|Login]]
* [[NEMO2/Hardware|Hardware and Architecture]]
* [[NEMO2/Hardware#File_Systems|File Systems]]
** [[NEMO2/Workspaces|Workspaces]]
** [[NEMO2/SDS_hd|Using SDS@hd on NEMO2]]
* Cluster Specific Software:
** [[NEMO2/Modules|Available Modules (Wiki)]] or [https://www.nemo.uni-freiburg.de/easybuild-modules/ Available Modules (HTML, incl. search)] on NEMO2
** [[NEMO2/Easybuild Modules|Easybuild Modules]] (hints for building your own software!)
** [[Conda]]
** [[NEMO2/Containers|Containers]] (Enroot and Apptainer/Singularity)
* [[NEMO2/Slurm|Submitting and managing Jobs with Slurm]] ([[HPC_Glossary#Batch_System|Batch System]])
* [[Development]]
|}

{| style=" background:#e6e9eb; width:100%;"
| style="padding:8px; background:#d1dadf; font-size:120%; font-weight:bold; text-align:left" | Cluster Funding
|-
|
* Please [[NEMO2/Acknowledgement|acknowledge]] the NEMO2 in your publications.
|}