HPC@HU - Benutzerbeiträge [de-formal]

Hauptseite

2025-05-15T07:54:07Z

Mielczad: /* Slurm Cluster */ - make the internal Wiki more visible

Der Service '''"HPC@HU'''" stellt folgende Dienste zur Verfügung:

# Zentraler Slurm-Cluster
# Azimuth-Service

Beide Services bieten die Möglichkeit, die HPC-Infrastruktur der HU zu nutzen. Dabei bietet der Slurm-Cluster eine Vielzahl an Softwarepaketen und ist direkt mit dem HU-Account nutzbar, wohingegen der Azimuth-Service größere Flexibilität ermöglicht und u.a. auch andere Platformen wie JupyterHub zur Verfügung stellt.

== Slurm Cluster ==
Der zentrale Slurm-Cluster ist nach Anmeldung per Mail direkt mit dem HU-Account nutzbar. Der Zugang erfolgt über ein Login-Knoten,

Ein detailliertes WIki inklusive einer detaillierte Auflistung steht innerhalb der HU unter folgendem Link zu Verfügung:

<big>'''https://wiki.hpc-service.hu-berlin.de'''</big>

Außerhalb der HU bieten die folgenden Links grundlegenden Informationen:

* [[Erste Verbindung/Einloggen]]





* [[Mailingliste und Support]]
* [[FAQ]]
== Azimuth ==
Azimuth bietet die Möglichkeit, verschiedene Plattformen, die man auch dem HPC-Bereich kennt, zu erstellen und zu verwalten. Dazu gehört u.a.:

# Slurm-Cluster
# JupyterHub
# HPC-Workstation

Die NutzerInnen können nach der Erstellung, die gewählte Plattform selbständig verwalten und erweitern. Dazu bekommen sie einen Administratorenzugang. Zur Zeit ist die Lebensdauer der Plattform nicht begrenzt.

Der Zugang zum Azimuth-Service erfolgt über den DV-Beauftragten der Einrichtung.

Hauptseite

2025-02-14T14:44:32Z

Mielczad: /* Slurm Cluster */

Der Service '''"HPC@HU'''" stellt folgende Dienste zur Verfügung:

# Zentraler Slurm-Cluster
# Azimuth-Service

Beide Services bieten die Möglichkeit, die HPC-Infrastruktur der HU zu nutzen. Dabei bietet der Slurm-Cluster eine Vielzahl an Softwarepaketen und ist direkt mit dem HU-Account nutzbar, wohingegen der Azimuth-Service größere Flexibilität ermöglicht und u.a. auch andere Platformen wie JupyterHub zur Verfügung stellt.

== Slurm Cluster ==
Der zentrale Slurm-Cluster ist nach Anmeldung per Mail direkt mit dem HU-Account nutzbar. Der Zugang erfolgt über ein Login-Knoten,

Weitere Informationen:

* [[Erste Verbindung/Einloggen]]





* [[Mailingliste und Support]]
* [[FAQ]]
Eine detaillierte Auflistung der verfügbaren Software sowie Hardware findet sich für Nutzer im HU-Netz unter https://wiki.hpc-service.hu-berlin.de

== Azimuth ==
Azimuth bietet die Möglichkeit, verschiedene Plattformen, die man auch dem HPC-Bereich kennt, zu erstellen und zu verwalten. Dazu gehört u.a.:

# Slurm-Cluster
# JupyterHub
# HPC-Workstation

Die NutzerInnen können nach der Erstellung, die gewählte Plattform selbständig verwalten und erweitern. Dazu bekommen sie einen Administratorenzugang. Zur Zeit ist die Lebensdauer der Plattform nicht begrenzt.

Der Zugang zum Azimuth-Service erfolgt über den DV-Beauftragten der Einrichtung.

Hauptseite

2025-02-14T14:44:19Z

Mielczad: /* Slurm Cluster */

Der Service '''"HPC@HU'''" stellt folgende Dienste zur Verfügung:

# Zentraler Slurm-Cluster
# Azimuth-Service

Beide Services bieten die Möglichkeit, die HPC-Infrastruktur der HU zu nutzen. Dabei bietet der Slurm-Cluster eine Vielzahl an Softwarepaketen und ist direkt mit dem HU-Account nutzbar, wohingegen der Azimuth-Service größere Flexibilität ermöglicht und u.a. auch andere Platformen wie JupyterHub zur Verfügung stellt.

== Slurm Cluster ==
Der zentrale Slurm-Cluster ist nach Anmeldung per Mail direkt mit dem HU-Account nutzbar. Der Zugang erfolgt über ein Login-Knoten,

Weitere Informationen:

* [[Erste Verbindung/Einloggen]]





* [[Mailingliste und Support]]
* [[FAQ]]
Eine detaillierte Auflistung der verfügbaren Software sowie Hardware findet sich für Nutzer im HU-Netz unter https://wiki.hpc-service.hu-berlin.de

Eine detaillierte Auflistung der verfügbaren Software sowie Hardware findet sich für Nutzer im HU-Netz unter https://wiki.hpc-service.hu-berlin.de

== Azimuth ==
Azimuth bietet die Möglichkeit, verschiedene Plattformen, die man auch dem HPC-Bereich kennt, zu erstellen und zu verwalten. Dazu gehört u.a.:

# Slurm-Cluster
# JupyterHub
# HPC-Workstation

Die NutzerInnen können nach der Erstellung, die gewählte Plattform selbständig verwalten und erweitern. Dazu bekommen sie einen Administratorenzugang. Zur Zeit ist die Lebensdauer der Plattform nicht begrenzt.

Der Zugang zum Azimuth-Service erfolgt über den DV-Beauftragten der Einrichtung.

Hauptseite

2025-02-14T14:43:58Z

Mielczad: /* Slurm Cluster */

Der Service '''"HPC@HU'''" stellt folgende Dienste zur Verfügung:

# Zentraler Slurm-Cluster
# Azimuth-Service

Beide Services bieten die Möglichkeit, die HPC-Infrastruktur der HU zu nutzen. Dabei bietet der Slurm-Cluster eine Vielzahl an Softwarepaketen und ist direkt mit dem HU-Account nutzbar, wohingegen der Azimuth-Service größere Flexibilität ermöglicht und u.a. auch andere Platformen wie JupyterHub zur Verfügung stellt.

== Slurm Cluster ==
Der zentrale Slurm-Cluster ist nach Anmeldung per Mail direkt mit dem HU-Account nutzbar. Der Zugang erfolgt über ein Login-Knoten,

Weitere Informationen:

* [[Erste Verbindung/Einloggen]]





* [[Mailingliste und Support]]
* [[FAQ]]

Eine detaillierte Auflistung der verfügbaren Software sowie Hardware findet sich für Nutzer im HU-Netz unter https://wiki.hpc-service.hu-berlin.de

== Azimuth ==
Azimuth bietet die Möglichkeit, verschiedene Plattformen, die man auch dem HPC-Bereich kennt, zu erstellen und zu verwalten. Dazu gehört u.a.:

# Slurm-Cluster
# JupyterHub
# HPC-Workstation

Die NutzerInnen können nach der Erstellung, die gewählte Plattform selbständig verwalten und erweitern. Dazu bekommen sie einen Administratorenzugang. Zur Zeit ist die Lebensdauer der Plattform nicht begrenzt.

Der Zugang zum Azimuth-Service erfolgt über den DV-Beauftragten der Einrichtung.

Hauptseite

2025-02-14T14:42:26Z

Mielczad: /* Slurm Cluster */ add link to internal website

Der Service '''"HPC@HU'''" stellt folgende Dienste zur Verfügung:

# Zentraler Slurm-Cluster
# Azimuth-Service

Beide Services bieten die Möglichkeit, die HPC-Infrastruktur der HU zu nutzen. Dabei bietet der Slurm-Cluster eine Vielzahl an Softwarepaketen und ist direkt mit dem HU-Account nutzbar, wohingegen der Azimuth-Service größere Flexibilität ermöglicht und u.a. auch andere Platformen wie JupyterHub zur Verfügung stellt.

== Slurm Cluster ==
Der zentrale Slurm-Cluster ist nach Anmeldung per Mail direkt mit dem HU-Account nutzbar. Der Zugang erfolgt über ein Login-Knoten,

Weitere Informationen:

* [[Erste Verbindung/Einloggen]]
* [[Datenspeicher & Dateistruktur]]
* [[Modules & Verfügbare Software]]
* [[Containerisierung]]
* [[Jobs einreichen mit SLURM]]
* [[Lustre Grundlagen]]
* [[Mailingliste und Support]]
* [[FAQ]]

Eine detaillierte Auflistung der verfügbaren Software sowie Hardware findet sich für Nutzer im HU-Netz unter https://wiki.hpc-service.hu-berlin.de

== Azimuth ==
Azimuth bietet die Möglichkeit, verschiedene Plattformen, die man auch dem HPC-Bereich kennt, zu erstellen und zu verwalten. Dazu gehört u.a.:

# Slurm-Cluster
# JupyterHub
# HPC-Workstation

Die NutzerInnen können nach der Erstellung, die gewählte Plattform selbständig verwalten und erweitern. Dazu bekommen sie einen Administratorenzugang. Zur Zeit ist die Lebensdauer der Plattform nicht begrenzt.

Der Zugang zum Azimuth-Service erfolgt über den DV-Beauftragten der Einrichtung.

Modules & Verfügbare Software

2025-01-17T13:58:29Z

Mielczad: /* Anaconda, Conda, Mamba */ enable link

==== Übersicht & Grundlagen zur Nuzung ====
Die bereitgestellten Compute-Knoten nutzen Linux, genaugenommen ein OpenSUSE.

HPC-typisch wird zentral Software bereitgestellt. Verfügbare Software wird über eine Modulumgebung geladen.

Welche Software verfügbar ist, lässt sich über <code>module avail</code> sowie <code>module spider <name></code> in Erfahrung bringen.

(Online Anleitung für lmod https://lmod.readthedocs.io/en/latest/010_user.html )

Wir bieten aktuell drei Gruppe von Software an:

# /hu "Von Uns" kompilierte Software welche zentral bereitgestellt wird.
# /all Über EasyBuild ( siehe http://docs.easybuild.io/what-is-easybuild/ ) bereitgestellte Software
# /intel Software welche mit Installer ausgeliefert wurde (wie zum Beispiel Intel OneAPI)

Bei der Auswahl von Software sollte darauf geachtet werden dass die Groß- und Kleinschreibung von Bedeutung ist, sprich gcc ist nicht gleich GCC.

Die finalen Pfade sind aktuell auch nicht endgültig festgelegt und können sich noch verändern.

Ferner wird empfohlen sich nicht auf die Defaults zu verlassen und die Version einer Software explizit auszuwählen.

Anwendungsbeispiel:

Die verfügbaren openmpi Versionen lassen sich mit dem Befehl
module spider openmpi
erfragen

Ist daraufhin die Version erwünscht, lässt sich diese mit dem Befehl
module load openmpi/5.0.3-gcc14.1.0
laden.

Aktuell geladene Module lassen sich mit
module list
anzeigen, während
module purge
alle geladenen Module "entlädt".

Aktuell wird die verfügbare Software noch ausgebaut, wodurch sich die Liste relativ schnell entwickelt. Für einen Überblick der aktuell verfügbaren Software wird gebeten diese direkt auf dem System abzufragen. Vor allem mit EasyBuild installierte Software bringt standardmäßig sehr viele kleine Abhängigkeiten mit.

Einen ersten Überblick über einige der wichtigeren Pakete (als Eigenkompilation) bietet die folgende Liste:

==== Verfügbare Software ====

===== Programmiersprachen und Compiler =====
- AMD aocc

- 4.2.0

- gcc

- 9.5.0

- 10.5.0

- 11.4.0

- 12.3.0

- 13.2.0

- 14.1.0

- 14.2.0

- Intel OneApi

- 2024.1

- Julia

- 1.10.3

- python

- 3.8.19

- 3.9.19

- 3.10.14

- 3.11.9

- 3.12.3

- QT (opensource)

- 5.15.14

- R

- 4.4.0

- ruby

- 3.3

===== Bibliotheken und Tools =====
- AMD AOCL

- 4.2.0 gcc

- 4.2.0 aocl

- apache-maven

- 3.9.8

- bash

- 5.2.21

- bc

- 1.0.7

- bison

- 3.8.2

- BLIS

- 4.2.0

- block2

- p0.5.3rc13 openmpi/5.0.3 gcc/14.1.0 OpenBLAS/0.3.26

- boost

- 1.85 gcc/13.2.0

- 1.85 gcc/14.1.0

- Catch2

- 3.6.0 cmake/3.29.3

- cmake

- 3.16.9

- 3.20.6

- 3.27.2

- 3.29.2

- 3.29.3

- coreutils

- 9.5

- costa

2.2.2

- cuda

- 10

- 11

- 12.0

- 12

- 12.1

- 12.2

- 12.3

- 12.4

- 12.4.1

- crest

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc13.2.0 openmpi/5.0.3-gcc13.2.0 gcc/13.2.0

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc14.1.0 openmpi/5.0.3-gcc14.1.0 gcc/14.1.0

fftw

- 3.3.0 gcc/14.1.0

- 3.3.0 openmpi/5.0.3 gcc/14.1.0

- flex

- 2.6.4

- fmt

- 10.2.1

- gsl

- 2.8

- hdf5

- 1.14.4.3

- lapack

- 3.12.0 gcc/13.2.0

- 3.12.0 gcc/14.1.0

- libaec

- 1.1.3

- libflame

- 4.2.0

- libunwind

- 1.8.1

- libxc

- 6.6.2

- magma

- 2.8.8

- mpich

- 3.2.0 gcc/12.3.0

- 3.3.0 gcc/12.3.0

- 4.1.3 gcc/12.3.0

- 4.2.1 gcc/14.1.0

- OpenBLAS

- 0.3.26 gcc/13.2.0

- 0.3.26 gcc/14.1.0

- OpenCoarrays

- 2.9.3 mpich/3.3.0 gcc/12.3.0

- 2.10.2 openmpi/5.0.3 gcc/14.1.0

- OpenMPI

- 4.1.6 gcc/13.2.0

- 5.0.3 gcc/13.2.0

- 5.0.3 gcc/14.1.0

- 5.0.5 gcc/14.2.0

- patch

- 2.7.6

- proj

- 9.4.1 gcc/14.1.0

- scalapack

- 2.2.0

- spglib

- 2.4.0 gcc/14.1.0

- sirius

- 7.5.2

- spla

- 1.6.1

- swig

- 4.2.1

- szip

- 2.1.1

- umpire

- 2024.02.01

===== Software =====
- Blender

- 4.3

- Gaussian 16

- A.03

- GaussView

- 6.0.16

- gdal

- 3.9.0 gcc/14.1.0 proj/9.4.1 swig/4.2.1 python/3.12.3

- hadoopp

- 3.4.0

- hpl

- v2.3

- ior

- 4.0.0 openmpi/5.0.3 gcc/14.1.0

- ncdu

- 1.20

- OpenFOAM

- 11

- v2312

- ORCA

- 5.0.4

- quantum-espresso

- 7.3.1 OpenBLAS/0.3.26 fftw/3.3.10 penmpi/5.0.3 gcc/14.1.0

- xtb

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/13.2.0

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/14.1.0

===== Fehlt was? =====
Da es sich beim HPC um ein Linux System handelt, ist es möglich eigene Software zu entwickeln. Die Einbindung von Software findet überwiegend über zwei grundlegende Variablen statt. <code>PATH</code> für ausführbare Binärdateien sowie <code>LD_LIBRARY_PATH</code> für verlinkte Bibliotheken.

Über ein <code>export PATH=/new/path:$PATH</code> sowie <code>export LD_LIBRARY_PATH=/new/path:$LD_LIBRARY_PATH</code> lassen sich beide erweitern. Diese Änderung gilt bis zum verlassen der Shell - oder ist "semi-permanent" wenn der Export in die .profile oder .bashrc Datei eingetragen wird.

Hierbei gilt es ferner zu beachten dass die Reihenfolge der Auflistung der verschiedenen Pfade von Bedeutung ist: die zuerst gefundene Variante wird genommen.

Obschon es möglich ist eine Software zu kompilieren, bitten wir darum bei fehlender freier Software nach Möglichkeit zuerst eine Anfrage an [mailto:hpc-support@hu-berlin.de hpc-support@hu-berlin.de] zu schicken, damit diese zentral für Alle zugänglich ist.

Bei Anfragen zu kommerzieller Software, internen Eigenentwicklungen oder anderweitig speziell lizenzierter Software stehen wir ebenfalls gerne zu Verfügung.

==== Python, Anaconda, Conda, Mamba ====

===== Python =====
Python wird in vielen Projekten eingesetzt. Die Nutzung von Python ist nicht immer problemfrei, darum gibt es folgend einige Empfehlungen für die Nutzung von Python, welche das Risiko von Problemen sowie die Problembeseitigung erleichtern.

Im Allgemeinen sollten Python Anwendungen in einer virtuellen Umgebung entwickelt und ausgeführt werden. Diese wird nativ von Python unterstützt und ermöglicht es Pakete auf einer bestimmten Version zu halten sowie eventuelle Inkompatibilitäten zwischen verschiedenen Projekten zu vermeiden. Ferner ist es möglich bei Problemen eine virtuelle Umgebung zu löschen und dadurch alte Pakete Rückstandslos zu entfernen. Das ist vor allem interessant da pip oder pip3 Abhängigkeiten installieren kann, aber im Gegensatz zu typischen Linux-Paketmanagern Abhängigkeiten nicht automatisch deinstallieren kann.

Eine virtuelle Umgebung kann wie folgt erstellt werden (mit einem relativen oder absoluten Pfad):
<code>python -m venv /Pfad/zur/neuen/virtuellen_Umgebung</code>
Mehr dazu auf in der Dokumentation von Python: <nowiki>https://docs.python.org/3/library/venv.html</nowiki>

Sollte es aus bestimmten Gründen nicht möglich sein eine virtuelle Umgebung zu nutzen, kann man mit pip Pakete in einem bestimmten Ordner installieren.
<code>pip3 install --target /Pfad/zum/ZielOrdner</code>
Danach kann der Ordner zur Variable PYTHONPATH hinzugefügt werden und wird dann von der Python-Umgebung erkannt.

Die virtuellen Umgebungen sind im Allgemeinen jedoch zu präferieren.

===== Anaconda, Conda, Mamba =====
Eine weitere Alternative ist die Nutzung einer Paketverwaltung in Python, so wie diese über Anaconda/conda/mamba angeboten wird, bei dieser ist der Funktionsumfang dann auch größer als be pip.

Hierbei werden Nutzer und Nutzerinnen angehalten die Nutzungsbedingungen von vor allem Anaconda und Miniconda zu beachten. Aktuell (Januar 2025) wird Miniforge unter der BSD Lizenz angeboten und ist auf Github unter [https://github.com/conda-forge/miniforge github.com/conda-forge/miniforge] verfügbar.

Es wurde mit einer zentralen Instanz von miniforge3 experimentiert, allerdings erweist sich die Verwaltung der Umgebung als unpraktisch und schwieriger als nötig, da normale Nutzer keine Schreibrechte in dem zentralen Installationsordner haben. Standardmäßig wird conda/mamba daraufhin versuchen einen Ordner im Home-Verzeichnis anzulegen, wobei jedoch dort der verfügbare Platz beschränkt ist. Alternativ kann ein expliziter Prefix wie folgt angegeben werden, <code>conda create --prefix /Pfad/zur/neuen/conda_Umgebung</code>, der dann jedoch nicht zwingend von conda direkt erkannt wird...

Es wird darum empfohlen eine eigene Installation von miniforge auf dem zentralen Lustre-Dateisystem aufzusetzen und seine eigene Umgebungen zu verwalten. Für die "Grundversorgung" mit reinem Python, stehen zentral Python-Instanzen zu Verfügung.

Bei der Einrichtung muss dann nur darauf geachtet werden dass der Installationspfad korrekt eingegeben wird. Da eine solche Installation mit der Zeit recht groß werden kann, wird empfohlen dass zuvor erwähnte Lustre-Dateisystem zu nutzen. Der Pfad würde dementsprechend <code>/lustre/<Fakultät>/<Benutzername></code> lauten.

Mit <code>conda init</code> oder <code>mamba init</code> wird die Umgebung initialisiert und die .bashrc Datei angepasst. Dabei werden eventuell existierende conda/mamba Konfigurationen überschrieben (!!!). Dies ist beim benutzen von mehreren Versionen potenziell problematisch und erfordert eine manuelle Anpassung der Skripte sowie potenziell deren Auslagerung in individuelle Dateien.

==== Persönliche Module ====
Es ist möglich eigene Module in <code>lmod</code> einzubinden, wie in der Dokumentation beschrieben: <nowiki>https://lmod.readthedocs.io/en/latest/020_advanced.html</nowiki>

Eine Môglichkeit besteht in dem Befehl <code>module use /path/to/personal/modulefiles</code>, alternativ kann der Pfad zu privaten Moduldateien auch gleich zur Variable <code>$MODULEPATH</code> hinzugefügt werden.

Informationen bezüglich des Aufbaus der Moduldateien finden sich in der lmod-Dokumentation auf der Webseite. Ebenso können die bereitgestellten Module unter <code>/software/modules</code> als Inspiration dienen.

==== Für Nutzer: ====
Für Nutzer von HPC@HU finden sich unter <code>/software/modules/software.md</code> weitere Informationen über die verfügbare Software und wie diese gebaut/konfiguriert wurde.

Modules & Verfügbare Software

2025-01-17T13:57:48Z

Mielczad: /* Anaconda, Conda, Mamba */ Update

==== Übersicht & Grundlagen zur Nuzung ====
Die bereitgestellten Compute-Knoten nutzen Linux, genaugenommen ein OpenSUSE.

HPC-typisch wird zentral Software bereitgestellt. Verfügbare Software wird über eine Modulumgebung geladen.

Welche Software verfügbar ist, lässt sich über <code>module avail</code> sowie <code>module spider <name></code> in Erfahrung bringen.

(Online Anleitung für lmod https://lmod.readthedocs.io/en/latest/010_user.html )

Wir bieten aktuell drei Gruppe von Software an:

# /hu "Von Uns" kompilierte Software welche zentral bereitgestellt wird.
# /all Über EasyBuild ( siehe http://docs.easybuild.io/what-is-easybuild/ ) bereitgestellte Software
# /intel Software welche mit Installer ausgeliefert wurde (wie zum Beispiel Intel OneAPI)

Bei der Auswahl von Software sollte darauf geachtet werden dass die Groß- und Kleinschreibung von Bedeutung ist, sprich gcc ist nicht gleich GCC.

Die finalen Pfade sind aktuell auch nicht endgültig festgelegt und können sich noch verändern.

Ferner wird empfohlen sich nicht auf die Defaults zu verlassen und die Version einer Software explizit auszuwählen.

Anwendungsbeispiel:

Die verfügbaren openmpi Versionen lassen sich mit dem Befehl
module spider openmpi
erfragen

Ist daraufhin die Version erwünscht, lässt sich diese mit dem Befehl
module load openmpi/5.0.3-gcc14.1.0
laden.

Aktuell geladene Module lassen sich mit
module list
anzeigen, während
module purge
alle geladenen Module "entlädt".

Aktuell wird die verfügbare Software noch ausgebaut, wodurch sich die Liste relativ schnell entwickelt. Für einen Überblick der aktuell verfügbaren Software wird gebeten diese direkt auf dem System abzufragen. Vor allem mit EasyBuild installierte Software bringt standardmäßig sehr viele kleine Abhängigkeiten mit.

Einen ersten Überblick über einige der wichtigeren Pakete (als Eigenkompilation) bietet die folgende Liste:

==== Verfügbare Software ====

===== Programmiersprachen und Compiler =====
- AMD aocc

- 4.2.0

- gcc

- 9.5.0

- 10.5.0

- 11.4.0

- 12.3.0

- 13.2.0

- 14.1.0

- 14.2.0

- Intel OneApi

- 2024.1

- Julia

- 1.10.3

- python

- 3.8.19

- 3.9.19

- 3.10.14

- 3.11.9

- 3.12.3

- QT (opensource)

- 5.15.14

- R

- 4.4.0

- ruby

- 3.3

===== Bibliotheken und Tools =====
- AMD AOCL

- 4.2.0 gcc

- 4.2.0 aocl

- apache-maven

- 3.9.8

- bash

- 5.2.21

- bc

- 1.0.7

- bison

- 3.8.2

- BLIS

- 4.2.0

- block2

- p0.5.3rc13 openmpi/5.0.3 gcc/14.1.0 OpenBLAS/0.3.26

- boost

- 1.85 gcc/13.2.0

- 1.85 gcc/14.1.0

- Catch2

- 3.6.0 cmake/3.29.3

- cmake

- 3.16.9

- 3.20.6

- 3.27.2

- 3.29.2

- 3.29.3

- coreutils

- 9.5

- costa

2.2.2

- cuda

- 10

- 11

- 12.0

- 12

- 12.1

- 12.2

- 12.3

- 12.4

- 12.4.1

- crest

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc13.2.0 openmpi/5.0.3-gcc13.2.0 gcc/13.2.0

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc14.1.0 openmpi/5.0.3-gcc14.1.0 gcc/14.1.0

fftw

- 3.3.0 gcc/14.1.0

- 3.3.0 openmpi/5.0.3 gcc/14.1.0

- flex

- 2.6.4

- fmt

- 10.2.1

- gsl

- 2.8

- hdf5

- 1.14.4.3

- lapack

- 3.12.0 gcc/13.2.0

- 3.12.0 gcc/14.1.0

- libaec

- 1.1.3

- libflame

- 4.2.0

- libunwind

- 1.8.1

- libxc

- 6.6.2

- magma

- 2.8.8

- mpich

- 3.2.0 gcc/12.3.0

- 3.3.0 gcc/12.3.0

- 4.1.3 gcc/12.3.0

- 4.2.1 gcc/14.1.0

- OpenBLAS

- 0.3.26 gcc/13.2.0

- 0.3.26 gcc/14.1.0

- OpenCoarrays

- 2.9.3 mpich/3.3.0 gcc/12.3.0

- 2.10.2 openmpi/5.0.3 gcc/14.1.0

- OpenMPI

- 4.1.6 gcc/13.2.0

- 5.0.3 gcc/13.2.0

- 5.0.3 gcc/14.1.0

- 5.0.5 gcc/14.2.0

- patch

- 2.7.6

- proj

- 9.4.1 gcc/14.1.0

- scalapack

- 2.2.0

- spglib

- 2.4.0 gcc/14.1.0

- sirius

- 7.5.2

- spla

- 1.6.1

- swig

- 4.2.1

- szip

- 2.1.1

- umpire

- 2024.02.01

===== Software =====
- Blender

- 4.3

- Gaussian 16

- A.03

- GaussView

- 6.0.16

- gdal

- 3.9.0 gcc/14.1.0 proj/9.4.1 swig/4.2.1 python/3.12.3

- hadoopp

- 3.4.0

- hpl

- v2.3

- ior

- 4.0.0 openmpi/5.0.3 gcc/14.1.0

- ncdu

- 1.20

- OpenFOAM

- 11

- v2312

- ORCA

- 5.0.4

- quantum-espresso

- 7.3.1 OpenBLAS/0.3.26 fftw/3.3.10 penmpi/5.0.3 gcc/14.1.0

- xtb

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/13.2.0

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/14.1.0

===== Fehlt was? =====
Da es sich beim HPC um ein Linux System handelt, ist es möglich eigene Software zu entwickeln. Die Einbindung von Software findet überwiegend über zwei grundlegende Variablen statt. <code>PATH</code> für ausführbare Binärdateien sowie <code>LD_LIBRARY_PATH</code> für verlinkte Bibliotheken.

Über ein <code>export PATH=/new/path:$PATH</code> sowie <code>export LD_LIBRARY_PATH=/new/path:$LD_LIBRARY_PATH</code> lassen sich beide erweitern. Diese Änderung gilt bis zum verlassen der Shell - oder ist "semi-permanent" wenn der Export in die .profile oder .bashrc Datei eingetragen wird.

Hierbei gilt es ferner zu beachten dass die Reihenfolge der Auflistung der verschiedenen Pfade von Bedeutung ist: die zuerst gefundene Variante wird genommen.

Obschon es möglich ist eine Software zu kompilieren, bitten wir darum bei fehlender freier Software nach Möglichkeit zuerst eine Anfrage an [mailto:hpc-support@hu-berlin.de hpc-support@hu-berlin.de] zu schicken, damit diese zentral für Alle zugänglich ist.

Bei Anfragen zu kommerzieller Software, internen Eigenentwicklungen oder anderweitig speziell lizenzierter Software stehen wir ebenfalls gerne zu Verfügung.

==== Python, Anaconda, Conda, Mamba ====

===== Python =====
Python wird in vielen Projekten eingesetzt. Die Nutzung von Python ist nicht immer problemfrei, darum gibt es folgend einige Empfehlungen für die Nutzung von Python, welche das Risiko von Problemen sowie die Problembeseitigung erleichtern.

Im Allgemeinen sollten Python Anwendungen in einer virtuellen Umgebung entwickelt und ausgeführt werden. Diese wird nativ von Python unterstützt und ermöglicht es Pakete auf einer bestimmten Version zu halten sowie eventuelle Inkompatibilitäten zwischen verschiedenen Projekten zu vermeiden. Ferner ist es möglich bei Problemen eine virtuelle Umgebung zu löschen und dadurch alte Pakete Rückstandslos zu entfernen. Das ist vor allem interessant da pip oder pip3 Abhängigkeiten installieren kann, aber im Gegensatz zu typischen Linux-Paketmanagern Abhängigkeiten nicht automatisch deinstallieren kann.

Eine virtuelle Umgebung kann wie folgt erstellt werden (mit einem relativen oder absoluten Pfad):
<code>python -m venv /Pfad/zur/neuen/virtuellen_Umgebung</code>
Mehr dazu auf in der Dokumentation von Python: <nowiki>https://docs.python.org/3/library/venv.html</nowiki>

Sollte es aus bestimmten Gründen nicht möglich sein eine virtuelle Umgebung zu nutzen, kann man mit pip Pakete in einem bestimmten Ordner installieren.
<code>pip3 install --target /Pfad/zum/ZielOrdner</code>
Danach kann der Ordner zur Variable PYTHONPATH hinzugefügt werden und wird dann von der Python-Umgebung erkannt.

Die virtuellen Umgebungen sind im Allgemeinen jedoch zu präferieren.

===== Anaconda, Conda, Mamba =====
Eine weitere Alternative ist die Nutzung einer Paketverwaltung in Python, so wie diese über Anaconda/conda/mamba angeboten wird, bei dieser ist der Funktionsumfang dann auch größer als be pip.

Hierbei werden Nutzer und Nutzerinnen angehalten die Nutzungsbedingungen von vor allem Anaconda und Miniconda zu beachten. Aktuell (Januar 2025) wird Miniforge unter der BSD Lizenz angeboten und ist auf Github unter <nowiki>https://github.com/conda-forge/miniforge</nowiki> verfügbar.

Es wurde mit einer zentralen Instanz von miniforge3 experimentiert, allerdings erweist sich die Verwaltung der Umgebung als unpraktisch und schwieriger als nötig, da normale Nutzer keine Schreibrechte in dem zentralen Installationsordner haben. Standardmäßig wird conda/mamba daraufhin versuchen einen Ordner im Home-Verzeichnis anzulegen, wobei jedoch dort der verfügbare Platz beschränkt ist. Alternativ kann ein expliziter Prefix wie folgt angegeben werden, <code>conda create --prefix /Pfad/zur/neuen/conda_Umgebung</code>, der dann jedoch nicht zwingend von conda direkt erkannt wird...

Es wird darum empfohlen eine eigene Installation von miniforge auf dem zentralen Lustre-Dateisystem aufzusetzen und seine eigene Umgebungen zu verwalten. Für die "Grundversorgung" mit reinem Python, stehen zentral Python-Instanzen zu Verfügung.

Bei der Einrichtung muss dann nur darauf geachtet werden dass der Installationspfad korrekt eingegeben wird. Da eine solche Installation mit der Zeit recht groß werden kann, wird empfohlen dass zuvor erwähnte Lustre-Dateisystem zu nutzen. Der Pfad würde dementsprechend <code>/lustre/<Fakultät>/<Benutzername></code> lauten.

Mit <code>conda init</code> oder <code>mamba init</code> wird die Umgebung initialisiert und die .bashrc Datei angepasst. Dabei werden eventuell existierende conda/mamba Konfigurationen überschrieben (!!!). Dies ist beim benutzen von mehreren Versionen potenziell problematisch und erfordert eine manuelle Anpassung der Skripte sowie potenziell deren Auslagerung in individuelle Dateien.

==== Persönliche Module ====
Es ist möglich eigene Module in <code>lmod</code> einzubinden, wie in der Dokumentation beschrieben: <nowiki>https://lmod.readthedocs.io/en/latest/020_advanced.html</nowiki>

Eine Môglichkeit besteht in dem Befehl <code>module use /path/to/personal/modulefiles</code>, alternativ kann der Pfad zu privaten Moduldateien auch gleich zur Variable <code>$MODULEPATH</code> hinzugefügt werden.

Informationen bezüglich des Aufbaus der Moduldateien finden sich in der lmod-Dokumentation auf der Webseite. Ebenso können die bereitgestellten Module unter <code>/software/modules</code> als Inspiration dienen.

==== Für Nutzer: ====
Für Nutzer von HPC@HU finden sich unter <code>/software/modules/software.md</code> weitere Informationen über die verfügbare Software und wie diese gebaut/konfiguriert wurde.

Modules & Verfügbare Software

2025-01-17T11:45:38Z

Mielczad: /* Anaconda, Conda, Mamba */

==== Übersicht & Grundlagen zur Nuzung ====
Die bereitgestellten Compute-Knoten nutzen Linux, genaugenommen ein OpenSUSE.

HPC-typisch wird zentral Software bereitgestellt. Verfügbare Software wird über eine Modulumgebung geladen.

Welche Software verfügbar ist, lässt sich über <code>module avail</code> sowie <code>module spider <name></code> in Erfahrung bringen.

(Online Anleitung für lmod https://lmod.readthedocs.io/en/latest/010_user.html )

Wir bieten aktuell drei Gruppe von Software an:

# /hu "Von Uns" kompilierte Software welche zentral bereitgestellt wird.
# /all Über EasyBuild ( siehe http://docs.easybuild.io/what-is-easybuild/ ) bereitgestellte Software
# /intel Software welche mit Installer ausgeliefert wurde (wie zum Beispiel Intel OneAPI)

Bei der Auswahl von Software sollte darauf geachtet werden dass die Groß- und Kleinschreibung von Bedeutung ist, sprich gcc ist nicht gleich GCC.

Die finalen Pfade sind aktuell auch nicht endgültig festgelegt und können sich noch verändern.

Ferner wird empfohlen sich nicht auf die Defaults zu verlassen und die Version einer Software explizit auszuwählen.

Anwendungsbeispiel:

Die verfügbaren openmpi Versionen lassen sich mit dem Befehl
module spider openmpi
erfragen

Ist daraufhin die Version erwünscht, lässt sich diese mit dem Befehl
module load openmpi/5.0.3-gcc14.1.0
laden.

Aktuell geladene Module lassen sich mit
module list
anzeigen, während
module purge
alle geladenen Module "entlädt".

Aktuell wird die verfügbare Software noch ausgebaut, wodurch sich die Liste relativ schnell entwickelt. Für einen Überblick der aktuell verfügbaren Software wird gebeten diese direkt auf dem System abzufragen. Vor allem mit EasyBuild installierte Software bringt standardmäßig sehr viele kleine Abhängigkeiten mit.

Einen ersten Überblick über einige der wichtigeren Pakete (als Eigenkompilation) bietet die folgende Liste:

==== Verfügbare Software ====

===== Programmiersprachen und Compiler =====
- AMD aocc

- 4.2.0

- gcc

- 9.5.0

- 10.5.0

- 11.4.0

- 12.3.0

- 13.2.0

- 14.1.0

- 14.2.0

- Intel OneApi

- 2024.1

- Julia

- 1.10.3

- python

- 3.8.19

- 3.9.19

- 3.10.14

- 3.11.9

- 3.12.3

- QT (opensource)

- 5.15.14

- R

- 4.4.0

- ruby

- 3.3

===== Bibliotheken und Tools =====
- AMD AOCL

- 4.2.0 gcc

- 4.2.0 aocl

- apache-maven

- 3.9.8

- bash

- 5.2.21

- bc

- 1.0.7

- bison

- 3.8.2

- BLIS

- 4.2.0

- block2

- p0.5.3rc13 openmpi/5.0.3 gcc/14.1.0 OpenBLAS/0.3.26

- boost

- 1.85 gcc/13.2.0

- 1.85 gcc/14.1.0

- Catch2

- 3.6.0 cmake/3.29.3

- cmake

- 3.16.9

- 3.20.6

- 3.27.2

- 3.29.2

- 3.29.3

- coreutils

- 9.5

- costa

2.2.2

- cuda

- 10

- 11

- 12.0

- 12

- 12.1

- 12.2

- 12.3

- 12.4

- 12.4.1

- crest

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc13.2.0 openmpi/5.0.3-gcc13.2.0 gcc/13.2.0

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc14.1.0 openmpi/5.0.3-gcc14.1.0 gcc/14.1.0

fftw

- 3.3.0 gcc/14.1.0

- 3.3.0 openmpi/5.0.3 gcc/14.1.0

- flex

- 2.6.4

- fmt

- 10.2.1

- gsl

- 2.8

- hdf5

- 1.14.4.3

- lapack

- 3.12.0 gcc/13.2.0

- 3.12.0 gcc/14.1.0

- libaec

- 1.1.3

- libflame

- 4.2.0

- libunwind

- 1.8.1

- libxc

- 6.6.2

- magma

- 2.8.8

- mpich

- 3.2.0 gcc/12.3.0

- 3.3.0 gcc/12.3.0

- 4.1.3 gcc/12.3.0

- 4.2.1 gcc/14.1.0

- OpenBLAS

- 0.3.26 gcc/13.2.0

- 0.3.26 gcc/14.1.0

- OpenCoarrays

- 2.9.3 mpich/3.3.0 gcc/12.3.0

- 2.10.2 openmpi/5.0.3 gcc/14.1.0

- OpenMPI

- 4.1.6 gcc/13.2.0

- 5.0.3 gcc/13.2.0

- 5.0.3 gcc/14.1.0

- 5.0.5 gcc/14.2.0

- patch

- 2.7.6

- proj

- 9.4.1 gcc/14.1.0

- scalapack

- 2.2.0

- spglib

- 2.4.0 gcc/14.1.0

- sirius

- 7.5.2

- spla

- 1.6.1

- swig

- 4.2.1

- szip

- 2.1.1

- umpire

- 2024.02.01

===== Software =====
- Blender

- 4.3

- Gaussian 16

- A.03

- GaussView

- 6.0.16

- gdal

- 3.9.0 gcc/14.1.0 proj/9.4.1 swig/4.2.1 python/3.12.3

- hadoopp

- 3.4.0

- hpl

- v2.3

- ior

- 4.0.0 openmpi/5.0.3 gcc/14.1.0

- ncdu

- 1.20

- OpenFOAM

- 11

- v2312

- ORCA

- 5.0.4

- quantum-espresso

- 7.3.1 OpenBLAS/0.3.26 fftw/3.3.10 penmpi/5.0.3 gcc/14.1.0

- xtb

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/13.2.0

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/14.1.0

===== Fehlt was? =====
Da es sich beim HPC um ein Linux System handelt, ist es möglich eigene Software zu entwickeln. Die Einbindung von Software findet überwiegend über zwei grundlegende Variablen statt. <code>PATH</code> für ausführbare Binärdateien sowie <code>LD_LIBRARY_PATH</code> für verlinkte Bibliotheken.

Über ein <code>export PATH=/new/path:$PATH</code> sowie <code>export LD_LIBRARY_PATH=/new/path:$LD_LIBRARY_PATH</code> lassen sich beide erweitern. Diese Änderung gilt bis zum verlassen der Shell - oder ist "semi-permanent" wenn der Export in die .profile oder .bashrc Datei eingetragen wird.

Hierbei gilt es ferner zu beachten dass die Reihenfolge der Auflistung der verschiedenen Pfade von Bedeutung ist: die zuerst gefundene Variante wird genommen.

Obschon es möglich ist eine Software zu kompilieren, bitten wir darum bei fehlender freier Software nach Möglichkeit zuerst eine Anfrage an [mailto:hpc-support@hu-berlin.de hpc-support@hu-berlin.de] zu schicken, damit diese zentral für Alle zugänglich ist.

Bei Anfragen zu kommerzieller Software, internen Eigenentwicklungen oder anderweitig speziell lizenzierter Software stehen wir ebenfalls gerne zu Verfügung.

==== Python, Anaconda, Conda, Mamba ====

===== Python =====
Python wird in vielen Projekten eingesetzt. Die Nutzung von Python ist nicht immer problemfrei, darum gibt es folgend einige Empfehlungen für die Nutzung von Python, welche das Risiko von Problemen sowie die Problembeseitigung erleichtern.

Im Allgemeinen sollten Python Anwendungen in einer virtuellen Umgebung entwickelt und ausgeführt werden. Diese wird nativ von Python unterstützt und ermöglicht es Pakete auf einer bestimmten Version zu halten sowie eventuelle Inkompatibilitäten zwischen verschiedenen Projekten zu vermeiden. Ferner ist es möglich bei Problemen eine virtuelle Umgebung zu löschen und dadurch alte Pakete Rückstandslos zu entfernen. Das ist vor allem interessant da pip oder pip3 Abhängigkeiten installieren kann, aber im Gegensatz zu typischen Linux-Paketmanagern Abhängigkeiten nicht automatisch deinstallieren kann.

Eine virtuelle Umgebung kann wie folgt erstellt werden (mit einem relativen oder absoluten Pfad):
<code>python -m venv /Pfad/zur/neuen/virtuellen_Umgebung</code>
Mehr dazu auf in der Dokumentation von Python: <nowiki>https://docs.python.org/3/library/venv.html</nowiki>

Sollte es aus bestimmten Gründen nicht möglich sein eine virtuelle Umgebung zu nutzen, kann man mit pip Pakete in einem bestimmten Ordner installieren.
<code>pip3 install --target /Pfad/zum/ZielOrdner</code>
Danach kann der Ordner zur Variable PYTHONPATH hinzugefügt werden und wird dann von der Python-Umgebung erkannt.

Die virtuellen Umgebungen sind im Allgemeinen jedoch zu präferieren.

===== Anaconda, Conda, Mamba =====
<s>Eine weitere Alternative ist die Nutzung einer Packetverwaltung in Python, so wie diese über Anaconda/conda/mamba angeboten wird, bei dieser ist der Funktionsumfang dann auch größer als be pip.</s>

<s>Hierbei werden Nutzer und Nutzerinnen angehalten die Nutzungsbedingungen von vor allem Anaconda und Miniconda zu beachten. Aktuell (Juli 2024) wird Miniforge unter der BSD Lizenz angeboten und ist in in Bezug auf die Nutzung.</s>

<s>Während eine zentrale Installation von conda und mamba über miniforge3 bereitgestellt wird, haben normale Nutzer keine Schreibrechte in dem zentralen Installationsordner. Standardmäßig wird conda/mamba daraufhin versuchen einen Ordner im Home-Verzeichnis anzulegen, alternativ kann ein expliziter Prefix wie folgt angegeben werden.</s>
<code><s>conda create --prefix /Pfad/zur/neuen/conda_Umgebung</s></code>
<s>Für typische Nutzertools wird darum empfohlen eine eigene Installation von miniforge aufzusetzen und eigene Umgebungen zu verwalten. Bei der Einrichtung muss dann nur darauf geachtet werden dass der Installationspfad korrekt eingegeben wird. Da eine solche Installation mit der Zeit recht groß werden kann, wird empfohlen dass lustre Dateisystem zu nutzen, der Pfad würde dementsprechend <code>/lustre/<Fakultät>/<Benutzername></code> lauten.</s>

<s>Mit <code>conda init</code> oder <code>mamba init</code> wird die Umgebung initiialisiert und die .bashrc Datei angepasst. Dabei werden eventuell existierende conda/mamba Konfigurationen überschrieben (!!!). Dies ist beim benutzen von mehreren Versionen potenziell problematisch und erfordert eine manuelle Anpassung der Skripte sowie potenziell deren Auslagerung in individuelle Dateien.</s>

==== Persönliche Module ====
Es ist möglich eigene Module in <code>lmod</code> einzubinden, wie in der Dokumentation beschrieben: <nowiki>https://lmod.readthedocs.io/en/latest/020_advanced.html</nowiki>

Eine Môglichkeit besteht in dem Befehl <code>module use /path/to/personal/modulefiles</code>, alternativ kann der Pfad zu privaten Moduldateien auch gleich zur Variable <code>$MODULEPATH</code> hinzugefügt werden.

Informationen bezüglich des Aufbaus der Moduldateien finden sich in der lmod-Dokumentation auf der Webseite. Ebenso können die bereitgestellten Module unter <code>/software/modules</code> als Inspiration dienen.

==== Für Nutzer: ====
Für Nutzer von HPC@HU finden sich unter <code>/software/modules/software.md</code> weitere Informationen über die verfügbare Software und wie diese gebaut/konfiguriert wurde.

Lustre Grundlagen

2024-12-18T15:25:22Z

Mielczad: Neue Seite über Unser Lustre

= Lustre Grundlagen =
Als zentrales paralleles Dateisystem steht ein Lustre mit insgesamt 1.6PB Speicherplatz zu Verfügung. Dieses ist unter <code>/lustre</code> erreichbar und bildet in seiner Struktur standardmäßig das Home-Directory nach, sprich die Pfade entsprechen <code>/lustre/<Fachbereich>/<Nutzername>/</code>, wobei Ordner für Gruppen innerhalb der Fachbereiche auch willkommen sind.

Technisch besteht das Lustre aus :

* 1 Management Server
* 2 Metadaten Servern (MGS)
** mit insgesamt 4 MDTs (initiale Konfiguration + Ausbaut) auf SSDs
* 4 Storage Servern (OSS)
** mit je 4 OSTs, bestehend aus je 8 Festplatten zu 16TB in RAID 6

Angebunden ist es über 100GBit/s Ethernet.

Die Lustre Clients kommunizieren hier mit mit dem Management Server um initial Informationen über das Lustre zu erhalten.

Nach dem ersten Verbindungsaufbau involviert zukünftige Kommunikation nur noch die Metadaten sowie Storage Server. Hierfür wird beim Zugriff auf das Lustre zuerst der Metadatenserver angefragt, welcher dann einen Storage Server zuweist (zum Lesen oder Schreiben von Dateien).

Aus diesem Grund sollte das Lustre bevorzugt für größere Dateien genutzt werden, da die Kommunikation zu einem relativ hohen "Overhead" bei kleinen Dateien (im KB-Bereich) führt. Die schlechte Leistung eines Lustre bei kleinen Dateien sind bekannt und werden anderweitig gut erläutert und erklärt. Hier lohnt sich die Nutzung eines lokalen temporären Speichers in den Servern selbst unter <code>/tmp</code>. Dieser wird jedoch nach Ende eines Jobs gelöscht und ist nicht persistent. Lösungen für einen besseren Datendurchsatz sind vonseiten der Lustre Server und Client Software verfügbar und an deren Implementierung wird gearbeitet.

Standardmäßig werden Dateien auf jeweils ein OST geschrieben (Stripe = 1), was den maximalen Datendurchsatz auf den eines OST beschränkt. Dabei gilt die Verteilung auf OSTs pro Datei, nicht pro Ordner: Sprich, es ist möglich dass verschiedene Dateien in einem Ordner auf verschiedenen OSTs liegen, was den globalen Datendurchsatz erhöht.

Werden sehr große Dateien geschrieben, kann es von Interesse sein diese über mehrere OSTs zu verteilen. Hierbei ist es nur Möglich diese Einstellung für neue Dateien zu verändern. mit <code>lfs setstripe</code> kann dieser Parameter für einen Ordner gesetzt oder gelöscht werden - oder auch eine Datei mit der entsprechenden Einstellung erstellt werden.

Nehmen wir an, wir möchen eine Datei oder einen Ordner über 2 OSTs verteilen, so lässt sich die Einstellung für einen Ordner wie folgt setzen:

<code>lfs setstripe -c 2</code>

Für das erstellen einer neue Datei mit zwei Stripes wäre der folgende Befehl erforderlich:

<code>lfs setstripe -c 2 NeueDatei</code>

Hierbei ist anzumerken dass es nicht möglich ist die Verteilung einer Datei nachträglich zu ändern. Für Änderungen muss eine neue Datei geschrieben werden, was demnach bedeutet dass die Datei kopiert werden muss und nicht verschoben werden kann um Einstellungen am Striping zu verändern. In Ordnern können die Einstellungen angepasst werden, wobei die jeweils aktuelle Einstellung alle zukünftigen Dateien betrifft.

Die Einstellungen für einen Ordner lassen sich auch mit folgendem Befehl löschen, danach wird wieder ein Stripe pro Datei genutzt:

<code>lfs setstripe --delete</code>

Ob sich die Nutzung mehrerer OSTs für einen Job im HPC-Betrieb lohnt, hängt hier stark von den Dateimengen und den Zugriffsmustern ab.

Die Butzung von Stripes - der Verteilung von Daten über mehrere OSTs führt nicht zwingend zu einem höheren Datendurchsatz und ist vom Nutzungsprofil abhängig. Mehrere OSTs kann bedeuten dass Daten auch von mehreren Storage Servern (OSS) angefragt werden müssen. In diesem Fall kann bei kleinen Dateien der Kommunikationsaufwand höher sein als der Gewinn an zusätzlichem Datendurchsatz. Dazu erhöht sich der "Arbeitsaufwand" für die Metadatenserver bei Dateien welche über mehrere OSTs verteilt sind. Sind Dateien jedoch hinreichen groß, kann die Verteilung zu einem erhöhten Datendurchsatz führen und dadurch die Leistung steigern.

Hauptseite

2024-12-18T15:20:07Z

Mielczad: /* Slurm Cluster */

Der Service '''"HPC@HU'''" stellt folgende Dienste zur Verfügung:

# Zentraler Slurm-Cluster
# Azimuth-Service

Beide Services bieten die Möglichkeit, die HPC-Infrastruktur der HU zu nutzen. Dabei bietet der Slurm-Cluster eine Vielzahl an Softwarepaketen und ist direkt mit dem HU-Account nutzbar, wohingegen der Azimuth-Service größere Flexibilität ermöglicht und u.a. auch andere Platformen wie JupyterHub zur Verfügung stellt.

== Slurm Cluster ==
Der zentrale Slurm-Cluster ist nach Anmeldung per Mail direkt mit dem HU-Account nutzbar. Der Zugang erfolgt über ein Login-Knoten,

Weitere Informationen:

* [[Erste Verbindung/Einloggen]]
* [[Datenspeicher & Dateistruktur]]
* [[Modules & Verfügbare Software]]
* [[Containerisierung]]
* [[Jobs einreichen mit SLURM]]
* [[Lustre Grundlagen]]
* [[Mailingliste und Support]]
* [[FAQ]]

== Azimuth ==
Azimuth bietet die Möglichkeit, verschiedene Plattformen, die man auch dem HPC-Bereich kennt, zu erstellen und zu verwalten. Dazu gehört u.a.:

# Slurm-Cluster
# JupyterHub
# HPC-Workstation

Die NutzerInnen können nach der Erstellung, die gewählte Plattform selbständig verwalten und erweitern. Dazu bekommen sie einen Administratorenzugang. Zur Zeit ist die Lebensdauer der Plattform nicht begrenzt.

Der Zugang zum Azimuth-Service erfolgt über den DV-Beauftragten der Einrichtung.

Jobs einreichen mit SLURM

2024-12-13T08:33:00Z

Mielczad: Beschreibung der queue-config

==== Einführung ====
Der Queue-Manager für HPC@HU ist SLURM ( siehe https://slurm.schedmd.com/quickstart.html )

Ein Beispiel kann wie folgt aussehen:
<code>#!/bin/bash</code>
<code>#SBATCH --ntasks=1 # Run on a single CPU</code>
<code>#SBATCH --mem=1gb # Job memory request</code>
<code>#SBATCH --time=00:05:00 # Time limit hrs:min:sec</code>
<code>#SBATCH --partition=standard</code>
<code>#SBATCH --account=nutzername</code>

<code>hostname</code>
Hier steht hostname beispielhaft für einen Script oder die Ausführung einer Software für Berechnungen.

Sollten im Script Variablen gesetzt werden, ist es wichtig dass dies erst nach der Definition des Jobs für SLURM geschieht.

Nennt sich der Scirpt <code>submit.bash</code> , lässt sich dieser dann über
sbatch submit.bash
beim Scheduler einreichen.

Der aktuelle Status lässt sich über
squeue
oder
squeue -u Nutzername
abfragen.

==== Parallelisierung mit mehreren Compute-Knoten: ====
Es ist möglich Berechnungen über mehrere Compute-Knoten laufen zu lassen. Hierbei sollte bedacht werden, dass Abhängig von den Virtuellen Maschinen in der aktuellen Konfiguration, die Kommunikation lokal auf einem Server oder über 100GBit/s Ethernet stattfindet.

Hierbei ist die Integration von openMPI und SLURM von der Nutzerseite einfach zu handhaben.

Um eine Berechnung über 2 Compute-Knoten laufen zu lassen, definiere ich zum Beispiel meine Anzahl an Threads sowie die Anzahl der Knoten:

#!/bin/bash
#SBATCH --ntasks=40 # Run 40 threads/processes
#SBATCH --ntasks-per-node=20 # Run 20 per compute node
#SBATCH --nodes=2 # Run on 2 nodes
#SBATCH --mem=80gb # Job memory needed per node (per node is important!!)
#SBATCH --time=96:00:00 # Time limit hrs:min:sec
#SBATCH --partition=standard
#SBATCH --account=<user account>

Danach rufe ich mein Programm ganz gewöhnlich über mpirun auf.

Der Aufruf des Programms (hier xhpl) sieht dann wie folgt aus:
mpirun -np 40 xhpl

=== Interaktive Sessions ===
Es ist möglich interaktive Sessions auf den Compute Knoten zu starten. Hierbei müsse die Ressourcen direkt auf der Befehlszeile angefordert werden, zum Beispiel wie folgt:
<code>srun --nodes=1 --exclusive --pty bash -i</code>
oder auch
<code>srun --nodes=1 --ntasks-per-node=1 --time=01:00:00 --pty bash -i</code>

==== Verfügbare Ressourcen: ====
Aktuell eingerichtete virtuelle Maschinen verfügen über je:
* 64 Threads (ûber 32 Kerne)
* 256GB Arbeitsspeicher
* knapp 1,5TB lokalen scratch

==== Queues / Partitionen ====
SLURM bietet die Möglichkeit Partitionen zu definieren, oft als "queues" bekannt.

Aktuell stehen den Nutzern folgende Queues zu Verfügung, wobei manche auf bestimmte Nutzergruppen beschränkt sind.
{| class="wikitable"
!PartitionName
!DefaultTime
!MaxTime
!DefMemPerCPU
!MaxMemPerCPU
!MaxNodes
|-
|desktop
|4:00:00
|26:00:00
|2000
|8000
|1
|-
|interactive
|1:00:00
|2:00:00
|2000
|8000
|1
|-
|standard
|04:00:00
|4-00:00:00
|2000
|8000
|12
|-
|longrun
|4-00:00:00
|14-00:00:00
|2000
|8000
|8
|-
|gpu
|04:00:00
|14-00:00:00
|2000
|8000
|2
|-
|large_memory
|04:00:00
|14-00:00:00
|8000
|64000
|2
|-
|chemie
|04:00:00
|20-00:00:00
|8000
|64000
|16
|-
|physik
|04:00:00
|20-00:00:00
|8000
|64000
|16
|}

Modules & Verfügbare Software

2024-12-06T12:25:40Z

Mielczad: /* Software */ add Blender

==== Übersicht & Grundlagen zur Nuzung ====
Die bereitgestellten Compute-Knoten nutzen Linux, genaugenommen ein OpenSUSE.

HPC-typisch wird zentral Software bereitgestellt. Verfügbare Software wird über eine Modulumgebung geladen.

Welche Software verfügbar ist, lässt sich über <code>module avail</code> sowie <code>module spider <name></code> in Erfahrung bringen.

(Online Anleitung für lmod https://lmod.readthedocs.io/en/latest/010_user.html )

Wir bieten aktuell drei Gruppe von Software an:

# /hu "Von Uns" kompilierte Software welche zentral bereitgestellt wird.
# /all Über EasyBuild ( siehe http://docs.easybuild.io/what-is-easybuild/ ) bereitgestellte Software
# /intel Software welche mit Installer ausgeliefert wurde (wie zum Beispiel Intel OneAPI)

Bei der Auswahl von Software sollte darauf geachtet werden dass die Groß- und Kleinschreibung von Bedeutung ist, sprich gcc ist nicht gleich GCC.

Die finalen Pfade sind aktuell auch nicht endgültig festgelegt und können sich noch verändern.

Ferner wird empfohlen sich nicht auf die Defaults zu verlassen und die Version einer Software explizit auszuwählen.

Anwendungsbeispiel:

Die verfügbaren openmpi Versionen lassen sich mit dem Befehl
module spider openmpi
erfragen

Ist daraufhin die Version erwünscht, lässt sich diese mit dem Befehl
module load openmpi/5.0.3-gcc14.1.0
laden.

Aktuell geladene Module lassen sich mit
module list
anzeigen, während
module purge
alle geladenen Module "entlädt".

Aktuell wird die verfügbare Software noch ausgebaut, wodurch sich die Liste relativ schnell entwickelt. Für einen Überblick der aktuell verfügbaren Software wird gebeten diese direkt auf dem System abzufragen. Vor allem mit EasyBuild installierte Software bringt standardmäßig sehr viele kleine Abhängigkeiten mit.

Einen ersten Überblick über einige der wichtigeren Pakete (als Eigenkompilation) bietet die folgende Liste:

==== Verfügbare Software ====

===== Programmiersprachen und Compiler =====
- AMD aocc

- 4.2.0

- gcc

- 9.5.0

- 10.5.0

- 11.4.0

- 12.3.0

- 13.2.0

- 14.1.0

- 14.2.0

- Intel OneApi

- 2024.1

- Julia

- 1.10.3

- python

- 3.8.19

- 3.9.19

- 3.10.14

- 3.11.9

- 3.12.3

- QT (opensource)

- 5.15.14

- R

- 4.4.0

- ruby

- 3.3

===== Bibliotheken und Tools =====
- AMD AOCL

- 4.2.0 gcc

- 4.2.0 aocl

- apache-maven

- 3.9.8

- bash

- 5.2.21

- bc

- 1.0.7

- bison

- 3.8.2

- BLIS

- 4.2.0

- block2

- p0.5.3rc13 openmpi/5.0.3 gcc/14.1.0 OpenBLAS/0.3.26

- boost

- 1.85 gcc/13.2.0

- 1.85 gcc/14.1.0

- Catch2

- 3.6.0 cmake/3.29.3

- cmake

- 3.16.9

- 3.20.6

- 3.27.2

- 3.29.2

- 3.29.3

- coreutils

- 9.5

- costa

2.2.2

- cuda

- 10

- 11

- 12.0

- 12

- 12.1

- 12.2

- 12.3

- 12.4

- 12.4.1

- crest

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc13.2.0 openmpi/5.0.3-gcc13.2.0 gcc/13.2.0

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc14.1.0 openmpi/5.0.3-gcc14.1.0 gcc/14.1.0

fftw

- 3.3.0 gcc/14.1.0

- 3.3.0 openmpi/5.0.3 gcc/14.1.0

- flex

- 2.6.4

- fmt

- 10.2.1

- gsl

- 2.8

- hdf5

- 1.14.4.3

- lapack

- 3.12.0 gcc/13.2.0

- 3.12.0 gcc/14.1.0

- libaec

- 1.1.3

- libflame

- 4.2.0

- libunwind

- 1.8.1

- libxc

- 6.6.2

- magma

- 2.8.8

- mpich

- 3.2.0 gcc/12.3.0

- 3.3.0 gcc/12.3.0

- 4.1.3 gcc/12.3.0

- 4.2.1 gcc/14.1.0

- OpenBLAS

- 0.3.26 gcc/13.2.0

- 0.3.26 gcc/14.1.0

- OpenCoarrays

- 2.9.3 mpich/3.3.0 gcc/12.3.0

- 2.10.2 openmpi/5.0.3 gcc/14.1.0

- OpenMPI

- 4.1.6 gcc/13.2.0

- 5.0.3 gcc/13.2.0

- 5.0.3 gcc/14.1.0

- 5.0.5 gcc/14.2.0

- patch

- 2.7.6

- proj

- 9.4.1 gcc/14.1.0

- scalapack

- 2.2.0

- spglib

- 2.4.0 gcc/14.1.0

- sirius

- 7.5.2

- spla

- 1.6.1

- swig

- 4.2.1

- szip

- 2.1.1

- umpire

- 2024.02.01

===== Software =====
- Blender

- 4.3

- Gaussian 16

- A.03

- GaussView

- 6.0.16

- gdal

- 3.9.0 gcc/14.1.0 proj/9.4.1 swig/4.2.1 python/3.12.3

- hadoopp

- 3.4.0

- hpl

- v2.3

- ior

- 4.0.0 openmpi/5.0.3 gcc/14.1.0

- ncdu

- 1.20

- OpenFOAM

- 11

- v2312

- ORCA

- 5.0.4

- quantum-espresso

- 7.3.1 OpenBLAS/0.3.26 fftw/3.3.10 penmpi/5.0.3 gcc/14.1.0

- xtb

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/13.2.0

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/14.1.0

===== Fehlt was? =====
Da es sich beim HPC um ein Linux System handelt, ist es möglich eigene Software zu entwickeln. Die Einbindung von Software findet überwiegend über zwei grundlegende Variablen statt. <code>PATH</code> für ausführbare Binärdateien sowie <code>LD_LIBRARY_PATH</code> für verlinkte Bibliotheken.

Über ein <code>export PATH=/new/path:$PATH</code> sowie <code>export LD_LIBRARY_PATH=/new/path:$LD_LIBRARY_PATH</code> lassen sich beide erweitern. Diese Änderung gilt bis zum verlassen der Shell - oder ist "semi-permanent" wenn der Export in die .profile oder .bashrc Datei eingetragen wird.

Hierbei gilt es ferner zu beachten dass die Reihenfolge der Auflistung der verschiedenen Pfade von Bedeutung ist: die zuerst gefundene Variante wird genommen.

Obschon es möglich ist eine Software zu kompilieren, bitten wir darum bei fehlender freier Software nach Möglichkeit zuerst eine Anfrage an [mailto:hpc-support@hu-berlin.de hpc-support@hu-berlin.de] zu schicken, damit diese zentral für Alle zugänglich ist.

Bei Anfragen zu kommerzieller Software, internen Eigenentwicklungen oder anderweitig speziell lizenzierter Software stehen wir ebenfalls gerne zu Verfügung.

==== Python, Anaconda, Conda, Mamba ====

===== Python =====
Python wird in vielen Projekten eingesetzt. Die Nutzung von Python ist nicht immer problemfrei, darum gibt es folgend einige Empfehlungen für die Nutzung von Python, welche das Risiko von Problemen sowie die Problembeseitigung erleichtern.

Im Allgemeinen sollten Python Anwendungen in einer virtuellen Umgebung entwickelt und ausgeführt werden. Diese wird nativ von Python unterstützt und ermöglicht es Pakete auf einer bestimmten Version zu halten sowie eventuelle Inkompatibilitäten zwischen verschiedenen Projekten zu vermeiden. Ferner ist es möglich bei Problemen eine virtuelle Umgebung zu löschen und dadurch alte Pakete Rückstandslos zu entfernen. Das ist vor allem interessant da pip oder pip3 Abhängigkeiten installieren kann, aber im Gegensatz zu typischen Linux-Paketmanagern Abhängigkeiten nicht automatisch deinstallieren kann.

Eine virtuelle Umgebung kann wie folgt erstellt werden (mit einem relativen oder absoluten Pfad):
<code>python -m venv /Pfad/zur/neuen/virtuellen_Umgebung</code>
Mehr dazu auf in der Dokumentation von Python: <nowiki>https://docs.python.org/3/library/venv.html</nowiki>

Sollte es aus bestimmten Gründen nicht möglich sein eine virtuelle Umgebung zu nutzen, kann man mit pip Pakete in einem bestimmten Ordner installieren.
<code>pip3 install --target /Pfad/zum/ZielOrdner</code>
Danach kann der Ordner zur Variable PYTHONPATH hinzugefügt werden und wird dann von der Python-Umgebung erkannt.

Die virtuellen Umgebungen sind im Allgemeinen jedoch zu präferieren.

===== Anaconda, Conda, Mamba =====
Eine weitere Alternative ist die Nutzung einer Packetverwaltung in Python, so wie diese über Anaconda/conda/mamba angeboten wird, bei dieser ist der Funktionsumfang dann auch größer als be pip.

Hierbei werden Nutzer und Nutzerinnen angehalten die Nutzungsbedingungen von vor allem Anaconda und Miniconda zu beachten. Aktuell (Juli 2024) wird Miniforge unter der BSD Lizenz angeboten und ist in in Bezug auf die Nutzung.

Während eine zentrale Installation von conda und mamba über miniforge3 bereitgestellt wird, haben normale Nutzer keine Schreibrechte in dem zentralen Installationsordner. Standardmäßig wird conda/mamba daraufhin versuchen einen Ordner im Home-Verzeichnis anzulegen, alternativ kann ein expliziter Prefix wie folgt angegeben werden.
<code>conda create --prefix /Pfad/zur/neuen/conda_Umgebung</code>
Für typische Nutzertools wird darum empfohlen eine eigene Installation von miniforge aufzusetzen und eigene Umgebungen zu verwalten. Bei der Einrichtung muss dann nur darauf geachtet werden dass der Installationspfad korrekt eingegeben wird. Da eine solche Installation mit der Zeit recht groß werden kann, wird empfohlen dass lustre Dateisystem zu nutzen, der Pfad würde dementsprechend <code>/lustre/<Fakultät>/<Benutzername></code> lauten.

Mit <code>conda init</code> oder <code>mamba init</code> wird die Umgebung initiialisiert und die .bashrc Datei angepasst. Dabei werden eventuell existierende conda/mamba Konfigurationen überschrieben (!!!). Dies ist beim benutzen von mehreren Versionen potenziell problematisch und erfordert eine manuelle Anpassung der Skripte sowie potenziell deren Auslagerung in individuelle Dateien.

==== Persönliche Module ====
Es ist möglich eigene Module in <code>lmod</code> einzubinden, wie in der Dokumentation beschrieben: <nowiki>https://lmod.readthedocs.io/en/latest/020_advanced.html</nowiki>

Eine Môglichkeit besteht in dem Befehl <code>module use /path/to/personal/modulefiles</code>, alternativ kann der Pfad zu privaten Moduldateien auch gleich zur Variable <code>$MODULEPATH</code> hinzugefügt werden.

Informationen bezüglich des Aufbaus der Moduldateien finden sich in der lmod-Dokumentation auf der Webseite. Ebenso können die bereitgestellten Module unter <code>/software/modules</code> als Inspiration dienen.

==== Für Nutzer: ====
Für Nutzer von HPC@HU finden sich unter <code>/software/modules/software.md</code> weitere Informationen über die verfügbare Software und wie diese gebaut/konfiguriert wurde.

Datenspeicher & Dateistruktur

2024-12-04T09:53:15Z

Mielczad: /* Lustre */ Zusatz zum Lustre

Auf dem Slurm-Cluster stehen auf jeder Maschine (Login- & Exec-Server) folgende Verzeichnisse zur Verfügung.
{| class="wikitable"
!Pfad
!Größe
!Sichtbarkeit
!Dauer
!Besonderheit
|-
|$HOME
|
|global**
|unlimited
|20GB pro Nutzer
|-
|/tmp
|1.5TB
|local (Job)
|job-time
|autotmp_fs***
|-
|/dev/shm
|128GB
|local (Job)
|job-time
|autotmp_fs***
|-
|/lustre
|1.5PB
|global
|unlimited*
|
|}
<nowiki>*</nowiki>Die Daten werden zur Zeit erst bei sehr hoher Belegung gelöscht

<nowiki>**</nowiki>Die Verzeichnisse sind über NFS gemountet

<nowiki>***</nowiki>Die Verzeichnisse werden für jeden Job angelegt und gemountet. Andere Jobs sehen den Inhalt nicht. Verzeichnisse werden nach Job-Ende gelöscht.

Bei anderen Anforderungen bitten wir darum per Mail mit dem HPC-Support Kontakt aufzunehmen.

==== Home ====
Die Home-Verzeichnisse liegen im Netzwerk der Universität. Aus diesem Grund sind die Verzeichnisse auf eine Quota von 20GB pro Nutzer beschränkt und sollten im Normalfall nicht als Arbeitsverzeichnisse bei HPC Berechnungen genutzt werden. Vom Home-Verzeichnis werden so-genannte Snapshots erstellt - effektiv ein Backup. Einmal zu jeder Stunde, zur Minute null (bis zu 168 Snapshots, 1 Woche), dann jeden Tag um 00:00 Uhr (bis zu 30 Snapshots). Diese finden sich, in jedem Ordner, innerhalb eines unsichtbaren Ordners <code>.snapshot</code>. Dieser wird allerdings nicht über <code>ls -a</code> angezeigt. Allerdings ist es möglich in den Ordner hinein zu navigieren, <code>cd .snapshot</code> oder sich die Inhalte anzeigen zu lassen <code>ls .snapshot</code>. Dadurch lassen sich für die Nutzer und Nutzerinnen des HPC-Service Daten im Home-Verzeichnis selbst wiederherstellen.

Der individuelle Pfad zum Verzeichnis lautet <code>/home/<Fakultät>/<Benutzernmae></code>

==== Lustre ====
Als temporärer Datenspeicher steht ein Lustre-Dateisystem under <code>/lustre</code> zu Verfügung, mit einer Gesamtgeröße von 1.5PB.

Nach einem erfolgreichen Verbdindungsaufbau werden automatisch Ordern mit einer Dateistsruktur ähnlich dem Home-Verzeichnis angelegt und solten im Normalfall auch so genutzt werden. Bei Gruppenübergreifender Arbeit, lohnt es sich eventuell dedizierte Ordner auf der Fakultätsebene anzulegen.

Der individuelle Pfad zulm Verzeichnis lautet <code>/lustre/<Fakultät>/<Benutzernmae></code>

Bei Berechnungen die große Datenmengen erfordern oder bei denen Daten auch nach Ende des Jobs zu Verfügung stehenn sollen, ist das Lustre Dateisystem zu bevorzugen.

==== Lokaler Scratch ====
Um die Nutzung des lokalen scratch zu unterstützen wird das Plugin "auto_tmpdir" der University of Delaware genutzt (<nowiki>https://github.com/University-of-Delaware-IT-RCI/auto_tmpdir/tree/master</nowiki>).

Dieses Plugin erstellt einen dedizierten Ordner für einen ausgeführten job welcher dann unter /tmp erreichbar ist (sowie /var/tm und /dev/shm ).

Der Vorteil des Plugins ist, dass sich dieses um de Erstellung der Mounts sowie dem Löschen der Mounts und Dateien kümmert. Da die Dateien nach Ende des Jobs gelöscht werden, ist es wichtig die Ausgabe anderweitig zu "streamen" oder das Endergebnis zu kopieren.

Exemplarisch könnte ein Script für die Nutzung wie folgt aussehen:
<#!/bin/bash
#SBATCH --ntasks=1 # Run on a single CPU
#SBATCH --mem=1gb # Job memory request
#SBATCH --time=00:05:00 # Time limit hrs:min:sec
#SBATCH --partition=std
#SBATCH --account=nutzername

## set path to root of job data
basedir=/lustre/fachbereich/nutzername/myjob

## copy job data
cp -r $basedir/* /tmp
## change to working director
cd /tmp

## do the work
hostname > $basedir/result.log

## copy the results if they are required
cp -r /tmp/* $basedir

== Zugriffsrechte: ==
Typisch für ein klassisches SLURM cluster, werden die regulären UNIX Rechte und Gruppen eingesetzt. Diese ermöglichen es Ordner auf dem geteilten Laufwerk nur für bestimmte Nutzer und Gruppen freizugeben. Allerdings ist die regulären Linux Rechteverwaltung hier in Bezug auf eine detaillierte Rechteverteilung stak eingeschränkt. (Da es nicht praktisch möglich ist für alle möglichen Kombinationen dedizierte Gruppen anzulegen.)

Eine feinere Rechteverwaltung, sofern notwendig ist über Access Control Lists (ACL) möglich.

In der der aktuellen Implementierung lassen sich diese über <code>getfacl</code> in Erfahrung bringen, über <code>setfacl</code> setzen oder modifizieren.

Die access control lists werden für den jeweiligen Benutzernamen gesetzt, welcher hier die User-ID des HU-Accounts ist.

Leserechte für eine Datei liesen sich wie folgt setzen:
<code>setfacl -m u:benutzername:r test-datei</code>
Rechte lassen sich ebenfalls rekursiv setzen, wodurch alle Dateien und Ordner abgedeckt sind.
<code>setfacl -Rm u:benutzername:r pfad-zur/test-datei</code>
Weiterführende Informationen zu Access Control Lists inklusive einer Erklärung der "flags" finden sich auf der Seite des Ohio Supercomputing Centre: <nowiki>https://www.osc.edu/resources/getting_started/howto/howto_manage_access_control_list_acls/howto_use_posix_acl</nowiki>

Sollte es notwendig sein die Zugriffsrechte auf spezifische Benutzer (und nicht nur einen Fachbereich) zu begrenzen wird folgender Vorgang empfohlen:

Die regulären UNIX/POSIX-Rechte werden auf den Eigentümer reduziert, ohne Zugriffsrechte für die Gruppe oder Welt. Dies entspräche einem <code>r-x------</code> (<code>500</code>) oder <code>rwx------</code> (<code>700</code>). Das Aufzeigen von Inhalten in Ordnern erfordert hierbei die Ausführungsrechte (<code>x</code>). Für Dateien welche nicht ausgeführt werden reichen Lese- und Schreibrechte (<code>r--</code> / <code>rw-</code> ).

Im nächsten Schritt werden berechtigen Nutzern über die ACLs Zugriffsrechte eingeräumt - der Gruppe bleibt hierbei weiter der Zugriff auf der POSIX-Basis verwehrt.

Anmerkung: Sollte die Vertraulichkeit von Daten eine Einschränkung der Zugriffsrechte erfordern, sollte im Allgemeinen minimalste Rechte eingeräumt werden. So wenige wie möglich, so viele wie erforderlich. Andererseits ist ein konventionelles HPC-Cluster nicht für hochsensible Daten ausgelegt. In diesem Fall bitten wir darum dass mit dem HPC-Team unter hpc-suppport@hu-berlin.de Kontakt aufgenommen wird um eventuelle Lösungsansätze zu besprechen.

== Externer Zugriff: ==
Der Zugriff auf das Dateisystem erfolgt über sftp (ftp ûber ssh) aus dem Netz der Humboldt Universität heraus.

Die ist unter Windows mit WinScp ( <nowiki>https://winscp.net/</nowiki> ) möglich - auch in Verbindung mit putty ( <nowiki>https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html</nowiki> ) für die Befehlszeile - und wird unter Linux im Plasma Desktop nativ von Dolphin unterstützt.

Datenspeicher & Dateistruktur

2024-12-04T09:23:48Z

Mielczad: /* Lokaler Scratch */ Anpassung des Pfades

Auf dem Slurm-Cluster stehen auf jeder Maschine (Login- & Exec-Server) folgende Verzeichnisse zur Verfügung.
{| class="wikitable"
!Pfad
!Größe
!Sichtbarkeit
!Dauer
!Besonderheit
|-
|$HOME
|
|global**
|unlimited
|20GB pro Nutzer
|-
|/tmp
|1.5TB
|local (Job)
|job-time
|autotmp_fs***
|-
|/dev/shm
|128GB
|local (Job)
|job-time
|autotmp_fs***
|-
|/lustre
|1.5PB
|global
|unlimited*
|
|}
<nowiki>*</nowiki>Die Daten werden zur Zeit erst bei sehr hoher Belegung gelöscht

<nowiki>**</nowiki>Die Verzeichnisse sind über NFS gemountet

<nowiki>***</nowiki>Die Verzeichnisse werden für jeden Job angelegt und gemountet. Andere Jobs sehen den Inhalt nicht. Verzeichnisse werden nach Job-Ende gelöscht.

Bei anderen Anforderungen bitten wir darum per Mail mit dem HPC-Support Kontakt aufzunehmen.

==== Home ====
Die Home-Verzeichnisse liegen im Netzwerk der Universität. Aus diesem Grund sind die Verzeichnisse auf eine Quota von 20GB pro Nutzer beschränkt und sollten im Normalfall nicht als Arbeitsverzeichnisse bei HPC Berechnungen genutzt werden. Vom Home-Verzeichnis werden so-genannte Snapshots erstellt - effektiv ein Backup. Einmal zu jeder Stunde, zur Minute null (bis zu 168 Snapshots, 1 Woche), dann jeden Tag um 00:00 Uhr (bis zu 30 Snapshots). Diese finden sich, in jedem Ordner, innerhalb eines unsichtbaren Ordners <code>.snapshot</code>. Dieser wird allerdings nicht über <code>ls -a</code> angezeigt. Allerdings ist es möglich in den Ordner hinein zu navigieren, <code>cd .snapshot</code> oder sich die Inhalte anzeigen zu lassen <code>ls .snapshot</code>. Dadurch lassen sich für die Nutzer und Nutzerinnen des HPC-Service Daten im Home-Verzeichnis selbst wiederherstellen.

Der individuelle Pfad zum Verzeichnis lautet <code>/home/<Fakultät>/<Benutzernmae></code>

==== Lustre ====
Als temporärer Datenspeicher steht ein Lustre-Dateisystem under <code>/lustre</code> zu Verfügung, mit einer Gesamtgeröße von 1.5PB.

Nach einem erfolgreichen Verbdindungsaufbau werden automatisch Ordern mit einer Dateistsruktur ähnlich dem Home-Verzeichnis angelegt und solten im Normalfall auch so genutzt werden. Bei Gruppenübergreifender Arbeit, lohnt es sich eventuell dedizierte Ordner auf der Fakultätsebene anzulegen.

Der individuelle Pfad zulm Verzeichnis lautet <code>/lustre/<Fakultät>/<Benutzernmae></code>

==== Lokaler Scratch ====
Um die Nutzung des lokalen scratch zu unterstützen wird das Plugin "auto_tmpdir" der University of Delaware genutzt (<nowiki>https://github.com/University-of-Delaware-IT-RCI/auto_tmpdir/tree/master</nowiki>).

Dieses Plugin erstellt einen dedizierten Ordner für einen ausgeführten job welcher dann unter /tmp erreichbar ist (sowie /var/tm und /dev/shm ).

Der Vorteil des Plugins ist, dass sich dieses um de Erstellung der Mounts sowie dem Löschen der Mounts und Dateien kümmert. Da die Dateien nach Ende des Jobs gelöscht werden, ist es wichtig die Ausgabe anderweitig zu "streamen" oder das Endergebnis zu kopieren.

Exemplarisch könnte ein Script für die Nutzung wie folgt aussehen:
<#!/bin/bash
#SBATCH --ntasks=1 # Run on a single CPU
#SBATCH --mem=1gb # Job memory request
#SBATCH --time=00:05:00 # Time limit hrs:min:sec
#SBATCH --partition=std
#SBATCH --account=nutzername

## set path to root of job data
basedir=/lustre/fachbereich/nutzername/myjob

## copy job data
cp -r $basedir/* /tmp
## change to working director
cd /tmp

## do the work
hostname > $basedir/result.log

## copy the results if they are required
cp -r /tmp/* $basedir

== Zugriffsrechte: ==
Typisch für ein klassisches SLURM cluster, werden die regulären UNIX Rechte und Gruppen eingesetzt. Diese ermöglichen es Ordner auf dem geteilten Laufwerk nur für bestimmte Nutzer und Gruppen freizugeben. Allerdings ist die regulären Linux Rechteverwaltung hier in Bezug auf eine detaillierte Rechteverteilung stak eingeschränkt. (Da es nicht praktisch möglich ist für alle möglichen Kombinationen dedizierte Gruppen anzulegen.)

Eine feinere Rechteverwaltung, sofern notwendig ist über Access Control Lists (ACL) möglich.

In der der aktuellen Implementierung lassen sich diese über <code>getfacl</code> in Erfahrung bringen, über <code>setfacl</code> setzen oder modifizieren.

Die access control lists werden für den jeweiligen Benutzernamen gesetzt, welcher hier die User-ID des HU-Accounts ist.

Leserechte für eine Datei liesen sich wie folgt setzen:
<code>setfacl -m u:benutzername:r test-datei</code>
Rechte lassen sich ebenfalls rekursiv setzen, wodurch alle Dateien und Ordner abgedeckt sind.
<code>setfacl -Rm u:benutzername:r pfad-zur/test-datei</code>
Weiterführende Informationen zu Access Control Lists inklusive einer Erklärung der "flags" finden sich auf der Seite des Ohio Supercomputing Centre: <nowiki>https://www.osc.edu/resources/getting_started/howto/howto_manage_access_control_list_acls/howto_use_posix_acl</nowiki>

Sollte es notwendig sein die Zugriffsrechte auf spezifische Benutzer (und nicht nur einen Fachbereich) zu begrenzen wird folgender Vorgang empfohlen:

Die regulären UNIX/POSIX-Rechte werden auf den Eigentümer reduziert, ohne Zugriffsrechte für die Gruppe oder Welt. Dies entspräche einem <code>r-x------</code> (<code>500</code>) oder <code>rwx------</code> (<code>700</code>). Das Aufzeigen von Inhalten in Ordnern erfordert hierbei die Ausführungsrechte (<code>x</code>). Für Dateien welche nicht ausgeführt werden reichen Lese- und Schreibrechte (<code>r--</code> / <code>rw-</code> ).

Im nächsten Schritt werden berechtigen Nutzern über die ACLs Zugriffsrechte eingeräumt - der Gruppe bleibt hierbei weiter der Zugriff auf der POSIX-Basis verwehrt.

Anmerkung: Sollte die Vertraulichkeit von Daten eine Einschränkung der Zugriffsrechte erfordern, sollte im Allgemeinen minimalste Rechte eingeräumt werden. So wenige wie möglich, so viele wie erforderlich. Andererseits ist ein konventionelles HPC-Cluster nicht für hochsensible Daten ausgelegt. In diesem Fall bitten wir darum dass mit dem HPC-Team unter hpc-suppport@hu-berlin.de Kontakt aufgenommen wird um eventuelle Lösungsansätze zu besprechen.

== Externer Zugriff: ==
Der Zugriff auf das Dateisystem erfolgt über sftp (ftp ûber ssh) aus dem Netz der Humboldt Universität heraus.

Die ist unter Windows mit WinScp ( <nowiki>https://winscp.net/</nowiki> ) möglich - auch in Verbindung mit putty ( <nowiki>https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html</nowiki> ) für die Befehlszeile - und wird unter Linux im Plasma Desktop nativ von Dolphin unterstützt.

Modules & Verfügbare Software

2024-11-20T11:34:23Z

Mielczad: Hinzufügen von Gaussian

==== Übersicht & Grundlagen zur Nuzung ====
Die bereitgestellten Compute-Knoten nutzen Linux, genaugenommen ein OpenSUSE.

HPC-typisch wird zentral Software bereitgestellt. Verfügbare Software wird über eine Modulumgebung geladen.

Welche Software verfügbar ist, lässt sich über <code>module avail</code> sowie <code>module spider <name></code> in Erfahrung bringen.

(Online Anleitung für lmod https://lmod.readthedocs.io/en/latest/010_user.html )

Wir bieten aktuell drei Gruppe von Software an:

# /hu "Von Uns" kompilierte Software welche zentral bereitgestellt wird.
# /all Über EasyBuild ( siehe http://docs.easybuild.io/what-is-easybuild/ ) bereitgestellte Software
# /intel Software welche mit Installer ausgeliefert wurde (wie zum Beispiel Intel OneAPI)

Bei der Auswahl von Software sollte darauf geachtet werden dass die Groß- und Kleinschreibung von Bedeutung ist, sprich gcc ist nicht gleich GCC.

Die finalen Pfade sind aktuell auch nicht endgültig festgelegt und können sich noch verändern.

Ferner wird empfohlen sich nicht auf die Defaults zu verlassen und die Version einer Software explizit auszuwählen.

Anwendungsbeispiel:

Die verfügbaren openmpi Versionen lassen sich mit dem Befehl
module spider openmpi
erfragen

Ist daraufhin die Version erwünscht, lässt sich diese mit dem Befehl
module load openmpi/5.0.3-gcc14.1.0
laden.

Aktuell geladene Module lassen sich mit
module list
anzeigen, während
module purge
alle geladenen Module "entlädt".

Aktuell wird die verfügbare Software noch ausgebaut, wodurch sich die Liste relativ schnell entwickelt. Für einen Überblick der aktuell verfügbaren Software wird gebeten diese direkt auf dem System abzufragen. Vor allem mit EasyBuild installierte Software bringt standardmäßig sehr viele kleine Abhängigkeiten mit.

Einen ersten Überblick über einige der wichtigeren Pakete (als Eigenkompilation) bietet die folgende Liste:

==== Verfügbare Software ====

===== Programmiersprachen und Compiler =====
- AMD aocc

- 4.2.0

- gcc

- 9.5.0

- 10.5.0

- 11.4.0

- 12.3.0

- 13.2.0

- 14.1.0

- 14.2.0

- Intel OneApi

- 2024.1

- Julia

- 1.10.3

- python

- 3.8.19

- 3.9.19

- 3.10.14

- 3.11.9

- 3.12.3

- QT (opensource)

- 5.15.14

- R

- 4.4.0

- ruby

- 3.3

===== Bibliotheken und Tools =====
- AMD AOCL

- 4.2.0 gcc

- 4.2.0 aocl

- apache-maven

- 3.9.8

- bash

- 5.2.21

- bc

- 1.0.7

- bison

- 3.8.2

- BLIS

- 4.2.0

- block2

- p0.5.3rc13 openmpi/5.0.3 gcc/14.1.0 OpenBLAS/0.3.26

- boost

- 1.85 gcc/13.2.0

- 1.85 gcc/14.1.0

- Catch2

- 3.6.0 cmake/3.29.3

- cmake

- 3.16.9

- 3.20.6

- 3.27.2

- 3.29.2

- 3.29.3

- coreutils

- 9.5

- costa

2.2.2

- cuda

- 10

- 11

- 12.0

- 12

- 12.1

- 12.2

- 12.3

- 12.4

- 12.4.1

- crest

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc13.2.0 openmpi/5.0.3-gcc13.2.0 gcc/13.2.0

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc14.1.0 openmpi/5.0.3-gcc14.1.0 gcc/14.1.0

fftw

- 3.3.0 gcc/14.1.0

- 3.3.0 openmpi/5.0.3 gcc/14.1.0

- flex

- 2.6.4

- fmt

- 10.2.1

- gsl

- 2.8

- hdf5

- 1.14.4.3

- lapack

- 3.12.0 gcc/13.2.0

- 3.12.0 gcc/14.1.0

- libaec

- 1.1.3

- libflame

- 4.2.0

- libunwind

- 1.8.1

- libxc

- 6.6.2

- magma

- 2.8.8

- mpich

- 3.2.0 gcc/12.3.0

- 3.3.0 gcc/12.3.0

- 4.1.3 gcc/12.3.0

- 4.2.1 gcc/14.1.0

- OpenBLAS

- 0.3.26 gcc/13.2.0

- 0.3.26 gcc/14.1.0

- OpenCoarrays

- 2.9.3 mpich/3.3.0 gcc/12.3.0

- 2.10.2 openmpi/5.0.3 gcc/14.1.0

- OpenMPI

- 4.1.6 gcc/13.2.0

- 5.0.3 gcc/13.2.0

- 5.0.3 gcc/14.1.0

- 5.0.5 gcc/14.2.0

- patch

- 2.7.6

- proj

- 9.4.1 gcc/14.1.0

- scalapack

- 2.2.0

- spglib

- 2.4.0 gcc/14.1.0

- sirius

- 7.5.2

- spla

- 1.6.1

- swig

- 4.2.1

- szip

- 2.1.1

- umpire

- 2024.02.01

===== Software =====
- Gaussian 16

- A.03

- GaussView

- 6.0.16

- gdal

- 3.9.0 gcc/14.1.0 proj/9.4.1 swig/4.2.1 python/3.12.3

- hadoopp

- 3.4.0

- hpl

- v2.3

- ior

- 4.0.0 openmpi/5.0.3 gcc/14.1.0

- ncdu

- 1.20

- OpenFOAM

- 11

- v2312

- ORCA

- 5.0.4

- quantum-espresso

- 7.3.1 OpenBLAS/0.3.26 fftw/3.3.10 penmpi/5.0.3 gcc/14.1.0

- xtb

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/13.2.0

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/14.1.0

===== Fehlt was? =====
Da es sich beim HPC um ein Linux System handelt, ist es möglich eigene Software zu entwickeln. Die Einbindung von Software findet überwiegend über zwei grundlegende Variablen statt. <code>PATH</code> für ausführbare Binärdateien sowie <code>LD_LIBRARY_PATH</code> für verlinkte Bibliotheken.

Über ein <code>export PATH=/new/path:$PATH</code> sowie <code>export LD_LIBRARY_PATH=/new/path:$LD_LIBRARY_PATH</code> lassen sich beide erweitern. Diese Änderung gilt bis zum verlassen der Shell - oder ist "semi-permanent" wenn der Export in die .profile oder .bashrc Datei eingetragen wird.

Hierbei gilt es ferner zu beachten dass die Reihenfolge der Auflistung der verschiedenen Pfade von Bedeutung ist: die zuerst gefundene Variante wird genommen.

Obschon es möglich ist eine Software zu kompilieren, bitten wir darum bei fehlender freier Software nach Möglichkeit zuerst eine Anfrage an [mailto:hpc-support@hu-berlin.de hpc-support@hu-berlin.de] zu schicken, damit diese zentral für Alle zugänglich ist.

Bei Anfragen zu kommerzieller Software, internen Eigenentwicklungen oder anderweitig speziell lizenzierter Software stehen wir ebenfalls gerne zu Verfügung.

==== Python, Anaconda, Conda, Mamba ====

===== Python =====
Python wird in vielen Projekten eingesetzt. Die Nutzung von Python ist nicht immer problemfrei, darum gibt es folgend einige Empfehlungen für die Nutzung von Python, welche das Risiko von Problemen sowie die Problembeseitigung erleichtern.

Im Allgemeinen sollten Python Anwendungen in einer virtuellen Umgebung entwickelt und ausgeführt werden. Diese wird nativ von Python unterstützt und ermöglicht es Pakete auf einer bestimmten Version zu halten sowie eventuelle Inkompatibilitäten zwischen verschiedenen Projekten zu vermeiden. Ferner ist es möglich bei Problemen eine virtuelle Umgebung zu löschen und dadurch alte Pakete Rückstandslos zu entfernen. Das ist vor allem interessant da pip oder pip3 Abhängigkeiten installieren kann, aber im Gegensatz zu typischen Linux-Paketmanagern Abhängigkeiten nicht automatisch deinstallieren kann.

Eine virtuelle Umgebung kann wie folgt erstellt werden (mit einem relativen oder absoluten Pfad):
<code>python -m venv /Pfad/zur/neuen/virtuellen_Umgebung</code>
Mehr dazu auf in der Dokumentation von Python: <nowiki>https://docs.python.org/3/library/venv.html</nowiki>

Sollte es aus bestimmten Gründen nicht möglich sein eine virtuelle Umgebung zu nutzen, kann man mit pip Pakete in einem bestimmten Ordner installieren.
<code>pip3 install --target /Pfad/zum/ZielOrdner</code>
Danach kann der Ordner zur Variable PYTHONPATH hinzugefügt werden und wird dann von der Python-Umgebung erkannt.

Die virtuellen Umgebungen sind im Allgemeinen jedoch zu präferieren.

===== Anaconda, Conda, Mamba =====
Eine weitere Alternative ist die Nutzung einer Packetverwaltung in Python, so wie diese über Anaconda/conda/mamba angeboten wird, bei dieser ist der Funktionsumfang dann auch größer als be pip.

Hierbei werden Nutzer und Nutzerinnen angehalten die Nutzungsbedingungen von vor allem Anaconda und Miniconda zu beachten. Aktuell (Juli 2024) wird Miniforge unter der BSD Lizenz angeboten und ist in in Bezug auf die Nutzung.

Während eine zentrale Installation von conda und mamba über miniforge3 bereitgestellt wird, haben normale Nutzer keine Schreibrechte in dem zentralen Installationsordner. Standardmäßig wird conda/mamba daraufhin versuchen einen Ordner im Home-Verzeichnis anzulegen, alternativ kann ein expliziter Prefix wie folgt angegeben werden.
<code>conda create --prefix /Pfad/zur/neuen/conda_Umgebung</code>
Für typische Nutzertools wird darum empfohlen eine eigene Installation von miniforge aufzusetzen und eigene Umgebungen zu verwalten. Bei der Einrichtung muss dann nur darauf geachtet werden dass der Installationspfad korrekt eingegeben wird. Da eine solche Installation mit der Zeit recht groß werden kann, wird empfohlen dass lustre Dateisystem zu nutzen, der Pfad würde dementsprechend <code>/lustre/<Fakultät>/<Benutzername></code> lauten.

Mit <code>conda init</code> oder <code>mamba init</code> wird die Umgebung initiialisiert und die .bashrc Datei angepasst. Dabei werden eventuell existierende conda/mamba Konfigurationen überschrieben (!!!). Dies ist beim benutzen von mehreren Versionen potenziell problematisch und erfordert eine manuelle Anpassung der Skripte sowie potenziell deren Auslagerung in individuelle Dateien.

==== Persönliche Module ====
Es ist möglich eigene Module in <code>lmod</code> einzubinden, wie in der Dokumentation beschrieben: <nowiki>https://lmod.readthedocs.io/en/latest/020_advanced.html</nowiki>

Eine Môglichkeit besteht in dem Befehl <code>module use /path/to/personal/modulefiles</code>, alternativ kann der Pfad zu privaten Moduldateien auch gleich zur Variable <code>$MODULEPATH</code> hinzugefügt werden.

Informationen bezüglich des Aufbaus der Moduldateien finden sich in der lmod-Dokumentation auf der Webseite. Ebenso können die bereitgestellten Module unter <code>/software/modules</code> als Inspiration dienen.

==== Für Nutzer: ====
Für Nutzer von HPC@HU finden sich unter <code>/software/modules/software.md</code> weitere Informationen über die verfügbare Software und wie diese gebaut/konfiguriert wurde.

Modules & Verfügbare Software

2024-10-31T09:39:40Z

Mielczad: /* Programmiersprachen und Compiler */

==== Übersicht & Grundlagen zur Nuzung ====
Die bereitgestellten Compute-Knoten nutzen Linux, genaugenommen ein OpenSUSE.

HPC-typisch wird zentral Software bereitgestellt. Verfügbare Software wird über eine Modulumgebung geladen.

Welche Software verfügbar ist, lässt sich über <code>module avail</code> sowie <code>module spider <name></code> in Erfahrung bringen.

(Online Anleitung für lmod https://lmod.readthedocs.io/en/latest/010_user.html )

Wir bieten aktuell drei Gruppe von Software an:

# /hu "Von Uns" kompilierte Software welche zentral bereitgestellt wird.
# /all Über EasyBuild ( siehe http://docs.easybuild.io/what-is-easybuild/ ) bereitgestellte Software
# /intel Software welche mit Installer ausgeliefert wurde (wie zum Beispiel Intel OneAPI)

Bei der Auswahl von Software sollte darauf geachtet werden dass die Groß- und Kleinschreibung von Bedeutung ist, sprich gcc ist nicht gleich GCC.

Die finalen Pfade sind aktuell auch nicht endgültig festgelegt und können sich noch verändern.

Ferner wird empfohlen sich nicht auf die Defaults zu verlassen und die Version einer Software explizit auszuwählen.

Anwendungsbeispiel:

Die verfügbaren openmpi Versionen lassen sich mit dem Befehl
module spider openmpi
erfragen

Ist daraufhin die Version erwünscht, lässt sich diese mit dem Befehl
module load openmpi/5.0.3-gcc14.1.0
laden.

Aktuell geladene Module lassen sich mit
module list
anzeigen, während
module purge
alle geladenen Module "entlädt".

Aktuell wird die verfügbare Software noch ausgebaut, wodurch sich die Liste relativ schnell entwickelt. Für einen Überblick der aktuell verfügbaren Software wird gebeten diese direkt auf dem System abzufragen. Vor allem mit EasyBuild installierte Software bringt standardmäßig sehr viele kleine Abhängigkeiten mit.

Einen ersten Überblick über einige der wichtigeren Pakete (als Eigenkompilation) bietet die folgende Liste:

==== Verfügbare Software ====

===== Programmiersprachen und Compiler =====
- AMD aocc

- 4.2.0

- gcc

- 9.5.0

- 10.5.0

- 11.4.0

- 12.3.0

- 13.2.0

- 14.1.0

- 14.2.0

- Intel OneApi

- 2024.1

- Julia

- 1.10.3

- python

- 3.8.19

- 3.9.19

- 3.10.14

- 3.11.9

- 3.12.3

- QT (opensource)

- 5.15.14

- R

- 4.4.0

- ruby

- 3.3

===== Bibliotheken und Tools =====
- AMD AOCL

- 4.2.0 gcc

- 4.2.0 aocl

- apache-maven

- 3.9.8

- bash

- 5.2.21

- bc

- 1.0.7

- bison

- 3.8.2

- BLIS

- 4.2.0

- block2

- p0.5.3rc13 openmpi/5.0.3 gcc/14.1.0 OpenBLAS/0.3.26

- boost

- 1.85 gcc/13.2.0

- 1.85 gcc/14.1.0

- Catch2

- 3.6.0 cmake/3.29.3

- cmake

- 3.16.9

- 3.20.6

- 3.27.2

- 3.29.2

- 3.29.3

- coreutils

- 9.5

- costa

2.2.2

- cuda

- 10

- 11

- 12.0

- 12

- 12.1

- 12.2

- 12.3

- 12.4

- 12.4.1

- crest

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc13.2.0 openmpi/5.0.3-gcc13.2.0 gcc/13.2.0

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc14.1.0 openmpi/5.0.3-gcc14.1.0 gcc/14.1.0

fftw

- 3.3.0 gcc/14.1.0

- 3.3.0 openmpi/5.0.3 gcc/14.1.0

- flex

- 2.6.4

- fmt

- 10.2.1

- gsl

- 2.8

- hdf5

- 1.14.4.3

- lapack

- 3.12.0 gcc/13.2.0

- 3.12.0 gcc/14.1.0

- libaec

- 1.1.3

- libflame

- 4.2.0

- libunwind

- 1.8.1

- libxc

- 6.6.2

- magma

- 2.8.8

- mpich

- 3.2.0 gcc/12.3.0

- 3.3.0 gcc/12.3.0

- 4.1.3 gcc/12.3.0

- 4.2.1 gcc/14.1.0

- OpenBLAS

- 0.3.26 gcc/13.2.0

- 0.3.26 gcc/14.1.0

- OpenCoarrays

- 2.9.3 mpich/3.3.0 gcc/12.3.0

- 2.10.2 openmpi/5.0.3 gcc/14.1.0

- OpenMPI

- 4.1.6 gcc/13.2.0

- 5.0.3 gcc/13.2.0

- 5.0.3 gcc/14.1.0

- 5.0.5 gcc/14.2.0

- patch

- 2.7.6

- proj

- 9.4.1 gcc/14.1.0

- scalapack

- 2.2.0

- spglib

- 2.4.0 gcc/14.1.0

- sirius

- 7.5.2

- spla

- 1.6.1

- swig

- 4.2.1

- szip

- 2.1.1

- umpire

- 2024.02.01

===== Software =====
- gdal

- 3.9.0 gcc/14.1.0 proj/9.4.1 swig/4.2.1 python/3.12.3

- hadoopp

- 3.4.0

- hpl

- v2.3

- ior

- 4.0.0 openmpi/5.0.3 gcc/14.1.0

- ncdu

- 1.20

- OpenFOAM

- 11

- v2312

- ORCA

- 5.0.4

- quantum-espresso

- 7.3.1 OpenBLAS/0.3.26 fftw/3.3.10 penmpi/5.0.3 gcc/14.1.0

- xtb

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/13.2.0

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/14.1.0

===== Fehlt was? =====
Da es sich beim HPC um ein Linux System handelt, ist es möglich eigene Software zu entwickeln. Die Einbindung von Software findet überwiegend über zwei grundlegende Variablen statt. <code>PATH</code> für ausführbare Binärdateien sowie <code>LD_LIBRARY_PATH</code> für verlinkte Bibliotheken.

Über ein <code>export PATH=/new/path:$PATH</code> sowie <code>export LD_LIBRARY_PATH=/new/path:$LD_LIBRARY_PATH</code> lassen sich beide erweitern. Diese Änderung gilt bis zum verlassen der Shell - oder ist "semi-permanent" wenn der Export in die .profile oder .bashrc Datei eingetragen wird.

Hierbei gilt es ferner zu beachten dass die Reihenfolge der Auflistung der verschiedenen Pfade von Bedeutung ist: die zuerst gefundene Variante wird genommen.

Obschon es möglich ist eine Software zu kompilieren, bitten wir darum bei fehlender freier Software nach Möglichkeit zuerst eine Anfrage an [mailto:hpc-support@hu-berlin.de hpc-support@hu-berlin.de] zu schicken, damit diese zentral für Alle zugänglich ist.

Bei Anfragen zu kommerzieller Software, internen Eigenentwicklungen oder anderweitig speziell lizenzierter Software stehen wir ebenfalls gerne zu Verfügung.

==== Python, Anaconda, Conda, Mamba ====

===== Python =====
Python wird in vielen Projekten eingesetzt. Die Nutzung von Python ist nicht immer problemfrei, darum gibt es folgend einige Empfehlungen für die Nutzung von Python, welche das Risiko von Problemen sowie die Problembeseitigung erleichtern.

Im Allgemeinen sollten Python Anwendungen in einer virtuellen Umgebung entwickelt und ausgeführt werden. Diese wird nativ von Python unterstützt und ermöglicht es Pakete auf einer bestimmten Version zu halten sowie eventuelle Inkompatibilitäten zwischen verschiedenen Projekten zu vermeiden. Ferner ist es möglich bei Problemen eine virtuelle Umgebung zu löschen und dadurch alte Pakete Rückstandslos zu entfernen. Das ist vor allem interessant da pip oder pip3 Abhängigkeiten installieren kann, aber im Gegensatz zu typischen Linux-Paketmanagern Abhängigkeiten nicht automatisch deinstallieren kann.

Eine virtuelle Umgebung kann wie folgt erstellt werden (mit einem relativen oder absoluten Pfad):
<code>python -m venv /Pfad/zur/neuen/virtuellen_Umgebung</code>
Mehr dazu auf in der Dokumentation von Python: <nowiki>https://docs.python.org/3/library/venv.html</nowiki>

Sollte es aus bestimmten Gründen nicht möglich sein eine virtuelle Umgebung zu nutzen, kann man mit pip Pakete in einem bestimmten Ordner installieren.
<code>pip3 install --target /Pfad/zum/ZielOrdner</code>
Danach kann der Ordner zur Variable PYTHONPATH hinzugefügt werden und wird dann von der Python-Umgebung erkannt.

Die virtuellen Umgebungen sind im Allgemeinen jedoch zu präferieren.

===== Anaconda, Conda, Mamba =====
Eine weitere Alternative ist die Nutzung einer Packetverwaltung in Python, so wie diese über Anaconda/conda/mamba angeboten wird, bei dieser ist der Funktionsumfang dann auch größer als be pip.

Hierbei werden Nutzer und Nutzerinnen angehalten die Nutzungsbedingungen von vor allem Anaconda und Miniconda zu beachten. Aktuell (Juli 2024) wird Miniforge unter der BSD Lizenz angeboten und ist in in Bezug auf die Nutzung.

Während eine zentrale Installation von conda und mamba über miniforge3 bereitgestellt wird, haben normale Nutzer keine Schreibrechte in dem zentralen Installationsordner. Standardmäßig wird conda/mamba daraufhin versuchen einen Ordner im Home-Verzeichnis anzulegen, alternativ kann ein expliziter Prefix wie folgt angegeben werden.
<code>conda create --prefix /Pfad/zur/neuen/conda_Umgebung</code>
Für typische Nutzertools wird darum empfohlen eine eigene Installation von miniforge aufzusetzen und eigene Umgebungen zu verwalten. Bei der Einrichtung muss dann nur darauf geachtet werden dass der Installationspfad korrekt eingegeben wird. Da eine solche Installation mit der Zeit recht groß werden kann, wird empfohlen dass lustre Dateisystem zu nutzen, der Pfad würde dementsprechend <code>/lustre/<Fakultät>/<Benutzername></code> lauten.

Mit <code>conda init</code> oder <code>mamba init</code> wird die Umgebung initiialisiert und die .bashrc Datei angepasst. Dabei werden eventuell existierende conda/mamba Konfigurationen überschrieben (!!!). Dies ist beim benutzen von mehreren Versionen potenziell problematisch und erfordert eine manuelle Anpassung der Skripte sowie potenziell deren Auslagerung in individuelle Dateien.

==== Persönliche Module ====
Es ist möglich eigene Module in <code>lmod</code> einzubinden, wie in der Dokumentation beschrieben: <nowiki>https://lmod.readthedocs.io/en/latest/020_advanced.html</nowiki>

Eine Môglichkeit besteht in dem Befehl <code>module use /path/to/personal/modulefiles</code>, alternativ kann der Pfad zu privaten Moduldateien auch gleich zur Variable <code>$MODULEPATH</code> hinzugefügt werden.

Informationen bezüglich des Aufbaus der Moduldateien finden sich in der lmod-Dokumentation auf der Webseite. Ebenso können die bereitgestellten Module unter <code>/software/modules</code> als Inspiration dienen.

==== Für Nutzer: ====
Für Nutzer von HPC@HU finden sich unter <code>/software/modules/software.md</code> weitere Informationen über die verfügbare Software und wie diese gebaut/konfiguriert wurde.

FAQ

2024-10-28T12:49:17Z

Mielczad: /* OpenMP mit OpenMPI */

Das zukünftige FAQ - welches sich, folgend der Erfahrung mit Nutzeranfragen, im Aufbau befindet:

== Wie fordere Ich Software an ==
Dem Nutzer werden eine ganze Reihe von Bibliotheken sowie Software über die Modules-Umgebung zu Verfügung gestellt. Diese werden unter [[Modules & Verfûgbare Software]] vorgestellt.

Sollte eine erwünschte Software oder Bibliothek fehlen, können wir diese (je nach Lizenzbedingungen) nach einer Anfrage zu Verfügung stellen. Dies ist im großen und ganzen über eine formlose Email an hpc-support@hu-berlin.de möglich.

Hierbei sind Links zu der Software hilfreich, sowie eventuell vorhandene Test-Jobs mit denen sich die Funktionalität testen lässt, inklusive der nötigen Befehle um die Software auszuführen.

== Wie melde Ich ein Softwareproblem ==
In den meisten Fällen werden Software und Bibliotheken mit Standardeinstellungen kompiliert und bereitgestellt. Dies ist häufig ausreichend.

Manchmal ist es allerdings notwendig bestimmte Argumente oder "Flags" zu setzen, zum Beispiel um zum Beispiel CUDA-Support zu aktivieren. In solch einem Fall würde das Ausführen einer Bibliothek ohne CUDA-Support mit CUDA zu einem Fehler führen. (CUDA wird hier nur beispielhaft genutzt.)

Sollte ein Fehler auftreten, sollte dieser möglichst vollumfänglich kopiert werde. Ferner sind die Eingaben von Interesse: wie wurde eine Software/Bibliothek genutzt, welche ist es, welche Argumente wurden genutzt. Idealerweise sollte auch eine Testdatei zu Verfügung gestellt werden damit das Problem nachvolzogen und reproduziert werden kann. Hierbei sollte die Testdatei idealerweise schnell das Problem aufzeigen können, das bekannte "minimum working example".

Dies kann dann über eine formlose Email an hpc-support@hu-berlin.de geschickt werden.

== OpenMP mit OpenMPI ==
Grundsätzlich soll die Nutzung von OpenMP in Kombination mit OpenMPI Môglich sein. Dadurch lassen sich das geringere "Overhead" von "Shared Memory Processing" (Threading) mit der Skalierung des MPI-Multi-Process-Asatz kombinieren.

In einem uns bekannten Fall gab es Probleme bei der Verwaltung der Threads in einem OpenSource Fortran-Programm.

Sollten unerwartet Probleme auftreten, sind folgenden Variablen/Parameter zu überprüfen:

Die Variable<code>OMP_NUM_THREADS</code> welche die Anzahl der OpenMP-Threads festlegt sollte exportiert werden, sowie die Option <code>--bind-to none</code> beim Aufruf mit OpenMPI genutzt werden.

Ein Aufruf in einem Script sähe dann für 4 Threads und zwei Prozesse wie folgt aus:
export OMP_NUM_THREADS=4
mpirun --bind-to none -np 2 meine_Software

== Zeilenterminierung ==
Wenn Textdateien unter Windows erstellt werden, kann dies mitunter in einigen Fällen unter Linux zu einem Problem führen.

Textdateien unter unter Windows werden mit <code>\r\n</code> terminiert, "return carriage" (<code>\r</code>) "neline" (<code>\n</code>), wḧarend Textdateien unter Linux nur mit einem <code>\n</code>, "newline" terminiert werden. Dies kann dann zu teilweise unverständlichen Fehlermeldungen führen. Unter Windows wird darum die Nutzung von Notepad++ ( <nowiki>https://notepad-plus-plus.org/downloads</nowiki> ) empfohlen, da in diesem Editor die Zeilenterminierung eingestellt werden kann und diese auch in der Statusleiste angezeigt wird. Alternativ können Textdateien auch über das Tool <code>dos2unix</code> konvertiert werden, dieses steht auf den Login-Knoten zu Verfügung.

FAQ

2024-10-28T12:48:43Z

Mielczad: /* OpenMP mit OpenMPI */

Das zukünftige FAQ - welches sich, folgend der Erfahrung mit Nutzeranfragen, im Aufbau befindet:

== Wie fordere Ich Software an ==
Dem Nutzer werden eine ganze Reihe von Bibliotheken sowie Software über die Modules-Umgebung zu Verfügung gestellt. Diese werden unter [[Modules & Verfûgbare Software]] vorgestellt.

Sollte eine erwünschte Software oder Bibliothek fehlen, können wir diese (je nach Lizenzbedingungen) nach einer Anfrage zu Verfügung stellen. Dies ist im großen und ganzen über eine formlose Email an hpc-support@hu-berlin.de möglich.

Hierbei sind Links zu der Software hilfreich, sowie eventuell vorhandene Test-Jobs mit denen sich die Funktionalität testen lässt, inklusive der nötigen Befehle um die Software auszuführen.

== Wie melde Ich ein Softwareproblem ==
In den meisten Fällen werden Software und Bibliotheken mit Standardeinstellungen kompiliert und bereitgestellt. Dies ist häufig ausreichend.

Manchmal ist es allerdings notwendig bestimmte Argumente oder "Flags" zu setzen, zum Beispiel um zum Beispiel CUDA-Support zu aktivieren. In solch einem Fall würde das Ausführen einer Bibliothek ohne CUDA-Support mit CUDA zu einem Fehler führen. (CUDA wird hier nur beispielhaft genutzt.)

Sollte ein Fehler auftreten, sollte dieser möglichst vollumfänglich kopiert werde. Ferner sind die Eingaben von Interesse: wie wurde eine Software/Bibliothek genutzt, welche ist es, welche Argumente wurden genutzt. Idealerweise sollte auch eine Testdatei zu Verfügung gestellt werden damit das Problem nachvolzogen und reproduziert werden kann. Hierbei sollte die Testdatei idealerweise schnell das Problem aufzeigen können, das beaknnte "minimum working example".

Dies kann dann über eine formlose Email an hpc-support@hu-berlin.de geschickt werden.

== OpenMP mit OpenMPI ==
Grundsätzlich soll die Nutzung von OpenMP in Kombination mit OpenMPI Môglich sein. Dadurch lassen sich das geringere "Overheaded" von "Shared Memory Processing" (Threading) mit der Skallierung des MPI-Multi-Process-Asatz kombinieren.

In einem uns bekannten Fall gab es Probleme bei der Verwaltung der Threads in einem OpenSource Fortran-Programm.

Sollten unerwartet Probleme auftreten, sind folgenden Variablen/Parameter zu überprüfen:

Die Variable<code>OMP_NUM_THREADS</code> welche die Anzahl der OpenMP-Threads festlegt sollte exportiert werden, sowie die Option <code>--bind-to none</code> beim Aufruf mit OpenMPI genutzt werden.

Ein Aufruf in einem Script sähe dann für 4 Threads und zwei Prozesse wie folgt aus:
export OMP_NUM_THREADS=4
mpirun --bind-to none -np 2 meine_Software

== Zeilenterminierung ==
Wenn Textdateien unter Windows erstellt werden, kann dies mitunter in einigen Fällen unter Linux zu einem Problem führen.

Textdateien unter unter Windows werden mit <code>\r\n</code> terminiert, "return carriage" (<code>\r</code>) "neline" (<code>\n</code>), wḧarend Textdateien unter Linux nur mit einem <code>\n</code>, "newline" terminiert werden. Dies kann dann zu teilweise unverständlichen Fehlermeldungen führen. Unter Windows wird darum die Nutzung von Notepad++ ( <nowiki>https://notepad-plus-plus.org/downloads</nowiki> ) empfohlen, da in diesem Editor die Zeilenterminierung eingestellt werden kann und diese auch in der Statusleiste angezeigt wird. Alternativ können Textdateien auch über das Tool <code>dos2unix</code> konvertiert werden, dieses steht auf den Login-Knoten zu Verfügung.

Containerisierung

2024-10-15T07:04:04Z

Mielczad: Erweiterung der Beschreibung um Containerisierung

Während im HPC-Bereich Software traditionnel direkt auf den Compute-Nodes ausgeführt wird, hat sich in den letzten Jahren auch die Nutzung eine Containerumgebung für bestimmte Anwendungsfâlle etabliert. Ein bekanntes Problem auf Compute-Clustern ist der Bedarf an einer neuerern glibc-Standardbibliothek welche durch Ihre tiefe Verwurzelung in Linux nicht ohne Weiteres angeboten werden kann. Die Containeriesrung kann es ermöglichen Software auszuführen welche sonst nicht gebaut werden kann oder nicht lauffähig ist.

Docker als bekannteste Conainerisierung ist hierbei im HPC aufgrund der Root-Rechte auf einem von Nutzern geteilten HPC Cluster problematisch. Darum wurde eine Containerisierung am Lawrence Berkeley National Laboratory Entwickelt welche nur im Userspace läuft, heute unter dem Namen Apptainer bekannt ( <nowiki>https://apptainer.org/</nowiki> ) - diese bieten wir den Nutzern auf unseren Ressourcen an. (Anmerkung: das Projekt startete ursprünglich unter dem Namen Singularity, Apptainer ist mit Singularity. SingularityCE its ein alternativer Fork.)

Container für Apptainer können in Apptainer selbst gebaut werden, oder aber auch in Docker und dann konvertiert werden. Wer sich Container über die Docker-Route selbst bauen möchte, benötigt hierfür seinen eigenen Computer. Alternativ kann Apptainer auch Images direkt vom Docker-Hub herunterladen sofern ein Image zu VerFûgung steht.

Wichtig is hierbei dass die Umgebungsvariable <code>APPTAINER_CACHEDIR</code> zum Einstellen des Cache-Ordners so gewählt wird, dass sich dieses auf dem Lustre-Dateisystem befindet. Zum Bespiel wie folgt:
<code>export APPTAINER_CACHEDIR=/lustre/department/username/apptainer</code>

=== Ein Minimales openSUSE 15.6 als glibc Overlay ===
Bei einem unserer Nutzer befindet sich ein minimales openSUSE 15.6 als Overlay im Testbetrieb um eine neuere glibc anzubieten.

Dazu wird ein Docker-Container mit openSUSE Leap 15.6 aufgesetzt, in welchem zusätlzich noch lua-lmod installiert wird. Letzteres wird benötigt um die Modules-Umgebung zu unterstützen. Wichtige Anmerkung, damit zypper korrekt funktioniert, benötigt es ein "clean" sowie "refresh". Dies ist mit dem folgenden Dockerfile möglich:
# syntax=docker/dockerfile:1

# use Leap as a basis to reduce differences
FROM opensuse/leap:15.6

RUN zypper clean --all
RUN zypper ref

# the container needs to bring its own lmod along
RUN zypper -n install lua-lmod

RUN bash
Danach kann der Container mit <code>docker build . -t opensuse-15.6</code> gebaut werden.

Ist der Docker-Container lokal aufgesetzt, kann dieser in eine Apptainer sif-Datei umgewandelt werden, und zwar wie folg:
<code>apptainer build opensuse-15.6.sif docker-daemon://opensuse-15.6:latest</code>
Hier ist es wichtig entweder den Tag (fals vorhanden) oder <code>:latest</code> anzugeben, sonst wird die Datei nicht erstellt.

Beim bauen des Container, wird <code>/tmp</code> im RAM gemounted. Sollte der Container etwas größer sein, ist es möglich dass der vorhanden Platz nicht ausreicht, und das Bauen eines Apptainer-Containers dadurch fehlschlägt. In diesem Fall kann ein expliziter Pfad für <code>/tmp</code> über eine Umgebungsvariable gesetzt werden. Danach ist man nicht auf den verfügbaren oder zugewiesenen RAM beschränkt.

Dies sähe dann wie folgt aus:
<code>APPTAINER_TMPDIR="/tmp" apptainer build opensuse-15.6.sif docker-daemon://opensuse-15.6:latest</code>
Die nun erstellte Datei ist der Container welcher sich nun in einer HPC-Umgebung - mit Nutzerrechtne - verwenden lässt. In einer interaktiven Session würde der Container mit <code>apptainer run opensuse-15.6.sif</code> ausgeführt. Dies ist an sich zuerst nicht besonders nützlich da nur das Home-Verzeichnis benutzbar ist. Allerdings können weitere Verzeichnisse über <code>--bind</code> eingebunden werden, wodurch sich im Container die gleichen Pfade wie außerhalb nutzen lassen. Das wäre hier:
<code>apptainer run --bind /lustre,/software opensuse-15.6.sif</code>
Allerdings kann der Container dabei im Zweifelsfall nicht auf systemseitig angebotene Software oder Bibliotheken zugreifen. Diese lassen sich über einen Workaround ebenfalls einbinden. Der Pfad wird umgeschrieben und über die Umgebungsvariablen eingespielt. Hierbei ist es wichtig dass der Pfad zu der Systemsoftware ans Ende gehängt wird, denn die Pfade innerhalb des Containers sollen privilegiert werden.

Zum Beispiel liese sich der Container wie folgt starten:
<code>apptainer run --bind /bin:/bin_base,/usr:/usr_base,/lustre,/software opensuse-15.6.sif</code>
Und danach könne die Umgebungsvariablen mit den folgenden Befehelen gesetzt werden:
## add the base software back in via path:
export PATH=$PATH:/usr_base/local/bin:/usr_base/bin:/bin_base
## ensure base OS libraries are included
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr_base/lib:/usr_base/lib64
Dies geht so natürlich nur in einer interaktiven Session.

Soll ein Job über SLURM eingereicht werden, so muss dies automatisch geschehen. Dazu kannn <code>apptainer exec</code> genutzt werden. Es wird ein Bash-Script geschrieben welcher die Umgebungsvariablen exportiert (zum erweitern der Pfade) und benötigte Module lädt und dann eventuellen Code ausführt. Das Script muss hierbei ausführbar sein, woraus sich ein Aufruf wie folgt ergibt: <code>apptainer exec --bind /bin:/bin_base,/usr:/usr_base,/lustre,/software opensuse-15.6.sif executable_script.sh</code>

Ein minimaler Container mit openSUSE 15.6 ist unter <code>/software/containers/opensuse-15.6.sif</code> verfügbar.

=== Bereitgestellte Container ===
Manche Programme werden von den Entwicklern bereits containerisiert angeboten. In diesem Fall sollte zuerst sichergestellt werden dass die Umgebungsvariable <code>APPTAINER_CACHEDIR</code> gesetzt ist, idealerweise mit einem Verweis auf das Lustre wie folgt:
<code>export APPTAINER_CACHEDIR=/lustre/department/username/apptainer</code>
Viele Container werden als Docker-Image bereitgestellt und können direkt verwendet werden. Als Beispiel wird hier Reaction Mechanism Generator vom MIT genutzt.

Auf der Docker-Hub Seite des Projekts wird folgender Befehl für die Nutzung von Docker bereitgestellt: ( <nowiki>https://hub.docker.com/r/reactionmechanismgenerator/rmg</nowiki> )
<code>docker pull reactionmechanismgenerator/rmg</code>
Da wir Apptainer anbieten ist der Aufruf üb er die Befehlszeile nicht identisch, aber sehr ähnlich: ( <nowiki>https://apptainer.org/docs/user/main/cli/apptainer_pull.html</nowiki> )
<code>apptainer pull docker://reactionmechanismgenerator/rmg</code>

Modules & Verfügbare Software

2024-10-08T06:26:42Z

Mielczad: update der Softwareliste

==== Übersicht & Grundlagen zur Nuzung ====
Die bereitgestellten Compute-Knoten nutzen Linux, genaugenommen ein OpenSUSE.

HPC-typisch wird zentral Software bereitgestellt. Verfügbare Software wird über eine Modulumgebung geladen.

Welche Software verfügbar ist, lässt sich über <code>module avail</code> sowie <code>module spider <name></code> in Erfahrung bringen.

(Online Anleitung für lmod https://lmod.readthedocs.io/en/latest/010_user.html )

Wir bieten aktuell drei Gruppe von Software an:

# /hu "Von Uns" kompilierte Software welche zentral bereitgestellt wird.
# /all Über EasyBuild ( siehe http://docs.easybuild.io/what-is-easybuild/ ) bereitgestellte Software
# /intel Software welche mit Installer ausgeliefert wurde (wie zum Beispiel Intel OneAPI)

Bei der Auswahl von Software sollte darauf geachtet werden dass die Groß- und Kleinschreibung von Bedeutung ist, sprich gcc ist nicht gleich GCC.

Die finalen Pfade sind aktuell auch nicht endgültig festgelegt und können sich noch verändern.

Ferner wird empfohlen sich nicht auf die Defaults zu verlassen und die Version einer Software explizit auszuwählen.

Anwendungsbeispiel:

Die verfügbaren openmpi Versionen lassen sich mit dem Befehl
module spider openmpi
erfragen

Ist daraufhin die Version erwünscht, lässt sich diese mit dem Befehl
module load openmpi/5.0.3-gcc14.1.0
laden.

Aktuell geladene Module lassen sich mit
module list
anzeigen, während
module purge
alle geladenen Module "entlädt".

Aktuell wird die verfügbare Software noch ausgebaut, wodurch sich die Liste relativ schnell entwickelt. Für einen Überblick der aktuell verfügbaren Software wird gebeten diese direkt auf dem System abzufragen. Vor allem mit EasyBuild installierte Software bringt standardmäßig sehr viele kleine Abhängigkeiten mit.

Einen ersten Überblick über einige der wichtigeren Pakete (als Eigenkompilation) bietet die folgende Liste:

==== Verfügbare Software ====

===== Programmiersprachen und Compiler =====
- AMD aocc

- 4.2.0

- gcc

- 9.5.0

- 10.5.0

- 11.4.0

- 12.3.0

- 13.2.0

- 14.1.0

- 14.2.0

- Intel OneApi

- 2024.1

- Julia

- 1.10.3

- python

- 3.8.19

- 3.9.19

- 3.10.14

- 3.11.9

- 3.12.3

- QT (opensource)

- 5.15.14

- R

- 4.4.0

- ruby

- 3.3

===== Bibliotheken und Tools =====
- AMD AOCL

- 4.2.0 gcc

- 4.2.0 aocl

- apache-maven

- 3.9.8

- bash

- 5.2.21

- bc

- 1.0.7

- bison

- 3.8.2

- BLIS

- 4.2.0

- block2

- p0.5.3rc13 openmpi/5.0.3 gcc/14.1.0 OpenBLAS/0.3.26

- boost

- 1.85 gcc/13.2.0

- 1.85 gcc/14.1.0

- Catch2

- 3.6.0 cmake/3.29.3

- cmake

- 3.16.9

- 3.20.6

- 3.27.2

- 3.29.2

- 3.29.3

- coreutils

- 9.5

- costa

2.2.2

- cuda

- 10

- 11

- 12.0

- 12

- 12.1

- 12.2

- 12.3

- 12.4

- 12.4.1

- crest

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc13.2.0 openmpi/5.0.3-gcc13.2.0 gcc/13.2.0

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc14.1.0 openmpi/5.0.3-gcc14.1.0 gcc/14.1.0

fftw

- 3.3.0 gcc/14.1.0

- 3.3.0 openmpi/5.0.3 gcc/14.1.0

- flex

- 2.6.4

- fmt

- 10.2.1

- gsl

- 2.8

- hdf5

- 1.14.4.3

- lapack

- 3.12.0 gcc/13.2.0

- 3.12.0 gcc/14.1.0

- libaec

- 1.1.3

- libflame

- 4.2.0

- libunwind

- 1.8.1

- libxc

- 6.6.2

- magma

- 2.8.8

- miniforge3

- 24.1.2-0

- mpich

- 3.2.0 gcc/12.3.0

- 3.3.0 gcc/12.3.0

- 4.1.3 gcc/12.3.0

- 4.2.1 gcc/14.1.0

- OpenBLAS

- 0.3.26 gcc/13.2.0

- 0.3.26 gcc/14.1.0

- OpenCoarrays

- 2.9.3 mpich/3.3.0 gcc/12.3.0

- 2.10.2 openmpi/5.0.3 gcc/14.1.0

- OpenMPI

- 4.1.6 gcc/13.2.0

- 5.0.3 gcc/13.2.0

- 5.0.3 gcc/14.1.0

- 5.0.5 gcc/14.2.0

- patch

- 2.7.6

- proj

- 9.4.1 gcc/14.1.0

- scalapack

- 2.2.0

- spglib

- 2.4.0 gcc/14.1.0

- sirius

- 7.5.2

- spla

- 1.6.1

- swig

- 4.2.1

- szip

- 2.1.1

- umpire

- 2024.02.01

===== Software =====
- gdal

- 3.9.0 gcc/14.1.0 proj/9.4.1 swig/4.2.1 python/3.12.3

- hadoopp

- 3.4.0

- hpl

- v2.3

- ior

- 4.0.0 openmpi/5.0.3 gcc/14.1.0

- ncdu

- 1.20

- OpenFOAM

- 11

- v2312

- ORCA

- 5.0.4

- quantum-espresso

- 7.3.1 OpenBLAS/0.3.26 fftw/3.3.10 penmpi/5.0.3 gcc/14.1.0

- xtb

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/13.2.0

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/14.1.0

===== Fehlt was? =====
Da es sich beim HPC um ein Linux System handelt, ist es möglich eigene Software zu entwickeln. Die Einbindung von Software findet überwiegend über zwei grundlegende Variablen statt. <code>PATH</code> für ausführbare Binärdateien sowie <code>LD_LIBRARY_PATH</code> für verlinkte Bibliotheken.

Über ein <code>export PATH=/new/path:$PATH</code> sowie <code>export LD_LIBRARY_PATH=/new/path:$LD_LIBRARY_PATH</code> lassen sich beide erweitern. Diese Änderung gilt bis zum verlassen der Shell - oder ist "semi-permanent" wenn der Export in die .profile oder .bashrc Datei eingetragen wird.

Hierbei gilt es ferner zu beachten dass die Reihenfolge der Auflistung der verschiedenen Pfade von Bedeutung ist: die zuerst gefundene Variante wird genommen.

Obschon es möglich ist eine Software zu kompilieren, bitten wir darum bei fehlender freier Software nach Möglichkeit zuerst eine Anfrage an [mailto:hpc-support@hu-berlin.de hpc-support@hu-berlin.de] zu schicken, damit diese zentral für Alle zugänglich ist.

Bei Anfragen zu kommerzieller Software, internen Eigenentwicklungen oder anderweitig speziell lizenzierter Software stehen wir ebenfalls gerne zu Verfügung.

==== Python, Anaconda, Conda, Mamba ====

===== Python =====
Python wird in vielen Projekten eingesetzt. Die Nutzung von Python ist nicht immer problemfrei, darum gibt es folgend einige Empfehlungen für die Nutzung von Python, welche das Risiko von Problemen sowie die Problembeseitigung erleichtern.

Im Allgemeinen sollten Python Anwendungen in einer virtuellen Umgebung entwickelt und ausgeführt werden. Diese wird nativ von Python unterstützt und ermöglicht es Pakete auf einer bestimmten Version zu halten sowie eventuelle Inkompatibilitäten zwischen verschiedenen Projekten zu vermeiden. Ferner ist es möglich bei Problemen eine virtuelle Umgebung zu löschen und dadurch alte Pakete Rückstandslos zu entfernen. Das ist vor allem interessant da pip oder pip3 Abhängigkeiten installieren kann, aber im Gegensatz zu typischen Linux-Paketmanagern Abhängigkeiten nicht automatisch deinstallieren kann.

Eine virtuelle Umgebung kann wie folgt erstellt werden (mit einem relativen oder absoluten Pfad):
<code>python -m venv /Pfad/zur/neuen/virtuellen_Umgebung</code>
Mehr dazu auf in der Dokumentation von Python: <nowiki>https://docs.python.org/3/library/venv.html</nowiki>

Sollte es aus bestimmten Gründen nicht möglich sein eine virtuelle Umgebung zu nutzen, kann man mit pip Pakete in einem bestimmten Ordner installieren.
<code>pip3 install --target /Pfad/zum/ZielOrdner</code>
Danach kann der Ordner zur Variable PYTHONPATH hinzugefügt werden und wird dann von der Python-Umgebung erkannt.

Die virtuellen Umgebungen sind im Allgemeinen jedoch zu präferieren.

===== Anaconda, Conda, Mamba =====
Eine weitere Alternative ist die Nutzung einer Packetverwaltung in Python, so wie diese über Anaconda/conda/mamba angeboten wird, bei dieser ist der Funktionsumfang dann auch größer als be pip.

Hierbei werden Nutzer und Nutzerinnen angehalten die Nutzungsbedingungen von vor allem Anaconda und Miniconda zu beachten. Aktuell (Juli 2024) wird Miniforge unter der BSD Lizenz angeboten und ist in in Bezug auf die Nutzung.

Während eine zentrale Installation von conda und mamba über miniforge3 bereitgestellt wird, haben normale Nutzer keine Schreibrechte in dem zentralen Installationsordner. Standardmäßig wird conda/mamba daraufhin versuchen einen Ordner im Home-Verzeichnis anzulegen, alternativ kann ein expliziter Prefix wie folgt angegeben werden.
<code>conda create --prefix /Pfad/zur/neuen/conda_Umgebung</code>
Für typische Nutzertools wird darum empfohlen eine eigene Installation von miniforge aufzusetzen und eigene Umgebungen zu verwalten. Bei der Einrichtung muss dann nur darauf geachtet werden dass der Installationspfad korrekt eingegeben wird. Da eine solche Installation mit der Zeit recht groß werden kann, wird empfohlen dass lustre Dateisystem zu nutzen, der Pfad würde dementsprechend <code>/lustre/<Fakultät>/<Benutzername></code> lauten.

Mit <code>conda init</code> oder <code>mamba init</code> wird die Umgebung initiialisiert und die .bashrc Datei angepasst. Dabei werden eventuell existierende conda/mamba Konfigurationen überschrieben (!!!). Dies ist beim benutzen von mehreren Versionen potenziell problematisch und erfordert eine manuelle Anpassung der Skripte sowie potenziell deren Auslagerung in individuelle Dateien.

==== Persönliche Module ====
Es ist möglich eigene Module in <code>lmod</code> einzubinden, wie in der Dokumentation beschrieben: <nowiki>https://lmod.readthedocs.io/en/latest/020_advanced.html</nowiki>

Eine Môglichkeit besteht in dem Befehl <code>module use /path/to/personal/modulefiles</code>, alternativ kann der Pfad zu privaten Moduldateien auch gleich zur Variable <code>$MODULEPATH</code> hinzugefügt werden.

Informationen bezüglich des Aufbaus der Moduldateien finden sich in der lmod-Dokumentation auf der Webseite. Ebenso können die bereitgestellten Module unter <code>/software/modules</code> als Inspiration dienen.

==== Für Nutzer: ====
Für Nutzer von HPC@HU finden sich unter <code>/software/modules/software.md</code> weitere Informationen über die verfügbare Software und wie diese gebaut/konfiguriert wurde.

Datenspeicher & Dateistruktur

2024-09-03T18:01:16Z

Mielczad: Pfad für Home und Ausführung bezüglich des Lustre

Auf dem Slurm-Cluster stehen auf jeder Maschine (Login- & Exec-Server) folgende Verzeichnisse zur Verfügung.
{| class="wikitable"
!Pfad
!Größe
!Sichtbarkeit
!Dauer
!Besonderheit
|-
|$HOME
|
|global**
|unlimited
|20GB pro Nutzer
|-
|/tmp
|1.5TB
|local (Job)
|job-time
|autotmp_fs***
|-
|/dev/shm
|128GB
|local (Job)
|job-time
|autotmp_fs***
|-
|/lustre
|1.5PB
|global
|unlimited*
|
|}
<nowiki>*</nowiki>Die Daten werden zur Zeit erst bei sehr hoher Belegung gelöscht

<nowiki>**</nowiki>Die Verzeichnisse sind über NFS gemountet

<nowiki>***</nowiki>Die Verzeichnisse werden für jeden Job angelegt und gemountet. Andere Jobs sehen den Inhalt nicht. Verzeichnisse werden nach Job-Ende gelöscht.

Bei anderen Anforderungen bitten wir darum per Mail mit dem HPC-Support Kontakt aufzunehmen.

==== Home ====
Die Home-Verzeichnisse liegen im Netzwerk der Universität. Aus diesem Grund sind die Verzeichnisse auf eine Quota von 20GB pro Nutzer beschränkt und sollten im Normalfall nicht als Arbeitsverzeichnisse bei HPC Berechnungen genutzt werden. Vom Home-Verzeichnis werden so-genannte Snapshots erstellt - effektiv ein Backup. Einmal zu jeder Stunde, zur Minute null (bis zu 168 Snapshots, 1 Woche), dann jeden Tag um 00:00 Uhr (bis zu 30 Snapshots). Diese finden sich, in jedem Ordner, innerhalb eines unsichtbaren Ordners <code>.snapshot</code>. Dieser wird allerdings nicht über <code>ls -a</code> angezeigt. Allerdings ist es möglich in den Ordner hinein zu navigieren, <code>cd .snapshot</code> oder sich die Inhalte anzeigen zu lassen <code>ls .snapshot</code>. Dadurch lassen sich für die Nutzer und Nutzerinnen des HPC-Service Daten im Home-Verzeichnis selbst wiederherstellen.

Der individuelle Pfad zum Verzeichnis lautet <code>/home/<Fakultät>/<Benutzernmae></code>

==== Lustre ====
Als temporärer Datenspeicher steht ein Lustre-Dateisystem under <code>/lustre</code> zu Verfügung, mit einer Gesamtgeröße von 1.5PB.

Nach einem erfolgreichen Verbdindungsaufbau werden automatisch Ordern mit einer Dateistsruktur ähnlich dem Home-Verzeichnis angelegt und solten im Normalfall auch so genutzt werden. Bei Gruppenübergreifender Arbeit, lohnt es sich eventuell dedizierte Ordner auf der Fakultätsebene anzulegen.

Der individuelle Pfad zulm Verzeichnis lautet <code>/lustre/<Fakultät>/<Benutzernmae></code>

==== Lokaler Scratch ====
Um die Nutzung des lokalen scratch zu unterstützen wird das Plugin "auto_tmpdir" der University of Delaware genutzt (<nowiki>https://github.com/University-of-Delaware-IT-RCI/auto_tmpdir/tree/master</nowiki>).

Dieses Plugin erstellt einen dedizierten Ordner für einen ausgeführten job welcher dann unter /tmp erreichbar ist (sowie /var/tm und /dev/shm ).

Der Vorteil des Plugins ist, dass sich dieses um de Erstellung der Mounts sowie dem Löschen der Mounts und Dateien kümmert. Da die Dateien nach Ende des Jobs gelöscht werden, ist es wichtig die Ausgabe anderweitig zu "streamen" oder das Endergebnis zu kopieren.

Exemplarisch könnte ein Script für die Nutzung wie folgt aussehen:
<#!/bin/bash
#SBATCH --ntasks=1 # Run on a single CPU
#SBATCH --mem=1gb # Job memory request
#SBATCH --time=00:05:00 # Time limit hrs:min:sec
#SBATCH --partition=std
#SBATCH --account=nutzername

## set path to root of job data
basedir=/globalscratch/nutzername/myjob

## copy job data
cp -r $basedir/* /tmp
## change to working director
cd /tmp

## do the work
hostname > $basedir/result.log

## copy the results if they are required
cp -r /tmp/* $basedir

== Zugriffsrechte: ==
Typisch für ein klassisches SLURM cluster, werden die regulären UNIX Rechte und Gruppen eingesetzt. Diese ermöglichen es Ordner auf dem geteilten Laufwerk nur für bestimmte Nutzer und Gruppen freizugeben. Allerdings ist die regulären Linux Rechteverwaltung hier in Bezug auf eine detaillierte Rechteverteilung stak eingeschränkt. (Da es nicht praktisch möglich ist für alle möglichen Kombinationen dedizierte Gruppen anzulegen.)

Eine feinere Rechteverwaltung, sofern notwendig ist über Access Control Lists (ACL) möglich.

In der der aktuellen Implementierung lassen sich diese über <code>getfacl</code> in Erfahrung bringen, über <code>setfacl</code> setzen oder modifizieren.

Die access control lists werden für den jeweiligen Benutzernamen gesetzt, welcher hier die User-ID des HU-Accounts ist.

Leserechte für eine Datei liesen sich wie folgt setzen:
<code>setfacl -m u:benutzername:r test-datei</code>
Rechte lassen sich ebenfalls rekursiv setzen, wodurch alle Dateien und Ordner abgedeckt sind.
<code>setfacl -Rm u:benutzername:r pfad-zur/test-datei</code>
Weiterführende Informationen zu Access Control Lists inklusive einer Erklärung der "flags" finden sich auf der Seite des Ohio Supercomputing Centre: <nowiki>https://www.osc.edu/resources/getting_started/howto/howto_manage_access_control_list_acls/howto_use_posix_acl</nowiki>

Sollte es notwendig sein die Zugriffsrechte auf spezifische Benutzer (und nicht nur einen Fachbereich) zu begrenzen wird folgender Vorgang empfohlen:

Die regulären UNIX/POSIX-Rechte werden auf den Eigentümer reduziert, ohne Zugriffsrechte für die Gruppe oder Welt. Dies entspräche einem <code>r-x------</code> (<code>500</code>) oder <code>rwx------</code> (<code>700</code>). Das Aufzeigen von Inhalten in Ordnern erfordert hierbei die Ausführungsrechte (<code>x</code>). Für Dateien welche nicht ausgeführt werden reichen Lese- und Schreibrechte (<code>r--</code> / <code>rw-</code> ).

Im nächsten Schritt werden berechtigen Nutzern über die ACLs Zugriffsrechte eingeräumt - der Gruppe bleibt hierbei weiter der Zugriff auf der POSIX-Basis verwehrt.

Anmerkung: Sollte die Vertraulichkeit von Daten eine Einschränkung der Zugriffsrechte erfordern, sollte im Allgemeinen minimalste Rechte eingeräumt werden. So wenige wie möglich, so viele wie erforderlich. Andererseits ist ein konventionelles HPC-Cluster nicht für hochsensible Daten ausgelegt. In diesem Fall bitten wir darum dass mit dem HPC-Team unter hpc-suppport@hu-berlin.de Kontakt aufgenommen wird um eventuelle Lösungsansätze zu besprechen.

== Externer Zugriff: ==
Der Zugriff auf das Dateisystem erfolgt über sftp (ftp ûber ssh) aus dem Netz der Humboldt Universität heraus.

Die ist unter Windows mit WinScp ( <nowiki>https://winscp.net/</nowiki> ) möglich - auch in Verbindung mit putty ( <nowiki>https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html</nowiki> ) für die Befehlszeile - und wird unter Linux im Plasma Desktop nativ von Dolphin unterstützt.

Datenspeicher & Dateistruktur

2024-09-03T07:00:03Z

Mielczad: Updates zum Home Directories

Auf dem Slurm-Cluster stehen auf jeder Maschine (Login- & Exec-Server) folgende Verzeichnisse zur Verfügung.
{| class="wikitable"
!Pfad
!Größe
!Sichtbarkeit
!Dauer
!Besonderheit
|-
|$HOME
|
|global**
|unlimited
|20GB pro Nutzer
|-
|/tmp
|1.5TB
|local (Job)
|job-time
|autotmp_fs***
|-
|/dev/shm
|128GB
|local (Job)
|job-time
|autotmp_fs***
|-
|/lustre
|1.5PB
|global
|unlimited*
|
|}
<nowiki>*</nowiki>Die Daten werden zur Zeit erst bei sehr hoher Belegung gelöscht

<nowiki>**</nowiki>Die Verzeichnisse sind über NFS gemountet

<nowiki>***</nowiki>Die Verzeichnisse werden für jeden Job angelegt und gemountet. Andere Jobs sehen den Inhalt nicht. Verzeichnisse werden nach Job-Ende gelöscht.

Bei anderen Anforderungen bitten wir darum per Mail mit dem HPC-Support Kontakt aufzunehmen.

==== Home ====
Die Home-Verzeichnisse liegen im Netzwerk der Universität. Aus diesem Grund sind die Verzeichnisse auf eine Quota von 20GB pro Nutzer beschränkt und sollten im Normalfall nicht als Arbeitsverzeichnisse bei HPC Berechnungen genutzt werden. Vom Home-Verzeichnis werden so-genannte Snapshots erstellt - effektiv ein Backup. Einmal zu jeder Stunde, zur Minute null (bis zu 168 Snapshots, 1 Woche), dann jeden Tag um 00:00 Uhr (bis zu 30 Snapshots). Diese finden sich, in jedem Ordner, innerhalb eines unsichtbaren Ordners <code>.snapshot</code>. Dieser wird allerdings nicht über <code>ls -a</code> angezeigt. Allerdings ist es möglich in den Ordner hinein zu navigieren, <code>cd .snapshot</code> oder sich die Inhalte anzeigen zu lassen <code>ls .snapshot</code>. Dadurch lassen sich für die Nutzer und Nutzerinnen des HPC-Service Daten im Home-Verzeichnis selbst wiederherstellen.

==== Lokaler Scratch ====
Um die Nutzung des lokalen scratch zu unterstützen wird das Plugin "auto_tmpdir" der University of Delaware genutzt (<nowiki>https://github.com/University-of-Delaware-IT-RCI/auto_tmpdir/tree/master</nowiki>).

Dieses Plugin erstellt einen dedizierten Ordner für einen ausgeführten job welcher dann unter /tmp erreichbar ist (sowie /var/tm und /dev/shm ).

Der Vorteil des Plugins ist, dass sich dieses um de Erstellung der Mounts sowie dem Löschen der Mounts und Dateien kümmert. Da die Dateien nach Ende des Jobs gelöscht werden, ist es wichtig die Ausgabe anderweitig zu "streamen" oder das Endergebnis zu kopieren.

Exemplarisch könnte ein Script für die Nutzung wie folgt aussehen:
<#!/bin/bash
#SBATCH --ntasks=1 # Run on a single CPU
#SBATCH --mem=1gb # Job memory request
#SBATCH --time=00:05:00 # Time limit hrs:min:sec
#SBATCH --partition=std
#SBATCH --account=nutzername

## set path to root of job data
basedir=/globalscratch/nutzername/myjob

## copy job data
cp -r $basedir/* /tmp
## change to working director
cd /tmp

## do the work
hostname > $basedir/result.log

## copy the results if they are required
cp -r /tmp/* $basedir

== Zugriffsrechte: ==
Typisch für ein klassisches SLURM cluster, werden die regulären UNIX Rechte und Gruppen eingesetzt. Diese ermöglichen es Ordner auf dem geteilten Laufwerk nur für bestimmte Nutzer und Gruppen freizugeben. Allerdings ist die regulären Linux Rechteverwaltung hier in Bezug auf eine detaillierte Rechteverteilung stak eingeschränkt. (Da es nicht praktisch möglich ist für alle möglichen Kombinationen dedizierte Gruppen anzulegen.)

Eine feinere Rechteverwaltung, sofern notwendig ist über Access Control Lists (ACL) möglich.

In der der aktuellen Implementierung lassen sich diese über <code>getfacl</code> in Erfahrung bringen, über <code>setfacl</code> setzen oder modifizieren.

Die access control lists werden für den jeweiligen Benutzernamen gesetzt, welcher hier die User-ID des HU-Accounts ist.

Leserechte für eine Datei liesen sich wie folgt setzen:
<code>setfacl -m u:benutzername:r test-datei</code>
Rechte lassen sich ebenfalls rekursiv setzen, wodurch alle Dateien und Ordner abgedeckt sind.
<code>setfacl -Rm u:benutzername:r pfad-zur/test-datei</code>
Weiterführende Informationen zu Access Control Lists inklusive einer Erklärung der "flags" finden sich auf der Seite des Ohio Supercomputing Centre: <nowiki>https://www.osc.edu/resources/getting_started/howto/howto_manage_access_control_list_acls/howto_use_posix_acl</nowiki>

Sollte es notwendig sein die Zugriffsrechte auf spezifische Benutzer (und nicht nur einen Fachbereich) zu begrenzen wird folgender Vorgang empfohlen:

Die regulären UNIX/POSIX-Rechte werden auf den Eigentümer reduziert, ohne Zugriffsrechte für die Gruppe oder Welt. Dies entspräche einem <code>r-x------</code> (<code>500</code>) oder <code>rwx------</code> (<code>700</code>). Das Aufzeigen von Inhalten in Ordnern erfordert hierbei die Ausführungsrechte (<code>x</code>). Für Dateien welche nicht ausgeführt werden reichen Lese- und Schreibrechte (<code>r--</code> / <code>rw-</code> ).

Im nächsten Schritt werden berechtigen Nutzern über die ACLs Zugriffsrechte eingeräumt - der Gruppe bleibt hierbei weiter der Zugriff auf der POSIX-Basis verwehrt.

Anmerkung: Sollte die Vertraulichkeit von Daten eine Einschränkung der Zugriffsrechte erfordern, sollte im Allgemeinen minimalste Rechte eingeräumt werden. So wenige wie möglich, so viele wie erforderlich. Andererseits ist ein konventionelles HPC-Cluster nicht für hochsensible Daten ausgelegt. In diesem Fall bitten wir darum dass mit dem HPC-Team unter hpc-suppport@hu-berlin.de Kontakt aufgenommen wird um eventuelle Lösungsansätze zu besprechen.

== Externer Zugriff: ==
Der Zugriff auf das Dateisystem erfolgt über sftp (ftp ûber ssh) aus dem Netz der Humboldt Universität heraus.

Die ist unter Windows mit WinScp ( <nowiki>https://winscp.net/</nowiki> ) möglich - auch in Verbindung mit putty ( <nowiki>https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html</nowiki> ) für die Befehlszeile - und wird unter Linux im Plasma Desktop nativ von Dolphin unterstützt.

Datenspeicher & Dateistruktur

2024-09-03T06:44:50Z

Mielczad:

Auf dem Slurm-Cluster stehen auf jeder Maschine (Login- & Exec-Server) folgende Verzeichnisse zur Verfügung.
{| class="wikitable"
!Pfad
!Größe
!Sichtbarkeit
!Dauer
!Besonderheit
|-
|$HOME
|800GB
|global**
|unlimited
|20GB pro Nutzer
|-
|/tmp
|1.5TB
|local (Job)
|job-time
|autotmp_fs***
|-
|/dev/shm
|128GB
|local (Job)
|job-time
|autotmp_fs***
|-
|/lustre
|1.5PB
|global
|unlimited*
|
|}
<nowiki>*</nowiki>Die Daten werden zur Zeit erst bei sehr hoher Belegung gelöscht

<nowiki>**</nowiki>Die Verzeichnisse sind über NFS gemountet

<nowiki>***</nowiki>Die Verzeichnisse werden für jeden Job angelegt und gemountet. Andere Jobs sehen den Inhalt nicht. Verzeichnisse werden nach Job-Ende gelöscht.

Bei anderen Anforderungen bitten wir darum per Mail mit dem HPC-Support Kontakt aufzunehmen.

Um die Nutzung des lokalen scratch zu unterstützen wird das Plugin "auto_tmpdir" der University of Delaware genutzt (<nowiki>https://github.com/University-of-Delaware-IT-RCI/auto_tmpdir/tree/master</nowiki>).

Dieses Plugin erstellt einen dedizierten Ordner für einen ausgeführten job welcher dann unter /tmp erreichbar ist (sowie /var/tm und /dev/shm ).

Der Vorteil des Plugins ist, dass sich dieses um de Erstellung der Mounts sowie dem Löschen der Mounts und Dateien kümmert. Da die Dateien nach Ende des Jobs gelöscht werden, ist es wichtig die Ausgabe anderweitig zu "streamen" oder das Endergebnis zu kopieren.

Exemplarisch könnte ein Script für die Nutzung wie folgt aussehen:
<#!/bin/bash
#SBATCH --ntasks=1 # Run on a single CPU
#SBATCH --mem=1gb # Job memory request
#SBATCH --time=00:05:00 # Time limit hrs:min:sec
#SBATCH --partition=std
#SBATCH --account=nutzername

## set path to root of job data
basedir=/globalscratch/nutzername/myjob

## copy job data
cp -r $basedir/* /tmp
## change to working director
cd /tmp

## do the work
hostname > $basedir/result.log

## copy the results if they are required
cp -r /tmp/* $basedir

== Zugriffsrechte: ==
Typisch für ein klassisches SLURM cluster, werden die regulären UNIX Rechte und Gruppen eingesetzt. Diese ermöglichen es Ordner auf dem geteilten Laufwerk nur für bestimmte Nutzer und Gruppen freizugeben. Allerdings ist die regulären Linux Rechteverwaltung hier in Bezug auf eine detaillierte Rechteverteilung stak eingeschränkt. (Da es nicht praktisch möglich ist für alle möglichen Kombinationen dedizierte Gruppen anzulegen.)

Eine feinere Rechteverwaltung, sofern notwendig ist über Access Control Lists (ACL) möglich.

In der der aktuellen Implementierung lassen sich diese über <code>getfacl</code> in Erfahrung bringen, über <code>setfacl</code> setzen oder modifizieren.

Die access control lists werden für den jeweiligen Benutzernamen gesetzt, welcher hier die User-ID des HU-Accounts ist.

Leserechte für eine Datei liesen sich wie folgt setzen:
<code>setfacl -m u:benutzername:r test-datei</code>
Rechte lassen sich ebenfalls rekursiv setzen, wodurch alle Dateien und Ordner abgedeckt sind.
<code>setfacl -Rm u:benutzername:r pfad-zur/test-datei</code>
Weiterführende Informationen zu Access Control Lists inklusive einer Erklärung der "flags" finden sich auf der Seite des Ohio Supercomputing Centre: <nowiki>https://www.osc.edu/resources/getting_started/howto/howto_manage_access_control_list_acls/howto_use_posix_acl</nowiki>

Sollte es notwendig sein die Zugriffsrechte auf spezifische Benutzer (und nicht nur einen Fachbereich) zu begrenzen wird folgender Vorgang empfohlen:

Die regulären UNIX/POSIX-Rechte werden auf den Eigentümer reduziert, ohne Zugriffsrechte für die Gruppe oder Welt. Dies entspräche einem <code>r-x------</code> (<code>500</code>) oder <code>rwx------</code> (<code>700</code>). Das Aufzeigen von Inhalten in Ordnern erfordert hierbei die Ausführungsrechte (<code>x</code>). Für Dateien welche nicht ausgeführt werden reichen Lese- und Schreibrechte (<code>r--</code> / <code>rw-</code> ).

Im nächsten Schritt werden berechtigen Nutzern über die ACLs Zugriffsrechte eingeräumt - der Gruppe bleibt hierbei weiter der Zugriff auf der POSIX-Basis verwehrt.

Anmerkung: Sollte die Vertraulichkeit von Daten eine Einschränkung der Zugriffsrechte erfordern, sollte im Allgemeinen minimalste Rechte eingeräumt werden. So wenige wie möglich, so viele wie erforderlich. Andererseits ist ein konventionelles HPC-Cluster nicht für hochsensible Daten ausgelegt. In diesem Fall bitten wir darum dass mit dem HPC-Team unter hpc-suppport@hu-berlin.de Kontakt aufgenommen wird um eventuelle Lösungsansätze zu besprechen.

== Externer Zugriff: ==
Der Zugriff auf das Dateisystem erfolgt über sftp (ftp ûber ssh) aus dem Netz der Humboldt Universität heraus.

Die ist unter Windows mit WinScp ( <nowiki>https://winscp.net/</nowiki> ) möglich - auch in Verbindung mit putty ( <nowiki>https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html</nowiki> ) für die Befehlszeile - und wird unter Linux im Plasma Desktop nativ von Dolphin unterstützt.

Datenspeicher & Dateistruktur

2024-08-30T11:29:03Z

Mielczad: quota für home eingeführt

Auf dem Slurm-Cluster stehen auf jeder Maschine (Login- & Exec-Server) folgende Verzeichnisse zur Verfügung.
{| class="wikitable"
!Pfad
!Größe
!Sichtbarkeit
!Dauer
!Besonderheit
|-
|$HOME
|800GB
|global**
|unlimited
|25GB pro Nutzer
|-
|/tmp
|1.5TB
|local (Job)
|job-time
|autotmp_fs***
|-
|/dev/shm
|128GB
|local (Job)
|job-time
|autotmp_fs***
|-
|/lustre
|1.5PB
|global
|unlimited*
|
|}
<nowiki>*</nowiki>Die Daten werden zur Zeit erst bei sehr hoher Belegung gelöscht

<nowiki>**</nowiki>Die Verzeichnisse sind über NFS gemountet

<nowiki>***</nowiki>Die Verzeichnisse werden für jeden Job angelegt und gemountet. Andere Jobs sehen den Inhalt nicht. Verzeichnisse werden nach Job-Ende gelöscht.

Bei anderen Anforderungen bitten wir darum per Mail mit dem HPC-Support Kontakt aufzunehmen.

Um die Nutzung des lokalen scratch zu unterstützen wird das Plugin "auto_tmpdir" der University of Delaware genutzt (<nowiki>https://github.com/University-of-Delaware-IT-RCI/auto_tmpdir/tree/master</nowiki>).

Dieses Plugin erstellt einen dedizierten Ordner für einen ausgeführten job welcher dann unter /tmp erreichbar ist (sowie /var/tm und /dev/shm ).

Der Vorteil des Plugins ist, dass sich dieses um de Erstellung der Mounts sowie dem Löschen der Mounts und Dateien kümmert. Da die Dateien nach Ende des Jobs gelöscht werden, ist es wichtig die Ausgabe anderweitig zu "streamen" oder das Endergebnis zu kopieren.

Exemplarisch könnte ein Script für die Nutzung wie folgt aussehen:
<#!/bin/bash
#SBATCH --ntasks=1 # Run on a single CPU
#SBATCH --mem=1gb # Job memory request
#SBATCH --time=00:05:00 # Time limit hrs:min:sec
#SBATCH --partition=std
#SBATCH --account=nutzername

## set path to root of job data
basedir=/globalscratch/nutzername/myjob

## copy job data
cp -r $basedir/* /tmp
## change to working director
cd /tmp

## do the work
hostname > $basedir/result.log

## copy the results if they are required
cp -r /tmp/* $basedir</code>

== Zugriffsrechte: ==
Typisch für ein klassisches SLURM cluster, werden die regulären UNIX Rechte und Gruppen eingesetzt. Diese ermöglichen es Ordner auf dem geteilten Laufwerk nur für bestimmte Nutzer und Gruppen freizugeben. Allerdings ist die regulären Linux Rechteverwaltung hier in Bezug auf eine detaillierte Rechteverteilung stak eingeschränkt. (Da es nicht praktisch möglich ist für alle möglichen Kombinationen dedizierte Gruppen anzulegen.)

Eine feinere Rechteverwaltung, sofern notwendig ist über Access Control Lists (ACL) möglich.

In der der aktuellen Implementierung lassen sich diese über <code>getfacl</code> in Erfahrung bringen, über <code>setfacl</code> setzen oder modifizieren.

Die access control lists werden für den jeweiligen Benutzernamen gesetzt, welcher hier die User-ID des HU-Accounts ist.

Leserechte für eine Datei liesen sich wie folgt setzen:
<code>setfacl -m u:benutzername:r test-datei</code>
Rechte lassen sich ebenfalls rekursiv setzen, wodurch alle Dateien und Ordner abgedeckt sind.
<code>setfacl -Rm u:benutzername:r pfad-zur/test-datei</code>
Weiterführende Informationen zu Access Control Lists inklusive einer Erklärung der "flags" finden sich auf der Seite des Ohio Supercomputing Centre: <nowiki>https://www.osc.edu/resources/getting_started/howto/howto_manage_access_control_list_acls/howto_use_posix_acl</nowiki>

Sollte es notwendig sein die Zugriffsrechte auf spezifische Benutzer (und nicht nur einen Fachbereich) zu begrenzen wird folgender Vorgang empfohlen:

Die regulären UNIX/POSIX-Rechte werden auf den Eigentümer reduziert, ohne Zugriffsrechte für die Gruppe oder Welt. Dies entspräche einem <code>r-x------</code> (<code>500</code>) oder <code>rwx------</code> (<code>700</code>). Das Aufzeigen von Inhalten in Ordnern erfordert hierbei die Ausführungsrechte (<code>x</code>). Für Dateien welche nicht ausgeführt werden reichen Lese- und Schreibrechte (<code>r--</code> / <code>rw-</code> ).

Im nächsten Schritt werden berechtigen Nutzern über die ACLs Zugriffsrechte eingeräumt - der Gruppe bleibt hierbei weiter der Zugriff auf der POSIX-Basis verwehrt.

Anmerkung: Sollte die Vertraulichkeit von Daten eine Einschränkung der Zugriffsrechte erfordern, sollte im Allgemeinen minimalste Rechte eingeräumt werden. So wenige wie möglich, so viele wie erforderlich. Andererseits ist ein konventionelles HPC-Cluster nicht für hochsensible Daten ausgelegt. In diesem Fall bitten wir darum dass mit dem HPC-Team unter hpc-suppport@hu-berlin.de Kontakt aufgenommen wird um eventuelle Lösungsansätze zu besprechen.

== Externer Zugriff: ==
Der Zugriff auf das Dateisystem erfolgt über sftp (ftp ûber ssh) aus dem Netz der Humboldt Universität heraus.

Die ist unter Windows mit WinScp ( <nowiki>https://winscp.net/</nowiki> ) möglich - auch in Verbindung mit putty ( <nowiki>https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html</nowiki> ) für die Befehlszeile - und wird unter Linux im Plasma Desktop nativ von Dolphin unterstützt.

FAQ

2024-08-22T13:56:21Z

Mielczad: Hinzufügen des Textes über die Zeilenterminierung

Das zukünftige FAQ - welches sich, folgend der Erfahrung mit Nutzeranfragen, im Aufbau befindet:

== Wie fordere Ich Software an ==
Dem Nutzer werden eine ganze Reihe von Bibliotheken sowie Software über die Modules-Umgebung zu Verfügung gestellt. Diese werden unter [[Modules & Verfûgbare Software]] vorgestellt.

Sollte eine erwünschte Software oder Bibliothek fehlen, können wir diese (je nach Lizenzbedingungen) nach einer Anfrage zu Verfügung stellen. Dies ist im großen und ganzen über eine formlose Email an hpc-support@hu-berlin.de möglich.

Hierbei sind Links zu der Software hilfreich, sowie eventuell vorhandene Test-Jobs mit denen sich die Funktionalität testen lässt, inklusive der nötigen Befehle um die Software auszuführen.

== Wie melde Ich ein Softwareproblem ==
In den meisten Fällen werden Software und Bibliotheken mit Standardeinstellungen kompiliert und bereitgestellt. Dies ist häufig ausreichend.

Manchmal ist es allerdings notwendig bestimmte Argumente oder "Flags" zu setzen, zum Beispiel um zum Beispiel CUDA-Support zu aktivieren. In solch einem Fall würde das Ausführen einer Bibliothek ohne CUDA-Support mit CUDA zu einem Fehler führen. (CUDA wird hier nur beispielhaft genutzt.)

Sollte ein Fehler auftreten, sollte dieser möglichst vollumfänglich kopiert werde. Ferner sind die Eingaben von Interesse: wie wurde eine Software/Bibliothek genutzt, welche ist es, welche Argumente wurden genutzt. Idealerweise sollte auch eine Testdatei zu Verfügung gestellt werden damit das Problem nachvolzogen und reproduziert werden kann. Hierbei sollte die Testdatei idealerweise schnell das Problem aufzeigen können, das beaknnte "minimum working example".

Dies kann dann über eine formlose Email an hpc-support@hu-berlin.de geschickt werden.

== OpenMP mit OpenMPI ==
Grundsätzlich soll die Nutzung von OpenMP in Kombination mit OpenMPI Môglich sein. Dadurch lassen sich das geringere "Overheaded" von "Shared Memory Processing" (Threading) mit der Skallierung des MPI-Multi-Process-Asatz kombinieren.

In einem uns bekannten Fall gab es Probleme bei der Verwaltung der Threads in einem OpenSource Fortran-Programm.

Sollten unerwartet Probleme auftreten, sind folgenden Variablen/Parameter zu überprüfen:

Die Variable<code>OMP_NUM_THREADS</code> welche die Anzahl der OpenMP-Threads festlegt sollte exportiert werden, sowie die Option <code>--bind-to none</code> beim Aufruf mit OpenMPI genutzt werden.

Ein Aufruf in einem Script sähe dann für 4 Threads und zwei Prozesse wie folgt aus:
<export OMP_NUM_THREADS=4
mpirun --bind-to none -np 2 meine_Software</code>

== Zeilenterminierung ==
Wenn Textdateien unter Windows erstellt werden, kann dies mitunter in einigen Fällen unter Linux zu einem Problem führen.

Textdateien unter unter Windows werden mit <code>\r\n</code> terminiert, "return carriage" (<code>\r</code>) "neline" (<code>\n</code>), wḧarend Textdateien unter Linux nur mit einem <code>\n</code>, "newline" terminiert werden. Dies kann dann zu teilweise unverständlichen Fehlermeldungen führen. Unter Windows wird darum die Nutzung von Notepad++ ( <nowiki>https://notepad-plus-plus.org/downloads</nowiki> ) empfohlen, da in diesem Editor die Zeilenterminierung eingestellt werden kann und diese auch in der Statusleiste angezeigt wird. Alternativ können Textdateien auch über das Tool <code>dos2unix</code> konvertiert werden, dieses steht auf den Login-Knoten zu Verfügung.

Containerisierung

2024-08-20T09:03:00Z

Mielczad:

Während im HPC-Bereich Software traditionnel direkt auf den Compute-Nodes ausgeführt wird, hat sich in den letzten Jahren auch die Nutzung eine Containerumgebung für bestimmte Anwendungsfâlle etabliert. Ein bekanntes Problem auf Compute-Clustern ist der Bedarf an einer neuerern glibc-Standardbibliothek welche durch Ihre tiefe Verwurzelung in Linux nicht ohne Weiteres angeboten werden kann. Die Containeriesrung kann es ermöglichen Software auszuführen welche sonst nicht gebaut werden kann oder nicht lauffähig ist.

Docker als bekannteste Conainerisierung ist hierbei im HPC aufgrund der Root-Rechte auf einem von Nutzern geteilten HPC Cluster problematisch. Darum wurde eine Containerisierung am Lawrence Berkeley National Laboratory Entwickelt welche nur im Userspace läuft, heute unter dem Namen Apptainer bekannt ( <nowiki>https://apptainer.org/</nowiki> ) - diese bieten wir den Nutzern auf unseren Ressourcen an. (Anmerkung: das Projekt startete ursprünglich unter dem Namen Singularity, Apptainer ist mit Singularity. SingularityCE its ein alternativer Fork.)

Container für Apptainer können in Apptainer selbst gebaut werden, oder aber auch in Docker und dann konvertiert werden. Wer sich Container über die Docker-Route selbst bauen möchte, benötigt hierfür seinen eigenen Computer. Alternativ kann Apptainer auch Images direkt vom Docker-Hub herunterladen sofern ein Image zu VerFûgung steht.

Wichtig is hierbei dass die Umgebungsvariable <code>APPTAINER_CACHEDIR</code> zum Einstellen des Cache-Ordners so gewählt wird, dass sich dieses auf dem Lustre-Dateisystem befindet. Zum Bespiel wie folgt:
<code>export APPTAINER_CACHEDIR=/lustre/department/username/apptainer</code>

=== Ein Minimales openSUSE 15.6 als glibc Overlay ===
Bei einem unserer Nutzer befindet sich ein minimales openSUSE 15.6 als Overlay im Testbetrieb um eine neuere glibc anzubieten.

Dazu wird ein Docker-Container mit openSUSE Leap 15.6 aufgesetzt, in welchem zusätlzich noch lua-lmod installiert wird. Letzteres wird benötigt um die Modules-Umgebung zu unterstützen. Wichtige Anmerkung, damit zypper korrekt funktioniert, benötigt es ein "clean" sowie "refresh". Dies ist mit dem folgenden Dockerfile möglich:
# syntax=docker/dockerfile:1

# use Leap as a basis to reduce differences
FROM opensuse/leap:15.6

RUN zypper clean --all
RUN zypper ref

# the container needs to bring its own lmod along
RUN zypper -n install lua-lmod

RUN bash
Danach kann der Container mit <code>docker build . -t opensuse-15.6</code> gebaut werden.

Ist der Docker-Container lokal aufgesetzt, kann dieser in eine Apptainer sif-Datei umgewandelt werden, und zwar wie folg: <code>apptainer build opensuse-15.6.sif docker-daemon://opensuse-15.6:latest</code> Hier ist es wichtig entweder den Tag (fals vorhanden) oder <code>:latest</code> anzugeben, sonst wird die Datei nicht erstellt.

Die nun erstellte Datei ist der Container welcher sich nun in einer HPC-Umgebung - mit Nutzerrechtne - verwenden lässt. In einer interaktiven Session würde der Container mit <code>apptainer run opensuse-15.6.sif</code> ausgeführt. Dies ist an sich zuerst nicht besonders nützlich da nur das Home-Verzeichnis benutzbar ist. Allerdings können weitere Verzeichnisse über <code>--bind</code> eingebunden werden, wodurch sich im Container die gleichen Pfade wie außerhalb nutzen lassen. Das wäre hier:
<code>apptainer run --bind /lustre,/software opensuse-15.6.sif</code>
Allerdings kann der Container dabei im Zweifelsfall nicht auf systemseitig angebotene Software oder Bibliotheken zugreifen. Diese lassen sich über einen Workaround ebenfalls einbinden. Der Pfad wird umgeschrieben und über die Umgebungsvariablen eingespielt. Hierbei ist es wichtig dass der Pfad zu der Systemsoftware ans Ende gehängt wird, denn die Pfade innerhalb des Containers sollen privilegiert werden.

Zum Beispiel liese sich der Container wie folgt starten:
<code>apptainer run --bind /bin:/bin_base,/usr:/usr_base,/lustre,/software opensuse-15.6.sif</code>
Und danach könne die Umgebungsvariablen mit den folgenden Befehelen gesetzt werden:
## add the base software back in via path:
export PATH=$PATH:/usr_base/local/bin:/usr_base/bin:/bin_base
## ensure base OS libraries are included
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr_base/lib:/usr_base/lib64
Dies geht so natürlich nur in einer interaktiven Session.

Soll ein Job über SLURM eingereicht werden, so muss dies automatisch geschehen. Dazu kannn <code>apptainer exec</code> genutzt werden. Es wird ein Bash-Script geschrieben welcher die Umgebungsvariablen exportiert (zum erweitern der Pfade) und benötigte Module lädt und dann eventuellen Code ausführt. Das Script muss hierbei ausführbar sein, woraus sich ein Aufruf wie folgt ergibt: <code>apptainer exec --bind /bin:/bin_base,/usr:/usr_base,/lustre,/software opensuse-15.6.sif executable_script.sh</code>

Ein minimaler Container mit openSUSE 15.6 ist unter <code>/software/containers/opensuse-15.6.sif</code> verfügbar.

=== Bereitgestellte Container ===
Manche Programme werden von den Entwicklern bereits containerisiert angeboten. In diesem Fall sollte zuerst sichergestellt werden dass die Umgebungsvariable <code>APPTAINER_CACHEDIR</code> gesetzt ist, idealerweise mit einem Verweis auf das Lustre wie folgt:
<code>export APPTAINER_CACHEDIR=/lustre/department/username/apptainer</code>
Viele Container werden als Docker-Image bereitgestellt und können direkt verwendet werden. Als Beispiel wird hier Reaction Mechanism Generator vom MIT genutzt.

Auf der Docker-Hub Seite des Projekts wird folgender Befehl für die Nutzung von Docker bereitgestellt: ( <nowiki>https://hub.docker.com/r/reactionmechanismgenerator/rmg</nowiki> )
<code>docker pull reactionmechanismgenerator/rmg</code>
Da wir Apptainer anbieten ist der Aufruf üb er die Befehlszeile nicht identisch, aber sehr ähnlich: ( <nowiki>https://apptainer.org/docs/user/main/cli/apptainer_pull.html</nowiki> )
<code>apptainer pull docker://reactionmechanismgenerator/rmg</code>

Containerisierung

2024-08-19T13:25:54Z

Mielczad:

Während im HPC-Bereich Software traditionnel direkt auf den Compute-Nodes ausgeführt wird, hat sich in den letzten Jahren auch die Nutzung eine Containerumgebung für bestimmte Anwendungsfâlle etabliert. Ein bekanntes Problem auf Compute-Clustern ist der Bedarf an einer neuerern glibc-Standardbibliothek welche durch Ihre tiefe Verwurzelung in Linux nicht ohne Weiteres angeboten werden kann. Die Containeriesrung kann es ermöglichen Software auszuführen welche sonst nicht gebaut werden kann oder nicht lauffähig ist.

Docker als bekannteste Conainerisierung ist hierbei im HPC aufgrund der Root-Rechte auf einem von Nutzern geteilten HPC Cluster problematisch. Darum wurde eine Containerisierung am Lawrence Berkeley National Laboratory Entwickelt welche nur im Userspace läuft, heute unter dem Namen Apptainer bekannt ( <nowiki>https://apptainer.org/</nowiki> ) - diese bieten wir den Nutzern auf unseren Ressourcen an. (Anmerkung: das Projekt startete ursprünglich unter dem Namen Singularity, Apptainer ist mit Singularity. SingularityCE its ein alternativer Fork.)

Container für Apptainer können in Apptainer selbst gebaut werden, oder aber auch in Docker und dann konvertiert werden. Wer sich Container über die Docker-Route selbst bauen möchte, benötigt hierfür seinen eigenen Computer. Alternativ kann Apptainer auch Images direkt vom Docker-Hub herunterladen sofern ein Image zu VerFûgung steht.

Wichtig is hierbei dass die Umgebungsvariable <code>APPTAINER_CACHEDIR</code> zum Einstellen des Cache-Ordners so gewählt wird, dass sich dieses auf dem Lustre-Dateisystem befindet. Zum Bespiel wie folgt:
<code>export APPTAINER_CACHEDIR=/lustre/department/username/apptainer</code>

=== Ein Minimales openSUSE 15.6 als glibc Overlay ===
Bei einem unserer Nutzer befindet sich ein minimales openSUSE 15.6 als Overlay im Testbetrieb um eine neuere glibc anzubieten.

Dazu wird ein Docker-Container mit openSUSE Leap 15.6 aufgesetzt, in welchem zusätlzich noch lua-lmod installiert wird. Letzteres wird benötigt um die Modules-Umgebung zu unterstützen. Wichtige Anmerkung, damit zypper korrekt funktioniert, benötigt es ein "clean" sowie "refresh". Dies ist mit dem folgenden Dockerfile möglich:
<# syntax=docker/dockerfile:1

# use Leap as a basis to reduce differences
FROM opensuse/leap:15.6

RUN zypper clean --all
RUN zypper ref

# the container needs to bring its own lmod along
RUN zypper -n install lua-lmod

RUN bash</code>
Danach kann der Container mit <code>docker build . -t opensuse-15.6</code> gebaut werden.

Ist der Docker-Container lokal aufgesetzt, kann dieser in eine Apptainer sif-Datei umgewandelt werden, und zwar wie folg: <code>apptainer build opensuse-15.6.sif docker-daemon://opensuse-15.6:latest</code> Hier ist es wichtig entweder den Tag (fals vorhanden) oder <code>:latest</code> anzugeben, sonst wird die Datei nicht erstellt.

Die nun erstellte Datei ist der Container welcher sich nun in einer HPC-Umgebung - mit Nutzerrechtne - verwenden lässt. In einer interaktiven Session würde der Container mit <code>apptainer run opensuse-15.6.sif</code> ausgeführt. Dies ist an sich zuerst nicht besonders nützlich da nur das Home-Verzeichnis benutzbar ist. Allerdings können weitere Verzeichnisse über <code>--bind</code> eingebunden werden, wodurch sich im Container die gleichen Pfade wie außerhalb nutzen lassen. Das wäre hier:
<code>apptainer run --bind /lustre,/software opensuse-15.6.sif</code>
Allerdings kann der Container dabei im Zweifelsfall nicht auf systemseitig angebotene Software oder Bibliotheken zugreifen. Diese lassen sich über einen Workaround ebenfalls einbinden. Der Pfad wird umgeschrieben und über die Umgebungsvariablen eingespielt. Hierbei ist es wichtig dass der Pfad zu der Systemsoftware ans Ende gehängt wird, denn die Pfade innerhalb des Containers sollen privilegiert werden.

Zum Beispiel liese sich der Container wie folgt starten:
<code>apptainer run --bind /bin:/bin_base,/usr:/usr_base,/lustre,/software opensuse-15.6.sif</code>
Und danach könne die Umgebungsvariablen mit den folgenden Befehelen gesetzt werden:
<## add the base software back in via path:
export PATH=$PATH:/usr_base/local/bin:/usr_base/bin:/bin_base
## ensure base OS libraries are included
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr_base/lib:/usr_base/lib64</code>
Dies geht so natürlich nur in einer interaktiven Session.

Soll ein Job über SLURM eingereicht werden, so muss dies automatisch geschehen. Dazu kannn <code>apptainer exec</code> genutzt werden. Es wird ein Bash-Script geschrieben welcher die Umgebungsvariablen exportiert (zum erweitern der Pfade) und benötigte Module lädt und dann eventuellen Code ausführt. Das Script muss hierbei ausführbar sein, woraus sich ein Aufruf wie folgt ergibt: <code>apptainer exec --bind /bin:/bin_base,/usr:/usr_base,/lustre,/software opensuse-15.6.sif executable_script.sh</code>

Ein minimaler Container mit openSUSE 15.6 ist unter <code>/software/containers/opensuse-15.6.sif</code> verfügbar.

=== Bereitgestellte Container ===
Manche Programme werden von den Entwicklern bereits containerisiert angeboten. In diesem Fall sollte zuerst sichergestellt werden dass die Umgebungsvariable <code>APPTAINER_CACHEDIR</code> gesetzt ist, idealerweise mit einem Verweis auf das Lustre wie folgt:
<code>export APPTAINER_CACHEDIR=/lustre/department/username/apptainer</code>
Viele Container werden als Docker-Image bereitgestellt und können direkt verwendet werden. Als Beispiel wird hier Reaction Mechanism Generator vom MIT genutzt.

Auf der Docker-Hub Seite des Projekts wird folgender Befehl für die Nutzung von Docker bereitgestellt: ( <nowiki>https://hub.docker.com/r/reactionmechanismgenerator/rmg</nowiki> )
<code>docker pull reactionmechanismgenerator/rmg</code>
Da wir Apptainer anbieten ist der Aufruf üb er die Befehlszeile nicht identisch, aber sehr ähnlich: ( <nowiki>https://apptainer.org/docs/user/main/cli/apptainer_pull.html</nowiki> )
<code>apptainer pull docker://reactionmechanismgenerator/rmg</code>

Containerisierung

2024-08-13T10:57:30Z

Mielczad: Containerisierung - erste Version

Während im HPC-Bereich Software traditionnel direkt auf den Compute-Nodes ausgeführt wird, hat sich in den letzten Jahren auch die Nutzung eine Containerumgebung für bestimmte Anwendungsfâlle etabliert. Ein bekanntes Problem auf Compute-Clustern ist der Bedarf an einer neuerern glibc-Standardbibliothek welche durch Ihre tiefe Verwurzelung in Linux nicht ohne Weiteres angeboten werden kann. Die Containeriesrung kann es ermöglichen Software auszuführen welche sonst nicht gebaut werden kann oder nicht lauffähig ist.

Docker als bekannteste Conainerisierung ist hierbei im HPC aufgrund der Root-Rechte auf einem von Nutzern geteilten HPC Cluster problematisch. Darum wurde eine Containerisierung am Lawrence Berkeley National Laboratory Entwickelt welche nur im Userspace läuft, heute unter dem Namen Apptainer bekannt ( <nowiki>https://apptainer.org/</nowiki> ) - diese bieten wir den Nutzern auf unseren Ressourcen an. (Anmerkung: das Projekt startete ursprünglich unter dem Namen Singularity, Apptainer ist mit Singularity. SingularityCE its ein alternativer Fork.)

Container für Apptainer können in Apptainer selbst gebaut werden, oder aber auch in Docker und dann konvertiert werden. Wer sich Container über die Docker-Route selbst bauen möchte, benötigt hierfür seinen eigenen Computer. Alternativ kann Apptainer auch Images direkt vom Docker-Hub herunterladen sofern ein Image zu VerFûgung steht.

Wichtig is hierbei dass die Umgebungsvariable <code>APPTAINER_CACHEDIR</code> zum Einstellen des Cache-Ordners so gewählt wird, dass sich dieses auf dem Lustre-Dateisystem befindet. Zum Bespiel wie folgt:
<code>export APPTAINER_CACHEDIR=/lustre/department/username/apptainer</code>

=== Ein Minimales openSUSE 15.6 als glibc Overlay ===
Bei einem unserer Nutzer befindet sich ein minimales openSUSE 15.6 als Overlay im Testbetrieb um eine neuere glibc anzubieten.

Dazu wird ein Docker-Container mit openSUSE Leap 15.6 aufgesetzt, in welchem zusätlzich noch lua-lmod installiert wird. Letzteres wird benötigt um die Modules-Umgebung zu unterstützen. Wichtige Anmerkung, damit zypper korrekt funktioniert, benötigt es ein "clean" sowie "refresh". Dies ist mit dem folgenden Dockerfile möglich:
<code># syntax=docker/dockerfile:1

# use Leap as a basis to reduce differences
FROM opensuse/leap:15.6

RUN zypper clean --all
RUN zypper ref

# the container needs to bring its own lmod along
RUN zypper -n install lua-lmod

RUN bash</code>
Danach kann der Container mit <code>docker build . -t opensuse-15.6</code> gebaut werden.

Ist der Docker-Container lokal aufgesetzt, kann dieser in eine Apptainer sif-Datei umgewandelt werden, und zwar wie folg: <code>apptainer build opensuse-15.6.sif docker-daemon://opensuse-15.6:latest</code> Hier ist es wichtig entweder den Tag (fals vorhanden) oder <code>:latest</code> anzugeben, sonst wird die Datei nicht erstellt.

Die nun erstellte Datei ist der Container welcher sich nun in einer HPC-Umgebung - mit Nutzerrechtne - verwenden lässt. In einer interaktiven Session würde der Container mit <code>apptainer run opensuse-15.6.sif</code> ausgeführt. Dies ist an sich zuerst nicht besonders nützlich da nur das Home-Verzeichnis benutzbar ist. Allerdings können weitere Verzeichnisse über <code>--bind</code> eingebunden werden, wodurch sich im Container die gleichen Pfade wie außerhalb nutzen lassen. Das wäre hier:
<code>apptainer run --bind /lustre,/software opensuse-15.6.sif</code>
Allerdings kann der Container dabei im Zweifelsfall nicht auf systemseitig angebotene Software oder Bibliotheken zugreifen. Diese lassen sich über einen Workaround ebenfalls einbinden. Der Pfad wird umgeschrieben und über die Umgebungsvariablen eingespielt. Hierbei ist es wichtig dass der Pfad zu der Systemsoftware ans Ende gehängt wird, denn die Pfade innerhalb des Containers sollen privilegiert werden.

Zum Beispiel liese sich der Container wie folgt starten:
<code>apptainer run --bind /bin:/bin_base,/usr:/usr_base,/lustre,/software opensuse-15.6.sif</code>
Und danach könne die Umgebungsvariablen mit den folgenden Befehelen gesetzt werden:
<code>## add the base software back in via path:
export PATH=$PATH:/usr_base/local/bin:/usr_base/bin:/bin_base
## ensure base OS libraries are included
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr_base/lib:/usr_base/lib64</code>
Dies geht so natürlich nur in einer interaktiven Session.

Soll ein Job über SLURM eingereicht werden, so muss dies automatisch geschehen. Dazu kannn <code>apptainer exec</code> genutzt werden. Es wird ein Bash-Script geschrieben welcher die Umgebungsvariablen exportiert (zum erweitern der Pfade) und benötigte Module lädt und dann eventuellen Code ausführt. Das Script muss hierbei ausführbar sein, woraus sich ein Aufruf wie folgt ergibt: <code>apptainer exec --bind /bin:/bin_base,/usr:/usr_base,/lustre,/software opensuse-15.6.sif executable_script.sh</code>

Ein minimaler Container mit openSUSE 15.6 ist unter <code>/software/containers/opensuse-15.6.sif</code> verfügbar.

Hauptseite

2024-08-13T10:56:46Z

Mielczad: /* Slurm Cluster */ - Containerisierung

Der Service '''"HPC@HU'''" stellt folgende Dienste zur Verfügung:

# Zentraler Slurm-Cluster
# Azimuth-Service

Beide Services bieten die Möglichkeit, die HPC-Infrastruktur der HU zu nutzen. Dabei bietet der Slurm-Cluster eine Vielzahl an Softwarepaketen und ist direkt mit dem HU-Account nutzbar, wohingegen der Azimuth-Service größere Flexibilität ermöglicht und u.a. auch andere Platformen wie JupyterHub zur Verfügung stellt.

== Slurm Cluster ==
Der zentrale Slurm-Cluster ist nach Anmeldung per Mail direkt mit dem HU-Account nutzbar. Der Zugang erfolgt über ein Login-Knoten,

Weitere Informationen:

* [[Erste Verbindung/Einloggen]]
* [[Datenspeicher & Dateistruktur]]
* [[Modules & Verfügbare Software]]
* [[Containerisierung]]
* [[Jobs einreichen mit SLURM]]
* [[Mailingliste und Support]]
* [[FAQ]]

== Azimuth ==
Azimuth bietet die Möglichkeit, verschiedene Plattformen, die man auch dem HPC-Bereich kennt, zu erstellen und zu verwalten. Dazu gehört u.a.:

# Slurm-Cluster
# JupyterHub
# HPC-Workstation

Die NutzerInnen können nach der Erstellung, die gewählte Plattform selbständig verwalten und erweitern. Dazu bekommen sie einen Administratorenzugang. Zur Zeit ist die Lebensdauer der Plattform nicht begrenzt.

Der Zugang zum Azimuth-Service erfolgt über den DV-Beauftragten der Einrichtung.

Jobs einreichen mit SLURM

2024-08-06T11:40:44Z

Mielczad: Interaktive Sessions hinzugefügt

==== Einführung ====
Der Queue-Manager für HPC@HU ist SLURM ( siehe https://slurm.schedmd.com/quickstart.html )

Ein Beispiel kann wie folgt aussehen:
<code>#!/bin/bash</code>
<code>#SBATCH --ntasks=1 # Run on a single CPU</code>
<code>#SBATCH --mem=1gb # Job memory request</code>
<code>#SBATCH --time=00:05:00 # Time limit hrs:min:sec</code>
<code>#SBATCH --partition=std</code>
<code>#SBATCH --account=nutzername</code>

<code>hostname</code>
Hier steht hostname beispielhaft für einen Script oder die Ausführung einer Software für Berechnungen.

Sollten im Script Variablen gesetzt werden, ist es wichtig dass dies erst nach der Definition des Jobs für SLURM geschieht.

Nennt sich der Scirpt <code>submit.bash</code> , lässt sich dieser dann über
sbatch submit.bash
beim Scheduler einreichen.

Der aktuelle Status lässt sich über
squeue
oder
squeue -u Nutzername
abfragen.

==== Parallelisierung mit mehreren Compute-Knoten: ====
Es ist möglich Berechnungen über mehrere Compute-Knoten laufen zu lassen. Hierbei sollte bedacht werden, dass Abhängig von den Virtuellen Maschinen in der aktuellen Konfiguration, die Kommunikation lokal auf einem Server oder über 100GBit/s Ethernet stattfindet.

Hierbei ist die Integration von openMPI und SLURM von der Nutzerseite einfach zu handhaben.

Um eine Berechnung über 2 Compute-Knoten laufen zu lassen, definiere ich zum Beispiel meine Anzahl an Threads sowie die Anzahl der Knoten:

#!/bin/bash
#SBATCH --ntasks=40 # Run 40 threads/processes
#SBATCH --ntasks-per-node=20 # Run 20 per compute node
#SBATCH --nodes=2 # Run on 2 nodes
#SBATCH --mem=80gb # Job memory needed per node (per node is important!!)
#SBATCH --time=96:00:00 # Time limit hrs:min:sec
#SBATCH --partition=std
#SBATCH --account=<user account>

Danach rufe ich mein Programm ganz gewöhnlich über mpirun auf.

Der Aufruf des Programms (hier xhpl) sieht dann wie folgt aus:
mpirun -np 40 xhpl

=== Interaktive Sessions ===
Es ist möglich interaktive Sessions auf den Compute Knoten zu starten. Hierbei müsse die Ressourcen direkt auf der Befehlszeile angefordert werden, zum Beispiel wie folgt:
<code>srun --nodes=1 --exclusive --pty bash -i</code>
oder auch
<code>srun --nodes=1 --ntasks-per-node=1 --time=01:00:00 --pty bash -i</code>

==== Verfügbare Ressourcen: ====
Aktuell eingerichtete virtuelle Maschinen verfügen über je:
* 64 Threads (ûber 32 Kerne)
* 256GB Arbeitsspeicher
* knapp 1,5TB lokalen scratch

FAQ

2024-08-01T07:13:14Z

Mielczad: Erweiterung des FAQ, OpenMP mit openMPI

Das zukünftige FAQ - welches sich, folgend der Erfahrung mit Nutzeranfragen, im Aufbau befindet:

== Wie fordere Ich Software an ==
Dem Nutzer werden eine ganze Reihe von Bibliotheken sowie Software über die Modules-Umgebung zu Verfügung gestellt. Diese werden unter [[Modules & Verfûgbare Software]] vorgestellt.

Sollte eine erwünschte Software oder Bibliothek fehlen, können wir diese (je nach Lizenzbedingungen) nach einer Anfrage zu Verfügung stellen. Dies ist im großen und ganzen über eine formlose Email an hpc-support@hu-berlin.de möglich.

Hierbei sind Links zu der Software hilfreich, sowie eventuell vorhandene Test-Jobs mit denen sich die Funktionalität testen lässt, inklusive der nötigen Befehle um die Software auszuführen.

== Wie melde Ich ein Softwareproblem ==
In den meisten Fällen werden Software und Bibliotheken mit Standardeinstellungen kompiliert und bereitgestellt. Dies ist häufig ausreichend.

Manchmal ist es allerdings notwendig bestimmte Argumente oder "Flags" zu setzen, zum Beispiel um zum Beispiel CUDA-Support zu aktivieren. In solch einem Fall würde das Ausführen einer Bibliothek ohne CUDA-Support mit CUDA zu einem Fehler führen. (CUDA wird hier nur beispielhaft genutzt.)

Sollte ein Fehler auftreten, sollte dieser möglichst vollumfänglich kopiert werde. Ferner sind die Eingaben von Interesse: wie wurde eine Software/Bibliothek genutzt, welche ist es, welche Argumente wurden genutzt. Idealerweise sollte auch eine Testdatei zu Verfügung gestellt werden damit das Problem nachvolzogen und reproduziert werden kann. Hierbei sollte die Testdatei idealerweise schnell das Problem aufzeigen können, das beaknnte "minimum working example".

Dies kann dann über eine formlose Email an hpc-support@hu-berlin.de geschickt werden.

== OpenMP mit OpenMPI ==
Grundsätzlich soll die Nutzung von OpenMP in Kombination mit OpenMPI Môglich sein. Dadurch lassen sich das geringere "Overheaded" von "Shared Memory Processing" (Threading) mit der Skallierung des MPI-Multi-Process-Asatz kombinieren.

In einem uns bekannten Fall gab es Probleme bei der Verwaltung der Threads in einem OpenSource Fortran-Programm.

Sollten unerwartet Probleme auftreten, sind folgenden Variablen/Parameter zu überprüfen:

Die Variable<code>OMP_NUM_THREADS</code> welche die Anzahl der OpenMP-Threads festlegt sollte exportiert werden, sowie die Option <code>--bind-to none</code> beim Aufruf mit OpenMPI genutzt werden.

Ein Aufruf in einem Script sähe dann für 4 Threads und zwei Prozesse wie folgt aus:
<code>export OMP_NUM_THREADS=4
mpirun --bind-to none -np 2 meine_Software</code>

Modules & Verfügbare Software

2024-07-31T13:22:31Z

Mielczad: /* Programmiersprachen und Compiler */

==== Übersicht & Grundlagen zur Nuzung ====
Die bereitgestellten Compute-Knoten nutzen Linux, genaugenommen ein OpenSUSE.

HPC-typisch wird zentral Software bereitgestellt. Verfügbare Software wird über eine Modulumgebung geladen.

Welche Software verfügbar ist, lässt sich über <code>module avail</code> sowie <code>module spider <name></code> in Erfahrung bringen.

(Online Anleitung für lmod https://lmod.readthedocs.io/en/latest/010_user.html )

Wir bieten aktuell drei Gruppe von Software an:

# /hu "Von Uns" kompilierte Software welche zentral bereitgestellt wird.
# /all Über EasyBuild ( siehe http://docs.easybuild.io/what-is-easybuild/ ) bereitgestellte Software
# /intel Software welche mit Installer ausgeliefert wurde (wie zum Beispiel Intel OneAPI)

Bei der Auswahl von Software sollte darauf geachtet werden dass die Groß- und Kleinschreibung von Bedeutung ist, sprich gcc ist nicht gleich GCC.

Die finalen Pfade sind aktuell auch nicht endgültig festgelegt und können sich noch verändern.

Ferner wird empfohlen sich nicht auf die Defaults zu verlassen und die Version einer Software explizit auszuwählen.

Anwendungsbeispiel:

Die verfügbaren openmpi Versionen lassen sich mit dem Befehl
module spider openmpi
erfragen

Ist daraufhin die Version erwünscht, lässt sich diese mit dem Befehl
module load openmpi/5.0.3-gcc14.1.0
laden.

Aktuell geladene Module lassen sich mit
module list
anzeigen, während
module purge
alle geladenen Module "entlädt".

Aktuell wird die verfügbare Software noch ausgebaut, wodurch sich die Liste relativ schnell entwickelt. Für einen Überblick der aktuell verfügbaren Software wird gebeten diese direkt auf dem System abzufragen. Vor allem mit EasyBuild installierte Software bringt standardmäßig sehr viele kleine Abhängigkeiten mit.

Einen ersten Überblick über einige der wichtigeren Pakete (als Eigenkompilation) bietet die folgende Liste:

==== Verfügbare Software ====

===== Programmiersprachen und Compiler =====
- AMD aocc

- 4.2.0

- gcc

- 9.5.0

- 10.5.0

- 11.4.0

- 12.3.0

- 13.2.0

- 14.1.0

- Intel OneApi

- 2024.1

- Julia

- 1.10.3

- python

- 3.8.19

- 3.9.19

- 3.10.14

- 3.11.9

- 3.12.3

- QT (opensource)

- 5.15.14

- R

- 4.4.0

- ruby

- 3.3

===== Bibliotheken und Tools =====
- AMD AOCL

- 4.2.0 gcc

- 4.2.0 aocl

- apache-maven

- 3.9.8

- bash

- 5.2.21

- bc

- 1.0.7

- bison

- 3.8.2

- BLIS

- 4.2.0

- block2

- p0.5.3rc13 openmpi/5.0.3 gcc/14.1.0 OpenBLAS/0.3.26

- boost

- 1.85 gcc/13.2.0

- 1.85 gcc/14.1.0

- Catch2

- 3.6.0 cmake/3.29.3

- cmake

- 3.16.9

- 3.20.6

- 3.27.2

- 3.29.2

- 3.29.3

- costa

2.2.2

- cuda

- 10

- 11

- 12.0

- 12

- 12.1

- 12.2

- 12.3

- 12.4

- 12.4.1

- crest

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc13.2.0 openmpi/5.0.3-gcc13.2.0 gcc/13.2.0

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc14.1.0 openmpi/5.0.3-gcc14.1.0 gcc/14.1.0

fftw

- 3.3.0 gcc/14.1.0

- 3.3.0 openmpi/5.0.3 gcc/14.1.0

- flex

- 2.6.4

- fmt

- 10.2.1

- gsl

- 2.8

- hdf5

- 1.14.4.3

- lapack

- 3.12.0 gcc/13.2.0

- 3.12.0 gcc/14.1.0

- libflame

- 4.2.0

- libunwind

- 1.8.1

- libxc

- 6.6.2

- magma

- 2.8.8

- miniforge3

- 24.1.2-0

- mpich

- 3.2.0 gcc/12.3.0

- 3.3.0 gcc/12.3.0

- 4.1.3 gcc/12.3.0

- 4.2.1 gcc/14.1.0

- OpenBLAS

- 0.3.26 gcc/13.2.0

- 0.3.26 gcc/14.1.0

- OpenCoarrays

- 2.9.3 mpich/3.3.0 gcc/12.3.0

- 2.10.2 openmpi/5.0.3 gcc/14.1.0

- OpenMPI

- 4.1.6 gcc/13.2.0

- 5.0.3 gcc/13.2.0

- 5.0.3 gcc/14.1.0

- patch

- 2.7.6

- proj

- 9.4.1 gcc/14.1.0

- scalapack

- 2.2.0

- spglib

- 2.4.0 gcc/14.1.0

- sirius

- 7.5.2

- spla

- 1.6.1

- swig

- 4.2.1

- szip

- 2.1.1

- umpire

- 2024.02.01

===== Software =====
- gdal

- 3.9.0 gcc/14.1.0 proj/9.4.1 swig/4.2.1 python/3.12.3

- hadoopp

- 3.4.0

- hpl

- v2.3

- ior

- 4.0.0 openmpi/5.0.3 gcc/14.1.0

- ncdu

- 1.20

- OpenFOAM

- 11

- v2312

- ORCA

- 5.0.4

- quantum-espresso

- 7.3.1 OpenBLAS/0.3.26 fftw/3.3.10 penmpi/5.0.3 gcc/14.1.0

- xtb

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/13.2.0

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/14.1.0

===== Fehlt was? =====
Da es sich beim HPC um ein Linux System handelt, ist es möglich eigene Software zu entwickeln. Die Einbindung von Software findet überwiegend über zwei grundlegende Variablen statt. <code>PATH</code> für ausführbare Binärdateien sowie <code>LD_LIBRARY_PATH</code> für verlinkte Bibliotheken.

Über ein <code>export PATH=/new/path:$PATH</code> sowie <code>export LD_LIBRARY_PATH=/new/path:$LD_LIBRARY_PATH</code> lassen sich beide erweitern. Diese Änderung gilt bis zum verlassen der Shell - oder ist "semi-permanent" wenn der Export in die .profile oder .bashrc Datei eingetragen wird.

Hierbei gilt es ferner zu beachten dass die Reihenfolge der Auflistung der verschiedenen Pfade von Bedeutung ist: die zuerst gefundene Variante wird genommen.

Obschon es möglich ist eine Software zu kompilieren, bitten wir darum bei fehlender freier Software nach Möglichkeit zuerst eine Anfrage an [mailto:hpc-support@hu-berlin.de hpc-support@hu-berlin.de] zu schicken, damit diese zentral für Alle zugänglich ist.

Bei Anfragen zu kommerzieller Software, internen Eigenentwicklungen oder anderweitig speziell lizenzierter Software stehen wir ebenfalls gerne zu Verfügung.

==== Python, Anaconda, Conda, Mamba ====

===== Python =====
Python wird in vielen Projekten eingesetzt. Die Nutzung von Python ist nicht immer problemfrei, darum gibt es folgend einige Empfehlungen für die Nutzung von Python, welche das Risiko von Problemen sowie die Problembeseitigung erleichtern.

Im Allgemeinen sollten Python Anwendungen in einer virtuellen Umgebung entwickelt und ausgeführt werden. Diese wird nativ von Python unterstützt und ermöglicht es Pakete auf einer bestimmten Version zu halten sowie eventuelle Inkompatibilitäten zwischen verschiedenen Projekten zu vermeiden. Ferner ist es möglich bei Problemen eine virtuelle Umgebung zu löschen und dadurch alte Pakete Rückstandslos zu entfernen. Das ist vor allem interessant da pip oder pip3 Abhängigkeiten installieren kann, aber im Gegensatz zu typischen Linux-Paketmanagern Abhängigkeiten nicht automatisch deinstallieren kann.

Eine virtuelle Umgebung kann wie folgt erstellt werden (mit einem relativen oder absoluten Pfad):
<code>python -m venv /Pfad/zur/neuen/virtuellen_Umgebung</code>
Mehr dazu auf in der Dokumentation von Python: <nowiki>https://docs.python.org/3/library/venv.html</nowiki>

Sollte es aus bestimmten Gründen nicht möglich sein eine virtuelle Umgebung zu nutzen, kann man mit pip Pakete in einem bestimmten Ordner installieren.
<code>pip3 install --target /Pfad/zum/ZielOrdner</code>
Danach kann der Ordner zur Variable PYTHONPATH hinzugefügt werden und wird dann von der Python-Umgebung erkannt.

Die virtuellen Umgebungen sind im Allgemeinen jedoch zu präferieren.

===== Anaconda, Conda, Mamba =====
Eine weitere Alternative ist die Nutzung einer Packetverwaltung in Python, so wie diese über Anaconda/conda/mamba angeboten wird, bei dieser ist der Funktionsumfang dann auch größer als be pip.

Hierbei werden Nutzer und Nutzerinnen angehalten die Nutzungsbedingungen von vor allem Anaconda und Miniconda zu beachten. Aktuell (Juli 2024) wird Miniforge unter der BSD Lizenz angeboten und ist in in Bezug auf die Nutzung.

Während eine zentrale Installation von conda und mamba über miniforge3 bereitgestellt wird, haben normale Nutzer keine Schreibrechte in dem zentralen Installationsordner. Standardmäßig wird conda/mamba daraufhin versuchen einen Ordner im Home-Verzeichnis anzulegen, alternativ kann ein expliziter Prefix wie folgt angegeben werden.
<code>conda create --prefix /Pfad/zur/neuen/conda_Umgebung</code>
Für typische Nutzertools wird darum empfohlen eine eigene Installation von miniforge aufzusetzen und eigene Umgebungen zu verwalten. Bei der Einrichtung muss dann nur darauf geachtet werden dass der Installationspfad korrekt eingegeben wird. Da eine solche Installation mit der Zeit recht groß werden kann, wird empfohlen dass lustre Dateisystem zu nutzen, der Pfad würde dementsprechend <code>/lustre/<Fakultät>/<Benutzername></code> lauten.

Mit <code>conda init</code> oder <code>mamba init</code> wird die Umgebung initiialisiert und die .bashrc Datei angepasst. Dabei werden eventuell existierende conda/mamba Konfigurationen überschrieben (!!!). Dies ist beim benutzen von mehreren Versionen potenziell problematisch und erfordert eine manuelle Anpassung der Skripte sowie potenziell deren Auslagerung in individuelle Dateien.

==== Persönliche Module ====
Es ist möglich eigene Module in <code>lmod</code> einzubinden, wie in der Dokumentation beschrieben: <nowiki>https://lmod.readthedocs.io/en/latest/020_advanced.html</nowiki>

Eine Môglichkeit besteht in dem Befehl <code>module use /path/to/personal/modulefiles</code>, alternativ kann der Pfad zu privaten Moduldateien auch gleich zur Variable <code>$MODULEPATH</code> hinzugefügt werden.

Informationen bezüglich des Aufbaus der Moduldateien finden sich in der lmod-Dokumentation auf der Webseite. Ebenso können die bereitgestellten Module unter <code>/software/modules</code> als Inspiration dienen.

==== Für Nutzer: ====
Für Nutzer von HPC@HU finden sich unter <code>/software/modules/software.md</code> weitere Informationen über die verfügbare Software und wie diese gebaut/konfiguriert wurde.

Modules & Verfügbare Software

2024-07-31T12:17:40Z

Mielczad: Die Seite wurde neu angelegt: „==== Übersicht & Grundlagen zur Nuzung ==== Die bereitgestellten Compute-Knoten nutzen Linux, genaugenommen ein OpenSUSE. HPC-typisch wird zentral Software bereitgestellt. Verfügbare Software wird über eine Modulumgebung geladen. Welche Software verfügbar ist, lässt sich über <code>module avail</code> sowie <code>module spider <name></code> in Erfahrung bringen. (Online Anleitung für lmod https://lmod.readthedocs.io/en/latest/010_user.html ) Wi…“

==== Übersicht & Grundlagen zur Nuzung ====
Die bereitgestellten Compute-Knoten nutzen Linux, genaugenommen ein OpenSUSE.

HPC-typisch wird zentral Software bereitgestellt. Verfügbare Software wird über eine Modulumgebung geladen.

Welche Software verfügbar ist, lässt sich über <code>module avail</code> sowie <code>module spider <name></code> in Erfahrung bringen.

(Online Anleitung für lmod https://lmod.readthedocs.io/en/latest/010_user.html )

Wir bieten aktuell drei Gruppe von Software an:

# /hu "Von Uns" kompilierte Software welche zentral bereitgestellt wird.
# /all Über EasyBuild ( siehe http://docs.easybuild.io/what-is-easybuild/ ) bereitgestellte Software
# /intel Software welche mit Installer ausgeliefert wurde (wie zum Beispiel Intel OneAPI)

Bei der Auswahl von Software sollte darauf geachtet werden dass die Groß- und Kleinschreibung von Bedeutung ist, sprich gcc ist nicht gleich GCC.

Die finalen Pfade sind aktuell auch nicht endgültig festgelegt und können sich noch verändern.

Ferner wird empfohlen sich nicht auf die Defaults zu verlassen und die Version einer Software explizit auszuwählen.

Anwendungsbeispiel:

Die verfügbaren openmpi Versionen lassen sich mit dem Befehl
module spider openmpi
erfragen

Ist daraufhin die Version erwünscht, lässt sich diese mit dem Befehl
module load openmpi/5.0.3-gcc14.1.0
laden.

Aktuell geladene Module lassen sich mit
module list
anzeigen, während
module purge
alle geladenen Module "entlädt".

Aktuell wird die verfügbare Software noch ausgebaut, wodurch sich die Liste relativ schnell entwickelt. Für einen Überblick der aktuell verfügbaren Software wird gebeten diese direkt auf dem System abzufragen. Vor allem mit EasyBuild installierte Software bringt standardmäßig sehr viele kleine Abhängigkeiten mit.

Einen ersten Überblick über einige der wichtigeren Pakete (als Eigenkompilation) bietet die folgende Liste:

==== Verfügbare Software ====

===== Programmiersprachen und Compiler =====
- gcc

- 9.5.0

- 10.5.0

- 11.4.0

- 12.3.0

- 13.2.0

- 14.1.0

- Intel OneApi

- 2024.1

- Julia

- 1.10.3

- python

- 3.8.19

- 3.9.19

- 3.10.14

- 3.11.9

- 3.12.3

- QT (opensource)

- 5.15.14

- R

- 4.4.0

- ruby

- 3.3

===== Bibliotheken und Tools =====
- AMD AOCL

- 4.2.0 gcc

- 4.2.0 aocl

- apache-maven

- 3.9.8

- bash

- 5.2.21

- bc

- 1.0.7

- bison

- 3.8.2

- BLIS

- 4.2.0

- block2

- p0.5.3rc13 openmpi/5.0.3 gcc/14.1.0 OpenBLAS/0.3.26

- boost

- 1.85 gcc/13.2.0

- 1.85 gcc/14.1.0

- Catch2

- 3.6.0 cmake/3.29.3

- cmake

- 3.16.9

- 3.20.6

- 3.27.2

- 3.29.2

- 3.29.3

- costa

2.2.2

- cuda

- 10

- 11

- 12.0

- 12

- 12.1

- 12.2

- 12.3

- 12.4

- 12.4.1

- crest

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc13.2.0 openmpi/5.0.3-gcc13.2.0 gcc/13.2.0

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc14.1.0 openmpi/5.0.3-gcc14.1.0 gcc/14.1.0

fftw

- 3.3.0 gcc/14.1.0

- 3.3.0 openmpi/5.0.3 gcc/14.1.0

- flex

- 2.6.4

- fmt

- 10.2.1

- gsl

- 2.8

- hdf5

- 1.14.4.3

- lapack

- 3.12.0 gcc/13.2.0

- 3.12.0 gcc/14.1.0

- libflame

- 4.2.0

- libunwind

- 1.8.1

- libxc

- 6.6.2

- magma

- 2.8.8

- miniforge3

- 24.1.2-0

- mpich

- 3.2.0 gcc/12.3.0

- 3.3.0 gcc/12.3.0

- 4.1.3 gcc/12.3.0

- 4.2.1 gcc/14.1.0

- OpenBLAS

- 0.3.26 gcc/13.2.0

- 0.3.26 gcc/14.1.0

- OpenCoarrays

- 2.9.3 mpich/3.3.0 gcc/12.3.0

- 2.10.2 openmpi/5.0.3 gcc/14.1.0

- OpenMPI

- 4.1.6 gcc/13.2.0

- 5.0.3 gcc/13.2.0

- 5.0.3 gcc/14.1.0

- patch

- 2.7.6

- proj

- 9.4.1 gcc/14.1.0

- scalapack

- 2.2.0

- spglib

- 2.4.0 gcc/14.1.0

- sirius

- 7.5.2

- spla

- 1.6.1

- swig

- 4.2.1

- szip

- 2.1.1

- umpire

- 2024.02.01

===== Software =====
- gdal

- 3.9.0 gcc/14.1.0 proj/9.4.1 swig/4.2.1 python/3.12.3

- hadoopp

- 3.4.0

- hpl

- v2.3

- ior

- 4.0.0 openmpi/5.0.3 gcc/14.1.0

- ncdu

- 1.20

- OpenFOAM

- 11

- v2312

- ORCA

- 5.0.4

- quantum-espresso

- 7.3.1 OpenBLAS/0.3.26 fftw/3.3.10 penmpi/5.0.3 gcc/14.1.0

- xtb

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/13.2.0

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/14.1.0

===== Fehlt was? =====
Da es sich beim HPC um ein Linux System handelt, ist es möglich eigene Software zu entwickeln. Die Einbindung von Software findet überwiegend über zwei grundlegende Variablen statt. <code>PATH</code> für ausführbare Binärdateien sowie <code>LD_LIBRARY_PATH</code> für verlinkte Bibliotheken.

Über ein <code>export PATH=/new/path:$PATH</code> sowie <code>export LD_LIBRARY_PATH=/new/path:$LD_LIBRARY_PATH</code> lassen sich beide erweitern. Diese Änderung gilt bis zum verlassen der Shell - oder ist "semi-permanent" wenn der Export in die .profile oder .bashrc Datei eingetragen wird.

Hierbei gilt es ferner zu beachten dass die Reihenfolge der Auflistung der verschiedenen Pfade von Bedeutung ist: die zuerst gefundene Variante wird genommen.

Obschon es möglich ist eine Software zu kompilieren, bitten wir darum bei fehlender freier Software nach Möglichkeit zuerst eine Anfrage an [mailto:hpc-support@hu-berlin.de hpc-support@hu-berlin.de] zu schicken, damit diese zentral für Alle zugänglich ist.

Bei Anfragen zu kommerzieller Software, internen Eigenentwicklungen oder anderweitig speziell lizenzierter Software stehen wir ebenfalls gerne zu Verfügung.

==== Python, Anaconda, Conda, Mamba ====

===== Python =====
Python wird in vielen Projekten eingesetzt. Die Nutzung von Python ist nicht immer problemfrei, darum gibt es folgend einige Empfehlungen für die Nutzung von Python, welche das Risiko von Problemen sowie die Problembeseitigung erleichtern.

Im Allgemeinen sollten Python Anwendungen in einer virtuellen Umgebung entwickelt und ausgeführt werden. Diese wird nativ von Python unterstützt und ermöglicht es Pakete auf einer bestimmten Version zu halten sowie eventuelle Inkompatibilitäten zwischen verschiedenen Projekten zu vermeiden. Ferner ist es möglich bei Problemen eine virtuelle Umgebung zu löschen und dadurch alte Pakete Rückstandslos zu entfernen. Das ist vor allem interessant da pip oder pip3 Abhängigkeiten installieren kann, aber im Gegensatz zu typischen Linux-Paketmanagern Abhängigkeiten nicht automatisch deinstallieren kann.

Eine virtuelle Umgebung kann wie folgt erstellt werden (mit einem relativen oder absoluten Pfad):
<code>python -m venv /Pfad/zur/neuen/virtuellen_Umgebung</code>
Mehr dazu auf in der Dokumentation von Python: <nowiki>https://docs.python.org/3/library/venv.html</nowiki>

Sollte es aus bestimmten Gründen nicht möglich sein eine virtuelle Umgebung zu nutzen, kann man mit pip Pakete in einem bestimmten Ordner installieren.
<code>pip3 install --target /Pfad/zum/ZielOrdner</code>
Danach kann der Ordner zur Variable PYTHONPATH hinzugefügt werden und wird dann von der Python-Umgebung erkannt.

Die virtuellen Umgebungen sind im Allgemeinen jedoch zu präferieren.

===== Anaconda, Conda, Mamba =====
Eine weitere Alternative ist die Nutzung einer Packetverwaltung in Python, so wie diese über Anaconda/conda/mamba angeboten wird, bei dieser ist der Funktionsumfang dann auch größer als be pip.

Hierbei werden Nutzer und Nutzerinnen angehalten die Nutzungsbedingungen von vor allem Anaconda und Miniconda zu beachten. Aktuell (Juli 2024) wird Miniforge unter der BSD Lizenz angeboten und ist in in Bezug auf die Nutzung.

Während eine zentrale Installation von conda und mamba über miniforge3 bereitgestellt wird, haben normale Nutzer keine Schreibrechte in dem zentralen Installationsordner. Standardmäßig wird conda/mamba daraufhin versuchen einen Ordner im Home-Verzeichnis anzulegen, alternativ kann ein expliziter Prefix wie folgt angegeben werden.
<code>conda create --prefix /Pfad/zur/neuen/conda_Umgebung</code>
Für typische Nutzertools wird darum empfohlen eine eigene Installation von miniforge aufzusetzen und eigene Umgebungen zu verwalten. Bei der Einrichtung muss dann nur darauf geachtet werden dass der Installationspfad korrekt eingegeben wird. Da eine solche Installation mit der Zeit recht groß werden kann, wird empfohlen dass lustre Dateisystem zu nutzen, der Pfad würde dementsprechend <code>/lustre/<Fakultät>/<Benutzername></code> lauten.

Mit <code>conda init</code> oder <code>mamba init</code> wird die Umgebung initiialisiert und die .bashrc Datei angepasst. Dabei werden eventuell existierende conda/mamba Konfigurationen überschrieben (!!!). Dies ist beim benutzen von mehreren Versionen potenziell problematisch und erfordert eine manuelle Anpassung der Skripte sowie potenziell deren Auslagerung in individuelle Dateien.

==== Persönliche Module ====
Es ist möglich eigene Module in <code>lmod</code> einzubinden, wie in der Dokumentation beschrieben: <nowiki>https://lmod.readthedocs.io/en/latest/020_advanced.html</nowiki>

Eine Môglichkeit besteht in dem Befehl <code>module use /path/to/personal/modulefiles</code>, alternativ kann der Pfad zu privaten Moduldateien auch gleich zur Variable <code>$MODULEPATH</code> hinzugefügt werden.

Informationen bezüglich des Aufbaus der Moduldateien finden sich in der lmod-Dokumentation auf der Webseite. Ebenso können die bereitgestellten Module unter <code>/software/modules</code> als Inspiration dienen.

==== Für Nutzer: ====
Für Nutzer von HPC@HU finden sich unter <code>/software/modules/software.md</code> weitere Informationen über die verfügbare Software und wie diese gebaut/konfiguriert wurde.

Hauptseite

2024-07-31T12:17:28Z

Mielczad: /* Slurm Cluster */

Der Service '''"HPC@HU'''" stellt folgende Dienste zur Verfügung:

# Zentraler Slurm-Cluster
# Azimuth-Service

Beide Services bieten die Möglichkeit, die HPC-Infrastruktur der HU zu nutzen. Dabei bietet der Slurm-Cluster eine Vielzahl an Softwarepaketen und ist direkt mit dem HU-Account nutzbar, wohingegen der Azimuth-Service größere Flexibilität ermöglicht und u.a. auch andere Platformen wie JupyterHub zur Verfügung stellt.

== Slurm Cluster ==
Der zentrale Slurm-Cluster ist nach Anmeldung per Mail direkt mit dem HU-Account nutzbar. Der Zugang erfolgt über ein Login-Knoten,

Weitere Informationen:

* [[Erste Verbindung/Einloggen]]
* [[Datenspeicher & Dateistruktur]]
* [[Modules & Verfügbare Software]]
* [[Jobs einreichen mit SLURM]]
* [[Mailingliste und Support]]
* [[FAQ]]

== Azimuth ==
Azimuth bietet die Möglichkeit, verschiedene Plattformen, die man auch dem HPC-Bereich kennt, zu erstellen und zu verwalten. Dazu gehört u.a.:

# Slurm-Cluster
# JupyterHub
# HPC-Workstation

Die NutzerInnen können nach der Erstellung, die gewählte Plattform selbständig verwalten und erweitern. Dazu bekommen sie einen Administratorenzugang. Zur Zeit ist die Lebensdauer der Plattform nicht begrenzt.

Der Zugang zum Azimuth-Service erfolgt über den DV-Beauftragten der Einrichtung.

Hauptseite

2024-07-31T12:16:49Z

Mielczad: /* Slurm Cluster */

Der Service '''"HPC@HU'''" stellt folgende Dienste zur Verfügung:

# Zentraler Slurm-Cluster
# Azimuth-Service

Beide Services bieten die Möglichkeit, die HPC-Infrastruktur der HU zu nutzen. Dabei bietet der Slurm-Cluster eine Vielzahl an Softwarepaketen und ist direkt mit dem HU-Account nutzbar, wohingegen der Azimuth-Service größere Flexibilität ermöglicht und u.a. auch andere Platformen wie JupyterHub zur Verfügung stellt.

== Slurm Cluster ==
Der zentrale Slurm-Cluster ist nach Anmeldung per Mail direkt mit dem HU-Account nutzbar. Der Zugang erfolgt über ein Login-Knoten,

Weitere Informationen:

* [[Erste Verbindung/Einloggen]]
* [[Datenspeicher & Dateistruktur]]
* [[Modules & Verfûgbare Software|Modules & Verfügbare Software]]
* [[Jobs einreichen mit SLURM]]
* [[Mailingliste und Support]]
* [[FAQ]]

== Azimuth ==
Azimuth bietet die Möglichkeit, verschiedene Plattformen, die man auch dem HPC-Bereich kennt, zu erstellen und zu verwalten. Dazu gehört u.a.:

# Slurm-Cluster
# JupyterHub
# HPC-Workstation

Die NutzerInnen können nach der Erstellung, die gewählte Plattform selbständig verwalten und erweitern. Dazu bekommen sie einen Administratorenzugang. Zur Zeit ist die Lebensdauer der Plattform nicht begrenzt.

Der Zugang zum Azimuth-Service erfolgt über den DV-Beauftragten der Einrichtung.

FAQ

2024-07-29T11:18:13Z

Mielczad: Link eingefügt, Korrektion von Rechtschreibfehlern

FAQ

2024-07-29T11:15:51Z

Mielczad: Erste Einträge im FAQ

Hauptseite

2024-07-25T13:31:57Z

Mielczad: /* Slurm Cluster */ Zusammenfassung von Datenspeicher und Dateistruktur

Der Service '''"HPC@HU'''" stellt folgende Dienste zur Verfügung:

# Zentraler Slurm-Cluster
# Azimuth-Service

Beide Services bieten die Möglichkeit, die HPC-Infrastruktur der HU zu nutzen. Dabei bietet der Slurm-Cluster eine Vielzahl an Softwarepaketen und ist direkt mit dem HU-Account nutzbar, wohingegen der Azimuth-Service größere Flexibilität ermöglicht und u.a. auch andere Platformen wie JupyterHub zur Verfügung stellt.

== Slurm Cluster ==
Der zentrale Slurm-Cluster ist nach Anmeldung per Mail direkt mit dem HU-Account nutzbar. Der Zugang erfolgt über ein Login-Knoten,

Weitere Informationen:

* [[Erste Verbindung/Einloggen]]
* [[Datenspeicher & Dateistruktur]]
* [[Modules & Verfûgbare Software]]
* [[Jobs einreichen mit SLURM]]
* [[Mailingliste und Support]]
* [[FAQ]]

== Azimuth ==
Azimuth bietet die Möglichkeit, verschiedene Plattformen, die man auch dem HPC-Bereich kennt, zu erstellen und zu verwalten. Dazu gehört u.a.:

# Slurm-Cluster
# JupyterHub
# HPC-Workstation

Die NutzerInnen können nach der Erstellung, die gewählte Plattform selbständig verwalten und erweitern. Dazu bekommen sie einen Administratorenzugang. Zur Zeit ist die Lebensdauer der Plattform nicht begrenzt.

Der Zugang zum Azimuth-Service erfolgt über den DV-Beauftragten der Einrichtung.

Datenspeicher & Dateistruktur

2024-07-25T13:31:35Z

Mielczad: Zusammenfassung der Seiten mit den Größen der Luafwerke sowie den Pfaden und Rechten

Auf dem Slurm-Cluster stehen auf jeder Maschine (Login- & Exec-Server) folgende Verzeichnisse zur Verfügung.
{| class="wikitable"
!Pfad
!Größe
!Sichtbarkeit
!Dauer
!Besonderheit
|-
|$HOME
|800GB
|global**
|unlimited
|
|-
|/tmp
|1.5TB
|local (Job)
|job-time
|autotmp_fs***
|-
|/dev/shm
|128GB
|local (Job)
|job-time
|autotmp_fs***
|-
|/lustre
|1.5PB
|global
|unlimited*
|
|}
<nowiki>*</nowiki>Die Daten werden zur Zeit erst bei sehr hoher Belegung gelöscht

<nowiki>**</nowiki>Die Verzeichnisse sind über NFS gemountet

<nowiki>***</nowiki>Die Verzeichnisse werden für jeden Job angelegt und gemountet. Andere Jobs sehen den Inhalt nicht. Verzeichnisse werden nach Job-Ende gelöscht.

Bei anderen Anforderungen bitten wir darum per Mail mit dem HPC-Support Kontakt aufzunehmen.

Um die Nutzung des lokalen scratch zu unterstützen wird das Plugin "auto_tmpdir" der University of Delaware genutzt (<nowiki>https://github.com/University-of-Delaware-IT-RCI/auto_tmpdir/tree/master</nowiki>).

Dieses Plugin erstellt einen dedizierten Ordner für einen ausgeführten job welcher dann unter /tmp erreichbar ist (sowie /var/tm und /dev/shm ).

Der Vorteil des Plugins ist, dass sich dieses um de Erstellung der Mounts sowie dem Löschen der Mounts und Dateien kümmert. Da die Dateien nach Ende des Jobs gelöscht werden, ist es wichtig die Ausgabe anderweitig zu "streamen" oder das Endergebnis zu kopieren.

Exemplarisch könnte ein Script für die Nutzung wie folgt aussehen:
<code>#!/bin/bash
#SBATCH --ntasks=1 # Run on a single CPU
#SBATCH --mem=1gb # Job memory request
#SBATCH --time=00:05:00 # Time limit hrs:min:sec
#SBATCH --partition=std
#SBATCH --account=nutzername

## set path to root of job data
basedir=/globalscratch/nutzername/myjob

## copy job data
cp -r $basedir/* /tmp
## change to working director
cd /tmp

## do the work
hostname > $basedir/result.log

## copy the results if they are required
cp -r /tmp/* $basedir</code>

== Zugriffsrechte: ==
Typisch für ein klassisches SLURM cluster, werden die regulären UNIX Rechte und Gruppen eingesetzt. Diese ermöglichen es Ordner auf dem geteilten Laufwerk nur für bestimmte Nutzer und Gruppen freizugeben. Allerdings ist die regulären Linux Rechteverwaltung hier in Bezug auf eine detaillierte Rechteverteilung stak eingeschränkt. (Da es nicht praktisch möglich ist für alle möglichen Kombinationen dedizierte Gruppen anzulegen.)

Eine feinere Rechteverwaltung, sofern notwendig ist über Access Control Lists (ACL) möglich.

In der der aktuellen Implementierung lassen sich diese über <code>getfacl</code> in Erfahrung bringen, über <code>setfacl</code> setzen oder modifizieren.

Die access control lists werden für den jeweiligen Benutzernamen gesetzt, welcher hier die User-ID des HU-Accounts ist.

Leserechte für eine Datei liesen sich wie folgt setzen:
<code>setfacl -m u:benutzername:r test-datei</code>
Rechte lassen sich ebenfalls rekursiv setzen, wodurch alle Dateien und Ordner abgedeckt sind.
<code>setfacl -Rm u:benutzername:r pfad-zur/test-datei</code>
Weiterführende Informationen zu Access Control Lists inklusive einer Erklärung der "flags" finden sich auf der Seite des Ohio Supercomputing Centre: <nowiki>https://www.osc.edu/resources/getting_started/howto/howto_manage_access_control_list_acls/howto_use_posix_acl</nowiki>

Sollte es notwendig sein die Zugriffsrechte auf spezifische Benutzer (und nicht nur einen Fachbereich) zu begrenzen wird folgender Vorgang empfohlen:

Die regulären UNIX/POSIX-Rechte werden auf den Eigentümer reduziert, ohne Zugriffsrechte für die Gruppe oder Welt. Dies entspräche einem <code>r-x------</code> (<code>500</code>) oder <code>rwx------</code> (<code>700</code>). Das Aufzeigen von Inhalten in Ordnern erfordert hierbei die Ausführungsrechte (<code>x</code>). Für Dateien welche nicht ausgeführt werden reichen Lese- und Schreibrechte (<code>r--</code> / <code>rw-</code> ).

Im nächsten Schritt werden berechtigen Nutzern über die ACLs Zugriffsrechte eingeräumt - der Gruppe bleibt hierbei weiter der Zugriff auf der POSIX-Basis verwehrt.

Anmerkung: Sollte die Vertraulichkeit von Daten eine Einschränkung der Zugriffsrechte erfordern, sollte im Allgemeinen minimalste Rechte eingeräumt werden. So wenige wie möglich, so viele wie erforderlich. Andererseits ist ein konventionelles HPC-Cluster nicht für hochsensible Daten ausgelegt. In diesem Fall bitten wir darum dass mit dem HPC-Team unter hpc-suppport@hu-berlin.de Kontakt aufgenommen wird um eventuelle Lösungsansätze zu besprechen.

== Externer Zugriff: ==
Der Zugriff auf das Dateisystem erfolgt über sftp (ftp ûber ssh) aus dem Netz der Humboldt Universität heraus.

Die ist unter Windows mit WinScp ( <nowiki>https://winscp.net/</nowiki> ) möglich - auch in Verbindung mit putty ( <nowiki>https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html</nowiki> ) für die Befehlszeile - und wird unter Linux im Plasma Desktop nativ von Dolphin unterstützt.

Hauptseite

2024-07-25T13:30:47Z

Mielczad: /* Slurm Cluster */

Der Service '''"HPC@HU'''" stellt folgende Dienste zur Verfügung:

# Zentraler Slurm-Cluster
# Azimuth-Service

Beide Services bieten die Möglichkeit, die HPC-Infrastruktur der HU zu nutzen. Dabei bietet der Slurm-Cluster eine Vielzahl an Softwarepaketen und ist direkt mit dem HU-Account nutzbar, wohingegen der Azimuth-Service größere Flexibilität ermöglicht und u.a. auch andere Platformen wie JupyterHub zur Verfügung stellt.

== Slurm Cluster ==
Der zentrale Slurm-Cluster ist nach Anmeldung per Mail direkt mit dem HU-Account nutzbar. Der Zugang erfolgt über ein Login-Knoten,

Weitere Informationen:

* [[Erste Verbindung/Einloggen]]
* [[Slurm - Datenspeicher|Datenspeicher]]
* [[Testbetrieb - Dateistruktur]]
* [[Datenspeicher & Dateistruktur]]
* [[Modules & Verfûgbare Software]]
* [[Jobs einreichen mit SLURM]]
* [[Mailingliste und Support]]
* [[FAQ]]

== Azimuth ==
Azimuth bietet die Möglichkeit, verschiedene Plattformen, die man auch dem HPC-Bereich kennt, zu erstellen und zu verwalten. Dazu gehört u.a.:

# Slurm-Cluster
# JupyterHub
# HPC-Workstation

Die NutzerInnen können nach der Erstellung, die gewählte Plattform selbständig verwalten und erweitern. Dazu bekommen sie einen Administratorenzugang. Zur Zeit ist die Lebensdauer der Plattform nicht begrenzt.

Der Zugang zum Azimuth-Service erfolgt über den DV-Beauftragten der Einrichtung.

Modules & Verfûgbare Software

2024-07-24T09:01:10Z

Mielczad: /* Übersicht & Grundlagen zur Nuzung */ Update der Sektion Python, Hinzufügen des Textes über persönliche Module

==== Übersicht & Grundlagen zur Nuzung ====
Die bereitgestellten Compute-Knoten nutzen Linux, genaugenommen ein OpenSUSE.

HPC-typisch wird zentral Software bereitgestellt. Verfügbare Software wird über eine Modulumgebung geladen.

Welche Software verfügbar ist, lässt sich über <code>module avail</code> sowie <code>module spider <name></code> in Erfahrung bringen.

(Online Anleitung für lmod https://lmod.readthedocs.io/en/latest/010_user.html )

Wir bieten aktuell drei Gruppe von Software an:

# /hu "Von Uns" kompilierte Software welche zentral bereitgestellt wird.
# /all Über EasyBuild ( siehe http://docs.easybuild.io/what-is-easybuild/ ) bereitgestellte Software
# /intel Software welche mit Installer ausgeliefert wurde (wie zum Beispiel Intel OneAPI)

Bei der Auswahl von Software sollte darauf geachtet werden dass die Groß- und Kleinschreibung von Bedeutung ist, sprich gcc ist nicht gleich GCC.

Die finalen Pfade sind aktuell auch nicht endgültig festgelegt und können sich noch verändern.

Ferner wird empfohlen sich nicht auf die Defaults zu verlassen und die Version einer Software explizit auszuwählen.

Anwendungsbeispiel:

Die verfügbaren openmpi Versionen lassen sich mit dem Befehl
module spider openmpi
erfragen

Ist daraufhin die Version erwünscht, lässt sich diese mit dem Befehl
module load openmpi/5.0.3-gcc14.1.0
laden.

Aktuell geladene Module lassen sich mit
module list
anzeigen, während
module purge
alle geladenen Module "entlädt".

Aktuell wird die verfügbare Software noch ausgebaut, wodurch sich die Liste relativ schnell entwickelt. Für einen Überblick der aktuell verfügbaren Software wird gebeten diese direkt auf dem System abzufragen. Vor allem mit EasyBuild installierte Software bringt standardmäßig sehr viele kleine Abhängigkeiten mit.

Einen ersten Überblick über einige der wichtigeren Pakete (als Eigenkompilation) bietet die folgende Liste:

==== Verfügbare Software ====

===== Programmiersprachen und Compiler =====
- gcc

- 9.5.0

- 10.5.0

- 11.4.0

- 12.3.0

- 13.2.0

- 14.1.0

- Intel OneApi

- 2024.1

- Julia

- 1.10.3

- python

- 3.8.19

- 3.9.19

- 3.10.14

- 3.11.9

- 3.12.3

- QT (opensource)

- 5.15.14

- R

- 4.4.0

- ruby

- 3.3

===== Bibliotheken und Tools =====
- AMD AOCL

- 4.2.0 gcc

- 4.2.0 aocl

- apache-maven

- 3.9.8

- bash

- 5.2.21

- bc

- 1.0.7

- bison

- 3.8.2

- BLIS

- 4.2.0

- block2

- p0.5.3rc13 openmpi/5.0.3 gcc/14.1.0 OpenBLAS/0.3.26

- boost

- 1.85 gcc/13.2.0

- 1.85 gcc/14.1.0

- Catch2

- 3.6.0 cmake/3.29.3

- cmake

- 3.16.9

- 3.20.6

- 3.27.2

- 3.29.2

- 3.29.3

- costa

2.2.2

- cuda

- 10

- 11

- 12.0

- 12

- 12.1

- 12.2

- 12.3

- 12.4

- 12.4.1

- crest

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc13.2.0 openmpi/5.0.3-gcc13.2.0 gcc/13.2.0

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc14.1.0 openmpi/5.0.3-gcc14.1.0 gcc/14.1.0

fftw

- 3.3.0 gcc/14.1.0

- 3.3.0 openmpi/5.0.3 gcc/14.1.0

- flex

- 2.6.4

- fmt

- 10.2.1

- gsl

- 2.8

- hdf5

- 1.14.4.3

- lapack

- 3.12.0 gcc/13.2.0

- 3.12.0 gcc/14.1.0

- libflame

- 4.2.0

- libunwind

- 1.8.1

- libxc

- 6.6.2

- magma

- 2.8.8

- miniforge3

- 24.1.2-0

- mpich

- 3.2.0 gcc/12.3.0

- 3.3.0 gcc/12.3.0

- 4.1.3 gcc/12.3.0

- 4.2.1 gcc/14.1.0

- OpenBLAS

- 0.3.26 gcc/13.2.0

- 0.3.26 gcc/14.1.0

- OpenCoarrays

- 2.9.3 mpich/3.3.0 gcc/12.3.0

- 2.10.2 openmpi/5.0.3 gcc/14.1.0

- OpenMPI

- 4.1.6 gcc/13.2.0

- 5.0.3 gcc/13.2.0

- 5.0.3 gcc/14.1.0

- patch

- 2.7.6

- proj

- 9.4.1 gcc/14.1.0

- scalapack

- 2.2.0

- spglib

- 2.4.0 gcc/14.1.0

- sirius

- 7.5.2

- spla

- 1.6.1

- swig

- 4.2.1

- szip

- 2.1.1

- umpire

- 2024.02.01

===== Software =====
- gdal

- 3.9.0 gcc/14.1.0 proj/9.4.1 swig/4.2.1 python/3.12.3

- hadoopp

- 3.4.0

- hpl

- v2.3

- ior

- 4.0.0 openmpi/5.0.3 gcc/14.1.0

- ncdu

- 1.20

- OpenFOAM

- 11

- v2312

- ORCA

- 5.0.4

- quantum-espresso

- 7.3.1 OpenBLAS/0.3.26 fftw/3.3.10 penmpi/5.0.3 gcc/14.1.0

- xtb

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/13.2.0

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/14.1.0

===== Fehlt was? =====
Da es sich beim HPC um ein Linux System handelt, ist es möglich eigene Software zu entwickeln. Die Einbindung von Software findet überwiegend über zwei grundlegende Variablen statt. <code>PATH</code> für ausführbare Binärdateien sowie <code>LD_LIBRARY_PATH</code> für verlinkte Bibliotheken.

Über ein <code>export PATH=/new/path:$PATH</code> sowie <code>export LD_LIBRARY_PATH=/new/path:$LD_LIBRARY_PATH</code> lassen sich beide erweitern. Diese Änderung gilt bis zum verlassen der Shell - oder ist "semi-permanent" wenn der Export in die .profile oder .bashrc Datei eingetragen wird.

Hierbei gilt es ferner zu beachten dass die Reihenfolge der Auflistung der verschiedenen Pfade von Bedeutung ist: die zuerst gefundene Variante wird genommen.

Obschon es möglich ist eine Software zu kompilieren, bitten wir darum bei fehlender freier Software nach Möglichkeit zuerst eine Anfrage an [mailto:hpc-support@hu-berlin.de hpc-support@hu-berlin.de] zu schicken, damit diese zentral für Alle zugänglich ist.

Bei Anfragen zu kommerzieller Software, internen Eigenentwicklungen oder anderweitig speziell lizenzierter Software stehen wir ebenfalls gerne zu Verfügung.

==== Python, Anaconda, Conda, Mamba ====

===== Python =====
Python wird in vielen Projekten eingesetzt. Die Nutzung von Python ist nicht immer problemfrei, darum gibt es folgend einige Empfehlungen für die Nutzung von Python, welche das Risiko von Problemen sowie die Problembeseitigung erleichtern.

Im Allgemeinen sollten Python Anwendungen in einer virtuellen Umgebung entwickelt und ausgeführt werden. Diese wird nativ von Python unterstützt und ermöglicht es Pakete auf einer bestimmten Version zu halten sowie eventuelle Inkompatibilitäten zwischen verschiedenen Projekten zu vermeiden. Ferner ist es möglich bei Problemen eine virtuelle Umgebung zu löschen und dadurch alte Pakete Rückstandslos zu entfernen. Das ist vor allem interessant da pip oder pip3 Abhängigkeiten installieren kann, aber im Gegensatz zu typischen Linux-Paketmanagern Abhängigkeiten nicht automatisch deinstallieren kann.

Eine virtuelle Umgebung kann wie folgt erstellt werden (mit einem relativen oder absoluten Pfad):
<code>python -m venv /Pfad/zur/neuen/virtuellen_Umgebung</code>
Mehr dazu auf in der Dokumentation von Python: <nowiki>https://docs.python.org/3/library/venv.html</nowiki>

Sollte es aus bestimmten Gründen nicht möglich sein eine virtuelle Umgebung zu nutzen, kann man mit pip Pakete in einem bestimmten Ordner installieren.
<code>pip3 install --target /Pfad/zum/ZielOrdner</code>
Danach kann der Ordner zur Variable PYTHONPATH hinzugefügt werden und wird dann von der Python-Umgebung erkannt.

Die virtuellen Umgebungen sind im Allgemeinen jedoch zu präferieren.

===== Anaconda, Conda, Mamba =====
Eine weitere Alternative ist die Nutzung einer Packetverwaltung in Python, so wie diese über Anaconda/conda/mamba angeboten wird, bei dieser ist der Funktionsumfang dann auch größer als be pip.

Hierbei werden Nutzer und Nutzerinnen angehalten die Nutzungsbedingungen von vor allem Anaconda und Miniconda zu beachten. Aktuell (Juli 2024) wird Miniforge unter der BSD Lizenz angeboten und ist in in Bezug auf die Nutzung.

Während eine zentrale Installation von conda und mamba über miniforge3 bereitgestellt wird, haben normale Nutzer keine Schreibrechte in dem zentralen Installationsordner. Standardmäßig wird conda/mamba daraufhin versuchen einen Ordner im Home-Verzeichnis anzulegen, alternativ kann ein expliziter Prefix wie folgt angegeben werden.
<code>conda create --prefix /Pfad/zur/neuen/conda_Umgebung</code>
Für typische Nutzertools wird darum empfohlen eine eigene Installation von miniforge aufzusetzen und eigene Umgebungen zu verwalten. Bei der Einrichtung muss dann nur darauf geachtet werden dass der Installationspfad korrekt eingegeben wird. Da eine solche Installation mit der Zeit recht groß werden kann, wird empfohlen dass lustre Dateisystem zu nutzen, der Pfad würde dementsprechend <code>/lustre/<Fakultät>/<Benutzername></code> lauten.

Mit <code>conda init</code> oder <code>mamba init</code> wird die Umgebung initiialisiert und die .bashrc Datei angepasst. Dabei werden eventuell existierende conda/mamba Konfigurationen überschrieben (!!!). Dies ist beim benutzen von mehreren Versionen potenziell problematisch und erfordert eine manuelle Anpassung der Skripte sowie potenziell deren Auslagerung in individuelle Dateien.

==== Persönliche Module ====
Es ist möglich eigene Module in <code>lmod</code> einzubinden, wie in der Dokumentation beschrieben: <nowiki>https://lmod.readthedocs.io/en/latest/020_advanced.html</nowiki>

Eine Môglichkeit besteht in dem Befehl <code>module use /path/to/personal/modulefiles</code>, alternativ kann der Pfad zu privaten Moduldateien auch gleich zur Variable <code>$MODULEPATH</code> hinzugefügt werden.

Informationen bezüglich des Aufbaus der Moduldateien finden sich in der lmod-Dokumentation auf der Webseite. Ebenso können die bereitgestellten Module unter <code>/software/modules</code> als Inspiration dienen.

==== Für Nutzer: ====
Für Nutzer von HPC@HU finden sich unter <code>/software/modules/software.md</code> weitere Informationen über die verfügbare Software und wie diese gebaut/konfiguriert wurde.

Modules & Verfûgbare Software

2024-07-24T08:46:23Z

Mielczad: /* Python */ update python section to be in line with internal documentation

==== Übersicht & Grundlagen zur Nuzung ====
Die bereitgestellten Compute-Knoten nutzen Linux, genaugenommen ein OpenSUSE.

HPC-typisch wird zentral Software bereitgestellt. Verfügbare Software wird über eine Modulumgebung geladen.

Welche Software verfügbar ist, lässt sich über <code>module avail</code> sowie <code>module spider <name></code> in Erfahrung bringen.

(Online Anleitung für lmod https://lmod.readthedocs.io/en/latest/010_user.html )

Wir bieten aktuell drei Gruppe von Software an:

# /hu "Von Uns" kompilierte Software welche zentral bereitgestellt wird.
# /all Über EasyBuild ( siehe http://docs.easybuild.io/what-is-easybuild/ ) bereitgestellte Software
# /intel Software welche mit Installer ausgeliefert wurde (wie zum Beispiel Intel OneAPI)

Bei der Auswahl von Software sollte darauf geachtet werden dass die Groß- und Kleinschreibung von Bedeutung ist, sprich gcc ist nicht gleich GCC.

Die finalen Pfade sind aktuell auch nicht endgültig festgelegt und können sich noch verändern.

Ferner wird empfohlen sich nicht auf die Defaults zu verlassen und die Version einer Software explizit auszuwählen.

Anwendungsbeispiel:

Die verfügbaren openmpi Versionen lassen sich mit dem Befehl
module spider openmpi
erfragen

Ist daraufhin die Version erwünscht, lässt sich diese mit dem Befehl
module load openmpi/5.0.3-gcc14.1.0
laden.

Aktuell geladene Module lassen sich mit
module list
anzeigen, während
module purge
alle geladenen Module "entlädt".

Aktuell wird die verfügbare Software noch ausgebaut, wodurch sich die Liste relativ schnell entwickelt. Für einen Überblick der aktuell verfügbaren Software wird gebeten diese direkt auf dem System abzufragen. Vor allem mit EasyBuild installierte Software bringt standardmäßig sehr viele kleine Abhängigkeiten mit.

Einen ersten Überblick über einige der wichtigeren Pakete (als Eigenkompilation) bietet die folgende Liste:

==== Verfügbare Software ====

===== Programmiersprachen und Compiler =====
- gcc

- 9.5.0

- 10.5.0

- 11.4.0

- 12.3.0

- 13.2.0

- 14.1.0

- Intel OneApi

- 2024.1

- Julia

- 1.10.3

- python

- 3.8.19

- 3.9.19

- 3.10.14

- 3.11.9

- 3.12.3

- QT (opensource)

- 5.15.14

- R

- 4.4.0

- ruby

- 3.3

===== Bibliotheken und Tools =====
- AMD AOCL

- 4.2.0 gcc

- 4.2.0 aocl

- apache-maven

- 3.9.8

- bash

- 5.2.21

- bc

- 1.0.7

- bison

- 3.8.2

- BLIS

- 4.2.0

- block2

- p0.5.3rc13 openmpi/5.0.3 gcc/14.1.0 OpenBLAS/0.3.26

- boost

- 1.85 gcc/13.2.0

- 1.85 gcc/14.1.0

- Catch2

- 3.6.0 cmake/3.29.3

- cmake

- 3.16.9

- 3.20.6

- 3.27.2

- 3.29.2

- 3.29.3

- costa

2.2.2

- cuda

- 10

- 11

- 12.0

- 12

- 12.1

- 12.2

- 12.3

- 12.4

- 12.4.1

- crest

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc13.2.0 openmpi/5.0.3-gcc13.2.0 gcc/13.2.0

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc14.1.0 openmpi/5.0.3-gcc14.1.0 gcc/14.1.0

fftw

- 3.3.0 gcc/14.1.0

- 3.3.0 openmpi/5.0.3 gcc/14.1.0

- flex

- 2.6.4

- fmt

- 10.2.1

- gsl

- 2.8

- hdf5

- 1.14.4.3

- lapack

- 3.12.0 gcc/13.2.0

- 3.12.0 gcc/14.1.0

- libflame

- 4.2.0

- libunwind

- 1.8.1

- libxc

- 6.6.2

- magma

- 2.8.8

- miniforge3

- 24.1.2-0

- mpich

- 3.2.0 gcc/12.3.0

- 3.3.0 gcc/12.3.0

- 4.1.3 gcc/12.3.0

- 4.2.1 gcc/14.1.0

- OpenBLAS

- 0.3.26 gcc/13.2.0

- 0.3.26 gcc/14.1.0

- OpenCoarrays

- 2.9.3 mpich/3.3.0 gcc/12.3.0

- 2.10.2 openmpi/5.0.3 gcc/14.1.0

- OpenMPI

- 4.1.6 gcc/13.2.0

- 5.0.3 gcc/13.2.0

- 5.0.3 gcc/14.1.0

- patch

- 2.7.6

- proj

- 9.4.1 gcc/14.1.0

- scalapack

- 2.2.0

- spglib

- 2.4.0 gcc/14.1.0

- sirius

- 7.5.2

- spla

- 1.6.1

- swig

- 4.2.1

- szip

- 2.1.1

- umpire

- 2024.02.01

===== Software =====
- gdal

- 3.9.0 gcc/14.1.0 proj/9.4.1 swig/4.2.1 python/3.12.3

- hadoopp

- 3.4.0

- hpl

- v2.3

- ior

- 4.0.0 openmpi/5.0.3 gcc/14.1.0

- ncdu

- 1.20

- OpenFOAM

- 11

- v2312

- ORCA

- 5.0.4

- quantum-espresso

- 7.3.1 OpenBLAS/0.3.26 fftw/3.3.10 penmpi/5.0.3 gcc/14.1.0

- xtb

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/13.2.0

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/14.1.0

===== Fehlt was? =====
Da es sich beim HPC um ein Linux System handelt, ist es möglich eigene Software zu entwickeln. Die Einbindung von Software findet überwiegend über zwei grundlegende Variablen statt. <code>PATH</code> für ausführbare Binärdateien sowie <code>LD_LIBRARY_PATH</code> für verlinkte Bibliotheken.

Über ein <code>export PATH=/new/path:$PATH</code> sowie <code>export LD_LIBRARY_PATH=/new/path:$LD_LIBRARY_PATH</code> lassen sich beide erweitern. Diese Änderung gilt bis zum verlassen der Shell - oder ist "semi-permanent" wenn der Export in die .profile oder .bashrc Datei eingetragen wird.

Hierbei gilt es ferner zu beachten dass die Reihenfolge der Auflistung der verschiedenen Pfade von Bedeutung ist: die zuerst gefundene Variante wird genommen.

Obschon es möglich ist eine Software zu kompilieren, bitten wir darum bei fehlender freier Software nach Möglichkeit zuerst eine Anfrage an [mailto:hpc-support@hu-berlin.de hpc-support@hu-berlin.de] zu schicken, damit diese zentral für Alle zugänglich ist.

Bei Anfragen zu kommerzieller Software, internen Eigenentwicklungen oder anderweitig speziell lizenzierter Software stehen wir ebenfalls gerne zu Verfügung.

==== Python ====
Python wird in vielen Projekten eingesetzt. Die Nutzung von Python ist nicht immer problemfrei, darum gibt es folgend einige Empfehlungen für die Nutzung von Python, welche das Risiko von Problemen sowie die Problembeseitigung erleichtern.

Im Allgemeinen sollten Python Anwendungen in einer virtuellen Umgebung entwickelt und ausgeführt werden. Diese wird nativ von Python unterstützt und ermöglicht es Pakete auf einer bestimmten Version zu halten sowie eventuelle Inkompatibilitäten zwischen verschiedenen Projekten zu vermeiden. Ferner ist es möglich bei Problemen eine virtuelle Umgebung zu löschen und dadurch alte Pakete Rückstandslos zu entfernen. Das ist vor allem interessant da pip oder pip3 Abhängigkeiten installieren kann, aber im Gegensatz zu typischen Linux-Paketmanagern Abhängigkeiten nicht automatisch deinstallieren kann.

Eine virtuelle Umgebung kann wie folgt erstellt werden (mit einem relativen oder absoluten Pfad):

<code>python -m venv /Pfad/zur/neuen/virtuellen_Umgebung</code>

Mehr dazu auf in der Dokumentation von Python: <nowiki>https://docs.python.org/3/library/venv.html</nowiki>

Sollte es aus bestimmten Gründen nicht möglich sein eine virtuelle Umgebung zu nutzen, kann man mit pip Pakete in einem bestimmten Ordner installieren.

<code>pip3 install --target /Pfad/zum/ZielOrdner</code>

Danach kann der Ordner zur Variable PYTHONPATH hinzugefügt werden und wird dann von der Python-Umgebung erkannt.

Die virtuellen Umgebungen sind im Allgemeinen jedoch zu präferieren.

==== Anaconda, Conda, Mamba ====
Eine weitere Alternative ist die Nutzung einer Packetverwaltung in Python, so wie diese über Anaconda/conda/mamba angeboten wird, bei dieser ist der Funktionsumfang dann auch größer als be pip.

Hierbei werden Nutzer und Nutzerinnen angehalten die Nutzungsbedingungen von vor allem Anaconda und Miniconda zu beachten. Aktuell (Juli 2024) wird Miniforge unter der BSD Lizenz angeboten und ist in in Bezug auf die Nutzung.

Während eine zentrale Installation von conda und mamba über miniforge3 bereitgestellt wird, haben normale Nutzer keine Schreibrechte in dem zentralen Installationsordner. Standardmäßig wird conda/mamba daraufhin versuchen einen Ordner im Home-Verzeichnis anzulegen, alternativ kann ein expliziter Prefix wie folgt angegeben werden.

<code>conda create --prefix /Pfad/zur/neuen/conda_Umgebung</code>

Für typische Nutzertools wird darum empfohlen eine eigene Installation von miniforge aufzusetzen und eigene Umgebungen zu verwalten. Bei der Einrichtung muss dann nur darauf geachtet werden dass der Installationspfad korrekt eingegeben wird. Da eine solche Installation mit der Zeit recht groß werden kann, wird empfohlen dass lustre Dateisystem zu nutzen, der Pfad würde dementsprechend <code>/lustre/<Fakultät>/<Benutzername></code> lauten.

Mit <code>conda init</code> oder <code>mamba init</code> wird die Umgebung initiialisiert und die .bashrc Datei angepasst. Dabei werden eventuell existierende conda/mamba Konfigurationen überschrieben (!!!). Dies ist beim benutzen von mehreren Versionen potenziell problematisch und erfordert eine manuelle Anpassung der Skripte sowie potenziell deren Auslagerung in individuelle Dateien.

==== Für Nutzer: ====
Für Nutzer von HPC@HU finden sich unter <code>/software/modules/software.md</code> weitere Informationen über die verfügbare Software und wie diese gebaut/konfiguriert wurde.

Modules & Verfûgbare Software

2024-07-24T08:44:43Z

Mielczad: /* Programmiersprachen und Compiler */ remove miniconda

==== Übersicht & Grundlagen zur Nuzung ====
Die bereitgestellten Compute-Knoten nutzen Linux, genaugenommen ein OpenSUSE.

HPC-typisch wird zentral Software bereitgestellt. Verfügbare Software wird über eine Modulumgebung geladen.

Welche Software verfügbar ist, lässt sich über <code>module avail</code> sowie <code>module spider <name></code> in Erfahrung bringen.

(Online Anleitung für lmod https://lmod.readthedocs.io/en/latest/010_user.html )

Wir bieten aktuell drei Gruppe von Software an:

# /hu "Von Uns" kompilierte Software welche zentral bereitgestellt wird.
# /all Über EasyBuild ( siehe http://docs.easybuild.io/what-is-easybuild/ ) bereitgestellte Software
# /intel Software welche mit Installer ausgeliefert wurde (wie zum Beispiel Intel OneAPI)

Bei der Auswahl von Software sollte darauf geachtet werden dass die Groß- und Kleinschreibung von Bedeutung ist, sprich gcc ist nicht gleich GCC.

Die finalen Pfade sind aktuell auch nicht endgültig festgelegt und können sich noch verändern.

Ferner wird empfohlen sich nicht auf die Defaults zu verlassen und die Version einer Software explizit auszuwählen.

Anwendungsbeispiel:

Die verfügbaren openmpi Versionen lassen sich mit dem Befehl
module spider openmpi
erfragen

Ist daraufhin die Version erwünscht, lässt sich diese mit dem Befehl
module load openmpi/5.0.3-gcc14.1.0
laden.

Aktuell geladene Module lassen sich mit
module list
anzeigen, während
module purge
alle geladenen Module "entlädt".

Aktuell wird die verfügbare Software noch ausgebaut, wodurch sich die Liste relativ schnell entwickelt. Für einen Überblick der aktuell verfügbaren Software wird gebeten diese direkt auf dem System abzufragen. Vor allem mit EasyBuild installierte Software bringt standardmäßig sehr viele kleine Abhängigkeiten mit.

Einen ersten Überblick über einige der wichtigeren Pakete (als Eigenkompilation) bietet die folgende Liste:

==== Verfügbare Software ====

===== Programmiersprachen und Compiler =====
- gcc

- 9.5.0

- 10.5.0

- 11.4.0

- 12.3.0

- 13.2.0

- 14.1.0

- Intel OneApi

- 2024.1

- Julia

- 1.10.3

- python

- 3.8.19

- 3.9.19

- 3.10.14

- 3.11.9

- 3.12.3

- QT (opensource)

- 5.15.14

- R

- 4.4.0

- ruby

- 3.3

===== Bibliotheken und Tools =====
- AMD AOCL

- 4.2.0 gcc

- 4.2.0 aocl

- apache-maven

- 3.9.8

- bash

- 5.2.21

- bc

- 1.0.7

- bison

- 3.8.2

- BLIS

- 4.2.0

- block2

- p0.5.3rc13 openmpi/5.0.3 gcc/14.1.0 OpenBLAS/0.3.26

- boost

- 1.85 gcc/13.2.0

- 1.85 gcc/14.1.0

- Catch2

- 3.6.0 cmake/3.29.3

- cmake

- 3.16.9

- 3.20.6

- 3.27.2

- 3.29.2

- 3.29.3

- costa

2.2.2

- cuda

- 10

- 11

- 12.0

- 12

- 12.1

- 12.2

- 12.3

- 12.4

- 12.4.1

- crest

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc13.2.0 openmpi/5.0.3-gcc13.2.0 gcc/13.2.0

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc14.1.0 openmpi/5.0.3-gcc14.1.0 gcc/14.1.0

fftw

- 3.3.0 gcc/14.1.0

- 3.3.0 openmpi/5.0.3 gcc/14.1.0

- flex

- 2.6.4

- fmt

- 10.2.1

- gsl

- 2.8

- hdf5

- 1.14.4.3

- lapack

- 3.12.0 gcc/13.2.0

- 3.12.0 gcc/14.1.0

- libflame

- 4.2.0

- libunwind

- 1.8.1

- libxc

- 6.6.2

- magma

- 2.8.8

- miniforge3

- 24.1.2-0

- mpich

- 3.2.0 gcc/12.3.0

- 3.3.0 gcc/12.3.0

- 4.1.3 gcc/12.3.0

- 4.2.1 gcc/14.1.0

- OpenBLAS

- 0.3.26 gcc/13.2.0

- 0.3.26 gcc/14.1.0

- OpenCoarrays

- 2.9.3 mpich/3.3.0 gcc/12.3.0

- 2.10.2 openmpi/5.0.3 gcc/14.1.0

- OpenMPI

- 4.1.6 gcc/13.2.0

- 5.0.3 gcc/13.2.0

- 5.0.3 gcc/14.1.0

- patch

- 2.7.6

- proj

- 9.4.1 gcc/14.1.0

- scalapack

- 2.2.0

- spglib

- 2.4.0 gcc/14.1.0

- sirius

- 7.5.2

- spla

- 1.6.1

- swig

- 4.2.1

- szip

- 2.1.1

- umpire

- 2024.02.01

===== Software =====
- gdal

- 3.9.0 gcc/14.1.0 proj/9.4.1 swig/4.2.1 python/3.12.3

- hadoopp

- 3.4.0

- hpl

- v2.3

- ior

- 4.0.0 openmpi/5.0.3 gcc/14.1.0

- ncdu

- 1.20

- OpenFOAM

- 11

- v2312

- ORCA

- 5.0.4

- quantum-espresso

- 7.3.1 OpenBLAS/0.3.26 fftw/3.3.10 penmpi/5.0.3 gcc/14.1.0

- xtb

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/13.2.0

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/14.1.0

===== Fehlt was? =====
Da es sich beim HPC um ein Linux System handelt, ist es möglich eigene Software zu entwickeln. Die Einbindung von Software findet überwiegend über zwei grundlegende Variablen statt. <code>PATH</code> für ausführbare Binärdateien sowie <code>LD_LIBRARY_PATH</code> für verlinkte Bibliotheken.

Über ein <code>export PATH=/new/path:$PATH</code> sowie <code>export LD_LIBRARY_PATH=/new/path:$LD_LIBRARY_PATH</code> lassen sich beide erweitern. Diese Änderung gilt bis zum verlassen der Shell - oder ist "semi-permanent" wenn der Export in die .profile oder .bashrc Datei eingetragen wird.

Hierbei gilt es ferner zu beachten dass die Reihenfolge der Auflistung der verschiedenen Pfade von Bedeutung ist: die zuerst gefundene Variante wird genommen.

Obschon es möglich ist eine Software zu kompilieren, bitten wir darum bei fehlender freier Software nach Möglichkeit zuerst eine Anfrage an [mailto:hpc-support@hu-berlin.de hpc-support@hu-berlin.de] zu schicken, damit diese zentral für Alle zugänglich ist.

Bei Anfragen zu kommerzieller Software, internen Eigenentwicklungen oder anderweitig speziell lizenzierter Software stehen wir ebenfalls gerne zu Verfügung.

==== Python ====
Python wird in vielen Projekten eingesetzt. Die Nutzung von Python ist nicht immer problemfrei, darum gibt es folgend einige Empfehlungen für die Nutzung von Python, welche das Risiko von Problemen sowie die Problembeseitigung erleichtern.

Im Allgemeinen sollten Python Anwendungen in einer virtuellen Umgebung entwickelt und ausgeführt werden. Diese wird nativ von Python unterstützt und ermöglicht es Pakete auf einer bestimmten Version zu halten sowie eventuelle Inkompatibilitäten zwischen verschiedenen Projekten zu vermeiden. Ferner ist es möglich bei Problemen eine virtuelle Umgebung zu löschen und dadurch alte Pakete Rückstandslos zu entfernen. Das ist vor allem interessant da <code>pip</code> oder <code>pip3</code> Abhängigkeiten installieren kann, aber im Gegensatz zu typischen Linux-Paketmanagern Abhängigkeiten nicht automatisch deinstallieren kann.

Eine virtuelle Umgebung kann wie folgt erstellt werden (mit einem relativen oder absoluten Pfad):
python -m venv /Pfad/zur/neuen/virtuellen_Umgebung
Mehr dazu auf in der Dokumentation von Python: https://docs.python.org/3/library/venv.html

Sollte es aus bestimmten Gründen nicht möglich sein eine virtuelle Umgebung zu nutzen, kann man mit pip Pakete in einem bestimmten Ordner installieren.
pip3 install --target /Pfad/zum/ZielOrdner
Danach kann der Order zur Variable <code>PYTHONPATH</code> hinzugefügt werden und wird dann von der Python-Umgebung erkannt.

Die virtuellen Umgebungen sind im Allgemeinen jedoch zu präferieren.

Eine weitere Alternative ist die Nutzung von <code>conda</code>, welches in der Form von miniconda angeboten wird. Mit <code>conda</code> lässt sich ebenfalls eine Umgebung erstellen, wobei der Funktionsumfang umfangreicher als bei <code>pip</code> ist, für eine Umgebung in einem bestimmten Pfad lautet der Befehl dann wir folgt:
conda create --prefix /Pfad/zur/neuen/conda_Umgebung
Mit <code>conda init</code> oder <code>mamba init</code> wird die umgebund initiialisiert und die .bashrc Datei wird angepasst. Dabei werden eventuell existierende conda/mamba Konfigurationen überschrieben '''(!!!)'''. Dies ist beim benutzen von mehreren Versionen potenziell problematisch.

Wenn von Nutzerseite ein conda-Ordner angelegt wird, sollte bedacht werden, dass diese im Laufe der Zeit mit der Installation von Paketen recht groß werden können.

===== Für Nutzer: =====
Für Nutzer von HPC@HU finden sich unter <code>/software/modules/software.md</code> weitere Informationen über die verfügbare Software und wie diese gebaut/konfiguriert wurde.

Modules & Verfûgbare Software

2024-07-24T07:52:48Z

Mielczad: /* Übersicht & Grundlagen zur Nuzung */ Link zu weiterer Dokumentation für Nutzer

==== Übersicht & Grundlagen zur Nuzung ====
Die bereitgestellten Compute-Knoten nutzen Linux, genaugenommen ein OpenSUSE.

HPC-typisch wird zentral Software bereitgestellt. Verfügbare Software wird über eine Modulumgebung geladen.

Welche Software verfügbar ist, lässt sich über <code>module avail</code> sowie <code>module spider <name></code> in Erfahrung bringen.

(Online Anleitung für lmod https://lmod.readthedocs.io/en/latest/010_user.html )

Wir bieten aktuell drei Gruppe von Software an:

# /hu "Von Uns" kompilierte Software welche zentral bereitgestellt wird.
# /all Über EasyBuild ( siehe http://docs.easybuild.io/what-is-easybuild/ ) bereitgestellte Software
# /intel Software welche mit Installer ausgeliefert wurde (wie zum Beispiel Intel OneAPI)

Bei der Auswahl von Software sollte darauf geachtet werden dass die Groß- und Kleinschreibung von Bedeutung ist, sprich gcc ist nicht gleich GCC.

Die finalen Pfade sind aktuell auch nicht endgültig festgelegt und können sich noch verändern.

Ferner wird empfohlen sich nicht auf die Defaults zu verlassen und die Version einer Software explizit auszuwählen.

Anwendungsbeispiel:

Die verfügbaren openmpi Versionen lassen sich mit dem Befehl
module spider openmpi
erfragen

Ist daraufhin die Version erwünscht, lässt sich diese mit dem Befehl
module load openmpi/5.0.3-gcc14.1.0
laden.

Aktuell geladene Module lassen sich mit
module list
anzeigen, während
module purge
alle geladenen Module "entlädt".

Aktuell wird die verfügbare Software noch ausgebaut, wodurch sich die Liste relativ schnell entwickelt. Für einen Überblick der aktuell verfügbaren Software wird gebeten diese direkt auf dem System abzufragen. Vor allem mit EasyBuild installierte Software bringt standardmäßig sehr viele kleine Abhängigkeiten mit.

Einen ersten Überblick über einige der wichtigeren Pakete (als Eigenkompilation) bietet die folgende Liste:

==== Verfügbare Software ====

===== Programmiersprachen und Compiler =====
- gcc

- 9.5.0

- 10.5.0

- 11.4.0

- 12.3.0

- 13.2.0

- 14.1.0

- Intel OneApi

- 2024.1

- Julia

- 1.10.3

- python

- 3.8.19

- 3.9.19

- 3.10.14

- 3.11.9

- 3.12.3

- QT (opensource)

- 5.15.14

- R

- 4.4.0

- ruby

- 3.3

===== Bibliotheken und Tools =====
- AMD AOCL

- 4.2.0 gcc

- 4.2.0 aocl

- apache-maven

- 3.9.8

- bash

- 5.2.21

- bc

- 1.0.7

- bison

- 3.8.2

- BLIS

- 4.2.0

- block2

- p0.5.3rc13 openmpi/5.0.3 gcc/14.1.0 OpenBLAS/0.3.26

- boost

- 1.85 gcc/13.2.0

- 1.85 gcc/14.1.0

- Catch2

- 3.6.0 cmake/3.29.3

- cmake

- 3.16.9

- 3.20.6

- 3.27.2

- 3.29.2

- 3.29.3

- costa

2.2.2

- cuda

- 10

- 11

- 12.0

- 12

- 12.1

- 12.2

- 12.3

- 12.4

- 12.4.1

- crest

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc13.2.0 openmpi/5.0.3-gcc13.2.0 gcc/13.2.0

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc14.1.0 openmpi/5.0.3-gcc14.1.0 gcc/14.1.0

fftw

- 3.3.0 gcc/14.1.0

- 3.3.0 openmpi/5.0.3 gcc/14.1.0

- flex

- 2.6.4

- fmt

- 10.2.1

- gsl

- 2.8

- hdf5

- 1.14.4.3

- lapack

- 3.12.0 gcc/13.2.0

- 3.12.0 gcc/14.1.0

- libflame

- 4.2.0

- libunwind

- 1.8.1

- libxc

- 6.6.2

- magma

- 2.8.8

- miniconda3

- 24.3.0-0

- miniforge3

- 24.1.2-0

- mpich

- 3.2.0 gcc/12.3.0

- 3.3.0 gcc/12.3.0

- 4.1.3 gcc/12.3.0

- 4.2.1 gcc/14.1.0

- OpenBLAS

- 0.3.26 gcc/13.2.0

- 0.3.26 gcc/14.1.0

- OpenCoarrays

- 2.9.3 mpich/3.3.0 gcc/12.3.0

- 2.10.2 openmpi/5.0.3 gcc/14.1.0

- OpenMPI

- 4.1.6 gcc/13.2.0

- 5.0.3 gcc/13.2.0

- 5.0.3 gcc/14.1.0

- patch

- 2.7.6

- proj

- 9.4.1 gcc/14.1.0

- scalapack

- 2.2.0

- spglib

- 2.4.0 gcc/14.1.0

- sirius

- 7.5.2

- spla

- 1.6.1

- swig

- 4.2.1

- szip

- 2.1.1

- umpire

- 2024.02.01

===== Software =====
- gdal

- 3.9.0 gcc/14.1.0 proj/9.4.1 swig/4.2.1 python/3.12.3

- hadoopp

- 3.4.0

- hpl

- v2.3

- ior

- 4.0.0 openmpi/5.0.3 gcc/14.1.0

- ncdu

- 1.20

- OpenFOAM

- 11

- v2312

- ORCA

- 5.0.4

- quantum-espresso

- 7.3.1 OpenBLAS/0.3.26 fftw/3.3.10 penmpi/5.0.3 gcc/14.1.0

- xtb

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/13.2.0

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/14.1.0

===== Fehlt was? =====
Da es sich beim HPC um ein Linux System handelt, ist es möglich eigene Software zu entwickeln. Die Einbindung von Software findet überwiegend über zwei grundlegende Variablen statt. <code>PATH</code> für ausführbare Binärdateien sowie <code>LD_LIBRARY_PATH</code> für verlinkte Bibliotheken.

Über ein <code>export PATH=/new/path:$PATH</code> sowie <code>export LD_LIBRARY_PATH=/new/path:$LD_LIBRARY_PATH</code> lassen sich beide erweitern. Diese Änderung gilt bis zum verlassen der Shell - oder ist "semi-permanent" wenn der Export in die .profile oder .bashrc Datei eingetragen wird.

Hierbei gilt es ferner zu beachten dass die Reihenfolge der Auflistung der verschiedenen Pfade von Bedeutung ist: die zuerst gefundene Variante wird genommen.

Obschon es möglich ist eine Software zu kompilieren, bitten wir darum bei fehlender freier Software nach Möglichkeit zuerst eine Anfrage an [mailto:hpc-support@hu-berlin.de hpc-support@hu-berlin.de] zu schicken, damit diese zentral für Alle zugänglich ist.

Bei Anfragen zu kommerzieller Software, internen Eigenentwicklungen oder anderweitig speziell lizenzierter Software stehen wir ebenfalls gerne zu Verfügung.

==== Python ====
Python wird in vielen Projekten eingesetzt. Die Nutzung von Python ist nicht immer problemfrei, darum gibt es folgend einige Empfehlungen für die Nutzung von Python, welche das Risiko von Problemen sowie die Problembeseitigung erleichtern.

Im Allgemeinen sollten Python Anwendungen in einer virtuellen Umgebung entwickelt und ausgeführt werden. Diese wird nativ von Python unterstützt und ermöglicht es Pakete auf einer bestimmten Version zu halten sowie eventuelle Inkompatibilitäten zwischen verschiedenen Projekten zu vermeiden. Ferner ist es möglich bei Problemen eine virtuelle Umgebung zu löschen und dadurch alte Pakete Rückstandslos zu entfernen. Das ist vor allem interessant da <code>pip</code> oder <code>pip3</code> Abhängigkeiten installieren kann, aber im Gegensatz zu typischen Linux-Paketmanagern Abhängigkeiten nicht automatisch deinstallieren kann.

Eine virtuelle Umgebung kann wie folgt erstellt werden (mit einem relativen oder absoluten Pfad):
python -m venv /Pfad/zur/neuen/virtuellen_Umgebung
Mehr dazu auf in der Dokumentation von Python: https://docs.python.org/3/library/venv.html

Sollte es aus bestimmten Gründen nicht möglich sein eine virtuelle Umgebung zu nutzen, kann man mit pip Pakete in einem bestimmten Ordner installieren.
pip3 install --target /Pfad/zum/ZielOrdner
Danach kann der Order zur Variable <code>PYTHONPATH</code> hinzugefügt werden und wird dann von der Python-Umgebung erkannt.

Die virtuellen Umgebungen sind im Allgemeinen jedoch zu präferieren.

Eine weitere Alternative ist die Nutzung von <code>conda</code>, welches in der Form von miniconda angeboten wird. Mit <code>conda</code> lässt sich ebenfalls eine Umgebung erstellen, wobei der Funktionsumfang umfangreicher als bei <code>pip</code> ist, für eine Umgebung in einem bestimmten Pfad lautet der Befehl dann wir folgt:
conda create --prefix /Pfad/zur/neuen/conda_Umgebung
Mit <code>conda init</code> oder <code>mamba init</code> wird die umgebund initiialisiert und die .bashrc Datei wird angepasst. Dabei werden eventuell existierende conda/mamba Konfigurationen überschrieben '''(!!!)'''. Dies ist beim benutzen von mehreren Versionen potenziell problematisch.

Wenn von Nutzerseite ein conda-Ordner angelegt wird, sollte bedacht werden, dass diese im Laufe der Zeit mit der Installation von Paketen recht groß werden können.

===== Für Nutzer: =====
Für Nutzer von HPC@HU finden sich unter <code>/software/modules/software.md</code> weitere Informationen über die verfügbare Software und wie diese gebaut/konfiguriert wurde.

Modules & Verfûgbare Software

2024-07-24T07:12:44Z

Mielczad: /* Programmiersprachen */ Update der Liste von verfügbarer Software

==== Übersicht & Grundlagen zur Nuzung ====
Die bereitgestellten Compute-Knoten nutzen Linux, genaugenommen ein OpenSUSE.

HPC-typisch wird zentral Software bereitgestellt. Verfügbare Software wird über eine Modulumgebung geladen.

Welche Software verfügbar ist, lässt sich über <code>module avail</code> sowie <code>module spider <name></code> in Erfahrung bringen.

(Online Anleitung für lmod https://lmod.readthedocs.io/en/latest/010_user.html )

Wir bieten aktuell drei Gruppe von Software an:

# /hu "Von Uns" kompilierte Software welche zentral bereitgestellt wird.
# /all Über EasyBuild ( siehe http://docs.easybuild.io/what-is-easybuild/ ) bereitgestellte Software
# /intel Software welche mit Installer ausgeliefert wurde (wie zum Beispiel Intel OneAPI)

Bei der Auswahl von Software sollte darauf geachtet werden dass die Groß- und Kleinschreibung von Bedeutung ist, sprich gcc ist nicht gleich GCC.

Die finalen Pfade sind aktuell auch nicht endgültig festgelegt und können sich noch verändern.

Ferner wird empfohlen sich nicht auf die Defaults zu verlassen und die Version einer Software explizit auszuwählen.

Anwendungsbeispiel:

Die verfügbaren openmpi Versionen lassen sich mit dem Befehl
module spider openmpi
erfragen

Ist daraufhin die Version erwünscht, lässt sich diese mit dem Befehl
module load openmpi/5.0.3-gcc14.1.0
laden.

Aktuell geladene Module lassen sich mit
module list
anzeigen, während
module purge
alle geladenen Module "entlädt".

Aktuell wird die verfügbare Software noch ausgebaut, wodurch sich die Liste relativ schnell entwickelt. Für einen Überblick der aktuell verfügbaren Software wird gebeten diese direkt auf dem System abzufragen. Vor allem mit EasyBuild installierte Software bringt standardmäßig sehr viele kleine Abhängigkeiten mit.

Einen ersten Überblick über einige der wichtigeren Pakete (als Eigenkompilation) bietet die folgende Liste:

==== Verfügbare Software ====

===== Programmiersprachen und Compiler =====
- gcc

- 9.5.0

- 10.5.0

- 11.4.0

- 12.3.0

- 13.2.0

- 14.1.0

- Intel OneApi

- 2024.1

- Julia

- 1.10.3

- python

- 3.8.19

- 3.9.19

- 3.10.14

- 3.11.9

- 3.12.3

- QT (opensource)

- 5.15.14

- R

- 4.4.0

- ruby

- 3.3

===== Bibliotheken und Tools =====
- AMD AOCL

- 4.2.0 gcc

- 4.2.0 aocl

- apache-maven

- 3.9.8

- bash

- 5.2.21

- bc

- 1.0.7

- bison

- 3.8.2

- BLIS

- 4.2.0

- block2

- p0.5.3rc13 openmpi/5.0.3 gcc/14.1.0 OpenBLAS/0.3.26

- boost

- 1.85 gcc/13.2.0

- 1.85 gcc/14.1.0

- Catch2

- 3.6.0 cmake/3.29.3

- cmake

- 3.16.9

- 3.20.6

- 3.27.2

- 3.29.2

- 3.29.3

- costa

2.2.2

- cuda

- 10

- 11

- 12.0

- 12

- 12.1

- 12.2

- 12.3

- 12.4

- 12.4.1

- crest

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc13.2.0 openmpi/5.0.3-gcc13.2.0 gcc/13.2.0

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc14.1.0 openmpi/5.0.3-gcc14.1.0 gcc/14.1.0

fftw

- 3.3.0 gcc/14.1.0

- 3.3.0 openmpi/5.0.3 gcc/14.1.0

- flex

- 2.6.4

- fmt

- 10.2.1

- gsl

- 2.8

- hdf5

- 1.14.4.3

- lapack

- 3.12.0 gcc/13.2.0

- 3.12.0 gcc/14.1.0

- libflame

- 4.2.0

- libunwind

- 1.8.1

- libxc

- 6.6.2

- magma

- 2.8.8

- miniconda3

- 24.3.0-0

- miniforge3

- 24.1.2-0

- mpich

- 3.2.0 gcc/12.3.0

- 3.3.0 gcc/12.3.0

- 4.1.3 gcc/12.3.0

- 4.2.1 gcc/14.1.0

- OpenBLAS

- 0.3.26 gcc/13.2.0

- 0.3.26 gcc/14.1.0

- OpenCoarrays

- 2.9.3 mpich/3.3.0 gcc/12.3.0

- 2.10.2 openmpi/5.0.3 gcc/14.1.0

- OpenMPI

- 4.1.6 gcc/13.2.0

- 5.0.3 gcc/13.2.0

- 5.0.3 gcc/14.1.0

- patch

- 2.7.6

- proj

- 9.4.1 gcc/14.1.0

- scalapack

- 2.2.0

- spglib

- 2.4.0 gcc/14.1.0

- sirius

- 7.5.2

- spla

- 1.6.1

- swig

- 4.2.1

- szip

- 2.1.1

- umpire

- 2024.02.01

===== Software =====
- gdal

- 3.9.0 gcc/14.1.0 proj/9.4.1 swig/4.2.1 python/3.12.3

- hadoopp

- 3.4.0

- hpl

- v2.3

- ior

- 4.0.0 openmpi/5.0.3 gcc/14.1.0

- ncdu

- 1.20

- OpenFOAM

- 11

- v2312

- ORCA

- 5.0.4

- quantum-espresso

- 7.3.1 OpenBLAS/0.3.26 fftw/3.3.10 penmpi/5.0.3 gcc/14.1.0

- xtb

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/13.2.0

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/14.1.0

===== Fehlt was? =====
Da es sich beim HPC um ein Linux System handelt, ist es möglich eigene Software zu entwickeln. Die Einbindung von Software findet überwiegend über zwei grundlegende Variablen statt. <code>PATH</code> für ausführbare Binärdateien sowie <code>LD_LIBRARY_PATH</code> für verlinkte Bibliotheken.

Über ein <code>export PATH=/new/path:$PATH</code> sowie <code>export LD_LIBRARY_PATH=/new/path:$LD_LIBRARY_PATH</code> lassen sich beide erweitern. Diese Änderung gilt bis zum verlassen der Shell - oder ist "semi-permanent" wenn der Export in die .profile oder .bashrc Datei eingetragen wird.

Hierbei gilt es ferner zu beachten dass die Reihenfolge der Auflistung der verschiedenen Pfade von Bedeutung ist: die zuerst gefundene Variante wird genommen.

Obschon es möglich ist eine Software zu kompilieren, bitten wir darum bei fehlender freier Software nach Möglichkeit zuerst eine Anfrage an [mailto:hpc-support@hu-berlin.de hpc-support@hu-berlin.de] zu schicken, damit diese zentral für Alle zugänglich ist.

Bei Anfragen zu kommerzieller Software, internen Eigenentwicklungen oder anderweitig speziell lizenzierter Software stehen wir ebenfalls gerne zu Verfügung.

==== Python ====
Python wird in vielen Projekten eingesetzt. Die Nutzung von Python ist nicht immer problemfrei, darum gibt es folgend einige Empfehlungen für die Nutzung von Python, welche das Risiko von Problemen sowie die Problembeseitigung erleichtern.

Im Allgemeinen sollten Python Anwendungen in einer virtuellen Umgebung entwickelt und ausgeführt werden. Diese wird nativ von Python unterstützt und ermöglicht es Pakete auf einer bestimmten Version zu halten sowie eventuelle Inkompatibilitäten zwischen verschiedenen Projekten zu vermeiden. Ferner ist es möglich bei Problemen eine virtuelle Umgebung zu löschen und dadurch alte Pakete Rückstandslos zu entfernen. Das ist vor allem interessant da <code>pip</code> oder <code>pip3</code> Abhängigkeiten installieren kann, aber im Gegensatz zu typischen Linux-Paketmanagern Abhängigkeiten nicht automatisch deinstallieren kann.

Eine virtuelle Umgebung kann wie folgt erstellt werden (mit einem relativen oder absoluten Pfad):
python -m venv /Pfad/zur/neuen/virtuellen_Umgebung
Mehr dazu auf in der Dokumentation von Python: https://docs.python.org/3/library/venv.html

Sollte es aus bestimmten Gründen nicht möglich sein eine virtuelle Umgebung zu nutzen, kann man mit pip Pakete in einem bestimmten Ordner installieren.
pip3 install --target /Pfad/zum/ZielOrdner
Danach kann der Order zur Variable <code>PYTHONPATH</code> hinzugefügt werden und wird dann von der Python-Umgebung erkannt.

Die virtuellen Umgebungen sind im Allgemeinen jedoch zu präferieren.

Eine weitere Alternative ist die Nutzung von <code>conda</code>, welches in der Form von miniconda angeboten wird. Mit <code>conda</code> lässt sich ebenfalls eine Umgebung erstellen, wobei der Funktionsumfang umfangreicher als bei <code>pip</code> ist, für eine Umgebung in einem bestimmten Pfad lautet der Befehl dann wir folgt:
conda create --prefix /Pfad/zur/neuen/conda_Umgebung
Mit <code>conda init</code> oder <code>mamba init</code> wird die umgebund initiialisiert und die .bashrc Datei wird angepasst. Dabei werden eventuell existierende conda/mamba Konfigurationen überschrieben '''(!!!)'''. Dies ist beim benutzen von mehreren Versionen potenziell problematisch.

Wenn von Nutzerseite ein conda-Ordner angelegt wird, sollte bedacht werden, dass diese im Laufe der Zeit mit der Installation von Paketen recht groß werden können.

Modules & Verfûgbare Software

2024-07-22T13:56:29Z

Mielczad: /* Programmiersprachen */ update software list

==== Übersicht & Grundlagen zur Nuzung ====
Die bereitgestellten Compute-Knoten nutzen Linux, genaugenommen ein OpenSUSE.

HPC-typisch wird zentral Software bereitgestellt. Verfügbare Software wird über eine Modulumgebung geladen.

Welche Software verfügbar ist, lässt sich über <code>module avail</code> sowie <code>module spider <name></code> in Erfahrung bringen.

(Online Anleitung für lmod https://lmod.readthedocs.io/en/latest/010_user.html )

Wir bieten aktuell drei Gruppe von Software an:

# /hu "Von Uns" kompilierte Software welche zentral bereitgestellt wird.
# /all Über EasyBuild ( siehe http://docs.easybuild.io/what-is-easybuild/ ) bereitgestellte Software
# /intel Software welche mit Installer ausgeliefert wurde (wie zum Beispiel Intel OneAPI)

Bei der Auswahl von Software sollte darauf geachtet werden dass die Groß- und Kleinschreibung von Bedeutung ist, sprich gcc ist nicht gleich GCC.

Die finalen Pfade sind aktuell auch nicht endgültig festgelegt und können sich noch verändern.

Ferner wird empfohlen sich nicht auf die Defaults zu verlassen und die Version einer Software explizit auszuwählen.

Anwendungsbeispiel:

Die verfügbaren openmpi Versionen lassen sich mit dem Befehl
module spider openmpi
erfragen

Ist daraufhin die Version erwünscht, lässt sich diese mit dem Befehl
module load openmpi/5.0.3-gcc14.1.0
laden.

Aktuell geladene Module lassen sich mit
module list
anzeigen, während
module purge
alle geladenen Module "entlädt".

Aktuell wird die verfügbare Software noch ausgebaut, wodurch sich die Liste relativ schnell entwickelt. Für einen Überblick der aktuell verfügbaren Software wird gebeten diese direkt auf dem System abzufragen. Vor allem mit EasyBuild installierte Software bringt standardmäßig sehr viele kleine Abhängigkeiten mit.

Einen ersten Überblick über einige der wichtigeren Pakete (als Eigenkompilation) bietet die folgende Liste:

==== Verfügbare Software ====

===== Programmiersprachen =====
- gcc

- 9.5.0

- 10.5.0

- 11.4.0

- 12.3.0

- 13.2.0

- 14.1.0

- Julia

- 1.10.3

- python

- 3.8.19

- 3.9.19

- 3.10.14

- 3.11.9

- 3.12.3

- QT (opensource)

- 5.15.14

- R

- 4.4.0

- ruby

- 3.3

===== Bibliotheken und Tools =====
- AMD AOCL

- 4.2.0 gcc

- 4.2.0 aocl

- apache-maven

- 3.9.8

- bash

- 5.2.21

- bc

- 1.0.7

- bison

- 3.8.2

- BLIS

- 4.2.0

- block2

- p0.5.3rc13 openmpi/5.0.3 gcc/14.1.0 OpenBLAS/0.3.26

- boost

- 1.85 gcc/13.2.0

- 1.85 gcc/14.1.0

- Catch2

- 3.6.0 cmake/3.29.3

- cmake

- 3.16.9

- 3.20.6

- 3.27.2

- 3.29.2

- 3.29.3

- cuda

- 10

- 11

- 12.0

- 12

- 12.1

- 12.2

- 12.3

- 12.4

- 12.4.1

- crest

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc13.2.0 openmpi/5.0.3-gcc13.2.0 gcc/13.2.0

- 3.0.1 cmake/3.29.3 OpenBLAS/0.3.26-gcc14.1.0 openmpi/5.0.3-gcc14.1.0 gcc/14.1.0

fftw

- 3.3.0 gcc/14.1.0

- 3.3.0 openmpi/5.0.3 gcc/14.1.0

- flex

- 2.6.4

- fmt

- 10.2.1

- Intel OneApi

- 2024.1

- lapack

- 3.12.0 gcc/13.2.0

- 3.12.0 gcc/14.1.0

- libflame

- 4.2.0

- miniconda3

- 24.3.0-0

- miniforge3

- 24.1.2-0

- mpich

- 3.2.0 gcc/12.3.0

- 3.3.0 gcc/12.3.0

- 4.1.3 gcc/12.3.0

- 4.2.1 gcc/14.1.0

- OpenBLAS

- 0.3.26 gcc/13.2.0

- 0.3.26 gcc/14.1.0

- OpenCoarrays

- 2.9.3 mpich/3.3.0 gcc/12.3.0

- 2.10.2 openmpi/5.0.3 gcc/14.1.0

- OpenMPI

- 4.1.6 gcc/13.2.0

- 5.0.3 gcc/13.2.0

- 5.0.3 gcc/14.1.0

- patch

- 2.7.6

- proj

- 9.4.1 gcc/14.1.0

- scalapack

- 2.2.0

- spglib

- 2.4.0 gcc/14.1.0

- swig

- 4.2.1

===== Software =====
- gdal

- 3.9.0 gcc/14.1.0 proj/9.4.1 swig/4.2.1 python/3.12.3

- hadoopp

- 3.4.0

- hpl

- v2.3

- ior

- 4.0.0 openmpi/5.0.3 gcc/14.1.0

- ncdu

- 1.20

- OpenFOAM

- 11

- v2312

- ORCA

- 5.0.4

- quantum-espresso

- 7.3.1 OpenBLAS/0.3.26 fftw/3.3.10 penmpi/5.0.3 gcc/14.1.0

- xtb

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/13.2.0

- 6.7.0 lapack/3.12 OpenBLAS/0.3.26 gcc/14.1.0

===== Fehlt was? =====
Da es sich beim HPC um ein Linux System handelt, ist es möglich eigene Software zu entwickeln. Die Einbindung von Software findet überwiegend über zwei grundlegende Variablen statt. <code>PATH</code> für ausführbare Binärdateien sowie <code>LD_LIBRARY_PATH</code> für verlinkte Bibliotheken.

Über ein <code>export PATH=/new/path:$PATH</code> sowie <code>export LD_LIBRARY_PATH=/new/path:$LD_LIBRARY_PATH</code> lassen sich beide erweitern. Diese Änderung gilt bis zum verlassen der Shell - oder ist "semi-permanent" wenn der Export in die .profile oder .bashrc Datei eingetragen wird.

Hierbei gilt es ferner zu beachten dass die Reihenfolge der Auflistung der verschiedenen Pfade von Bedeutung ist: die zuerst gefundene Variante wird genommen.

Obschon es möglich ist eine Software zu kompilieren, bitten wir darum bei fehlender freier Software nach Möglichkeit zuerst eine Anfrage an [mailto:hpc-support@hu-berlin.de hpc-support@hu-berlin.de] zu schicken, damit diese zentral für Alle zugänglich ist.

Bei Anfragen zu kommerzieller Software, internen Eigenentwicklungen oder anderweitig speziell lizenzierter Software stehen wir ebenfalls gerne zu Verfügung.

==== Python ====
Python wird in vielen Projekten eingesetzt. Die Nutzung von Python ist nicht immer problemfrei, darum gibt es folgend einige Empfehlungen für die Nutzung von Python, welche das Risiko von Problemen sowie die Problembeseitigung erleichtern.

Im Allgemeinen sollten Python Anwendungen in einer virtuellen Umgebung entwickelt und ausgeführt werden. Diese wird nativ von Python unterstützt und ermöglicht es Pakete auf einer bestimmten Version zu halten sowie eventuelle Inkompatibilitäten zwischen verschiedenen Projekten zu vermeiden. Ferner ist es möglich bei Problemen eine virtuelle Umgebung zu löschen und dadurch alte Pakete Rückstandslos zu entfernen. Das ist vor allem interessant da <code>pip</code> oder <code>pip3</code> Abhängigkeiten installieren kann, aber im Gegensatz zu typischen Linux-Paketmanagern Abhängigkeiten nicht automatisch deinstallieren kann.

Eine virtuelle Umgebung kann wie folgt erstellt werden (mit einem relativen oder absoluten Pfad):
python -m venv /Pfad/zur/neuen/virtuellen_Umgebung
Mehr dazu auf in der Dokumentation von Python: https://docs.python.org/3/library/venv.html

Sollte es aus bestimmten Gründen nicht möglich sein eine virtuelle Umgebung zu nutzen, kann man mit pip Pakete in einem bestimmten Ordner installieren.
pip3 install --target /Pfad/zum/ZielOrdner
Danach kann der Order zur Variable <code>PYTHONPATH</code> hinzugefügt werden und wird dann von der Python-Umgebung erkannt.

Die virtuellen Umgebungen sind im Allgemeinen jedoch zu präferieren.

Eine weitere Alternative ist die Nutzung von <code>conda</code>, welches in der Form von miniconda angeboten wird. Mit <code>conda</code> lässt sich ebenfalls eine Umgebung erstellen, wobei der Funktionsumfang umfangreicher als bei <code>pip</code> ist, für eine Umgebung in einem bestimmten Pfad lautet der Befehl dann wir folgt:
conda create --prefix /Pfad/zur/neuen/conda_Umgebung
Mit <code>conda init</code> oder <code>mamba init</code> wird die umgebund initiialisiert und die .bashrc Datei wird angepasst. Dabei werden eventuell existierende conda/mamba Konfigurationen überschrieben '''(!!!)'''. Dies ist beim benutzen von mehreren Versionen potenziell problematisch.

Wenn von Nutzerseite ein conda-Ordner angelegt wird, sollte bedacht werden, dass diese im Laufe der Zeit mit der Installation von Paketen recht groß werden können.

Erste Verbindung/Einloggen

2024-07-22T10:11:53Z

Mielczad: Verweis darauf dass der Login Knoten eine geteilte Ressource darstellt

HPC@HU ist aktuell in Entwicklung im Testbetrieb eingeschränkt nutzbar.

Benutzerkonten für Forschende können von den EDV-Beauftragten der einzelnen Fachbereiche über hpc-support@hu-berlin.de angefordert werden.

Sobald ein Nutzer für den HPC-Testbetrieb freigeschaltet wurde, ist es möglich sich über den HU-Account per SSH einzuloggen.

Der Login Knoten befindet sich im Humboldt Universität internen Netz unter der IP-Adresse <code>172.28.105.227</code> und ein Login sähe damit wie folgt aus:
ssh -C AccountName@172.28.105.227
Daraufhin wird zur Eingabe der Passworts aufgefordert. Typisch für SSH ist die Eingabe nicht sichtbar und lässt sich bei einem Fehler mit <code>strg+u</code> (<code>ctrl+u</code>) löschen.

Nach dem ersten Login mit einem Benutzernamen und Passwort wird das home-Verzeichnis erstellt und es ist möglich einen SSH-Schlüssel für zukünftige Verbindungen zu hinterlegen.

Beim mobilen Arbeiten ist der Zugriff nur über das virtuelle private Netzwerk (VPN) der Humboldt Universität möglich.

Es ist anzumerken dass der Login-Knoten eine "shared ressource" darstellt, dessen Aufgabe darin besteht Nutzern eine Schnittstelle fûr das Einreichen an Jobs beim Scheduler zu bieten, sowie eine Möglichkeit bieten relativ einfach und schnell Programme zu kompilieren oder Ergebnisse zu visualisieren.. Der Login-Knoten soll nicht für langlaufende Berechnungen genutzt werden, welche Nutzer und Nutzerinnen der HPC-Ressourcen beeinträchtigt. Sollten langlaufende Berechnungen auf dem Login Knoten gestartet werden, werden diese gegebenenfalls von dem Administrations-Team beendet.

Testbetrieb - Dateistruktur

2024-07-22T07:47:28Z

Mielczad: /* Zugriffsrechte: */

==== Dateistruktur: ====
Im Rahmen des Testbetriebs sind die endgültigen Dateipfade sowie die endgültigen Dateisysteme noch nicht vollständig konfiguriert.

Langfristig wird ein Lustre als zentrales "scratch" bereitgestellt, dieses ist aber aktuell noch nicht verfügbar.

Im Testbetrieb sind folgende Laufwerke verfügbar:

<code>/tmp</code> als lokaler scratch, über 'auto_tmpdir', etwa 1TB

<code>/lustre</code> als geteiltes zentrales Netzwerklaufwerk mit etwa 1.5PB auf das alle Knoten direkt zugreifen können. Es werden automatisch Unterordner für Fachbereiche und Nutzer, ähnlich <code>$HOME</code> angelegt.

<code>/home/<Fachbereich>/<UserID></code> für <code>$HOME</code> als zentrales "home directory" auf das per NFS zugegriffen wird.



Es wird empfohlen im Testbetrieb das lokale Laufwerk zu privilegieren. Auch im Regelbetrieb dürfte dies aufgrund von Latenzen der bevorzugte Pfad sein.

Um die Nutzung des lokalen scratch zu unterstützen wird das Plugin "auto_tmpdir" der University of Delaware genutzt (https://github.com/University-of-Delaware-IT-RCI/auto_tmpdir/tree/master).

Dieses Plugin erstellt einen dedizierten Ordner für einen ausgeführten job welcher dann unter /<code>tmp</code> erreichbar ist (sowie <code>/var/tm</code> und <code>/dev/shm</code> ).

Der Vorteil des Plugins ist, dass sich dieses um de Erstellung der Mounts sowie dem Löschen der Mounts und Dateien kümmert. Da die Dateien nach Ende des Jobs gelöscht werden, ist es wichtig die Ausgabe anderweitig zu "streamen" oder das Endergebnis zu kopieren.

Exemplarisch könnte ein Script für die Nutzung wie folgt aussehen:
#!/bin/bash
#SBATCH --ntasks=1 # Run on a single CPU
#SBATCH --mem=1gb # Job memory request
#SBATCH --time=00:05:00 # Time limit hrs:min:sec
#SBATCH --partition=std
#SBATCH --account=nutzername

## set path to root of job data
basedir=/globalscratch/nutzername/myjob

## copy job data
cp -r $basedir/* /tmp
## change to working director
cd /tmp

## do the work
hostname > $basedir/result.log

## copy the results if they are required
cp -r /tmp/* $basedir

===== Zugriffsrechte: =====

Typisch für ein klassisches SLURM cluster, werden die regulären UNIX Rechte und Gruppen eingesetzt. Diese ermöglichen es Ordner auf dem geteilten Laufwerk nur für bestimmte Nutzer und Gruppen freizugeben. Allerdings ist die regulären Linux Rechteverwaltung hier in Bezug auf eine detaillierte Rechteverteilung stak eingeschränkt. (Da es nicht praktisch möglich ist für alle möglichen Kombinationen dedizierte Gruppen anzulegen.)

Eine feinere Rechteverwaltung, sofern notwendig ist über Access Control Lists (ACL) möglich.

In der der aktuellen Implementierung lassen sich diese über <code>getfacl</code> in Erfahrung bringen, über <code>setfacl</code> setzen oder modifizieren.


Die access control lists werden für den jeweiligen Benutzernamen gesetzt, welcher hier die User-ID des HU-Accounts ist.



Leserechte für eine Datei liesen sich wie folgt setzen:
<code>setfacl -m u:benutzername:r test-datei</code>
Rechte lassen sich ebenfalls rekursiv setzen, wodurch alle Dateien und Ordner abgedeckt sind.
<code>setfacl -Rm u:benutzername:r pfad-zur/test-datei</code>
Weiterführende Informationen zu Access Control Lists inklusive einer Erklärung der "flags" finden sich auf der Seite des Ohio Supercomputing Centre: https://www.osc.edu/resources/getting_started/howto/howto_manage_access_control_list_acls/howto_use_posix_acl

Sollte es notwendig sein die Zugriffsrechte auf spezifische Benutzer (und nicht nur einen Fachbereich) zu begrenzen wird folgender Vorgang empfohlen:

Die regulären UNIX/POSIX-Rechte werden auf den Eigentümer reduziert, ohne Zugriffsrechte für die Gruppe oder Welt. Dies entspräche einem <code>r-x------</code> (500) oder <code>rwx------</code> (700). Das Aufzeigen von Inhalten in Ordnern erfordert hierbei die Ausführungsrechte (<code>x</code>). Für Dateien welche nicht ausgeführt werden reichen Lese- und Schreibrechte (<code>r--</code> / <code>rw-</code> ).

Im nächsten Schritt werden berechtigen Nutzern über die ACLs Zugriffsrechte eingeräumt - der Gruppe bleibt hierbei weiter der Zugriff auf der POSIX-Basis verwehrt.

Anmerkung: Sollte die Vertraulichkeit von Daten eine Einschränkung der Zugriffsrechte erfordern, sollte im Allgemeinen minimalste Rechte eingeräumt werden. So wenige wie möglich, so viele wie erforderlich. Andererseits ist ein konventionelles HPC-Cluster nicht für hochsensible Daten ausgelegt. In diesem Fall bitten wir darum dass mit dem HPC-Team unter [mailto:hpc-suppport@hu-berlin.de hpc-suppport@hu-berlin.de] Kontakt aufgenommen wird um eventuelle Lösungsansätze zu besprechen.

==== Externer Zugriff: ====
Der Zugriff auf das Dateisystem erfolgt über sftp (ftp ûber ssh) aus dem Netz der Humboldt Universität heraus.

Die ist unter Windows mit WinScp ( https://winscp.net/ ) möglich - auch in Verbindung mit putty ( https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html ) für die Befehlszeile - und wird unter Linux im Plasma Desktop nativ von Dolphin unterstützt.

Testbetrieb - Dateistruktur

2024-07-22T07:47:10Z

Mielczad: /* Zugriffsrechte: */ - Umstellung von nfs4 acl auf posix acl welche nun angewendet werden sollten

==== Dateistruktur: ====
Im Rahmen des Testbetriebs sind die endgültigen Dateipfade sowie die endgültigen Dateisysteme noch nicht vollständig konfiguriert.

Langfristig wird ein Lustre als zentrales "scratch" bereitgestellt, dieses ist aber aktuell noch nicht verfügbar.

Im Testbetrieb sind folgende Laufwerke verfügbar:

<code>/tmp</code> als lokaler scratch, über 'auto_tmpdir', etwa 1TB

<code>/lustre</code> als geteiltes zentrales Netzwerklaufwerk mit etwa 1.5PB auf das alle Knoten direkt zugreifen können. Es werden automatisch Unterordner für Fachbereiche und Nutzer, ähnlich <code>$HOME</code> angelegt.

<code>/home/<Fachbereich>/<UserID></code> für <code>$HOME</code> als zentrales "home directory" auf das per NFS zugegriffen wird.



Es wird empfohlen im Testbetrieb das lokale Laufwerk zu privilegieren. Auch im Regelbetrieb dürfte dies aufgrund von Latenzen der bevorzugte Pfad sein.

Um die Nutzung des lokalen scratch zu unterstützen wird das Plugin "auto_tmpdir" der University of Delaware genutzt (https://github.com/University-of-Delaware-IT-RCI/auto_tmpdir/tree/master).

Dieses Plugin erstellt einen dedizierten Ordner für einen ausgeführten job welcher dann unter /<code>tmp</code> erreichbar ist (sowie <code>/var/tm</code> und <code>/dev/shm</code> ).

Der Vorteil des Plugins ist, dass sich dieses um de Erstellung der Mounts sowie dem Löschen der Mounts und Dateien kümmert. Da die Dateien nach Ende des Jobs gelöscht werden, ist es wichtig die Ausgabe anderweitig zu "streamen" oder das Endergebnis zu kopieren.

Exemplarisch könnte ein Script für die Nutzung wie folgt aussehen:
#!/bin/bash
#SBATCH --ntasks=1 # Run on a single CPU
#SBATCH --mem=1gb # Job memory request
#SBATCH --time=00:05:00 # Time limit hrs:min:sec
#SBATCH --partition=std
#SBATCH --account=nutzername

## set path to root of job data
basedir=/globalscratch/nutzername/myjob

## copy job data
cp -r $basedir/* /tmp
## change to working director
cd /tmp

## do the work
hostname > $basedir/result.log

## copy the results if they are required
cp -r /tmp/* $basedir

===== Zugriffsrechte: =====

Typisch für ein klassisches SLURM cluster, werden die regulären UNIX Rechte und Gruppen eingesetzt. Diese ermöglichen es Ordner auf dem geteilten Laufwerk nur für bestimmte Nutzer und Gruppen freizugeben. Allerdings ist die regulären Linux Rechteverwaltung hier in Bezug auf eine detaillierte Rechteverteilung stak eingeschränkt. (Da es nicht praktisch möglich ist für alle möglichen Kombinationen dedizierte Gruppen anzulegen.)

Eine feinere Rechteverwaltung, sofern notwendig ist über Access Control Lists (ACL) möglich.

In der der aktuellen Implementierung lassen sich diese über <code>getfacl</code> in Erfahrung bringen, über <code>setfacl</code> setzen oder modifizieren.


Die access control lists werden für den jeweiligen Benutzernamen gesetzt, welcher hier die User-ID des HU-Accounts ist.



Leserechte für eine Datei liesen sich wie folgt setzen:
<code>setfacl -m u:benutzername:r test-datei</code>
Rechte lassen sich ebenfalls rekursiv setzen, wodurch alle Dateien und Ordner abgedeckt sind.
<code>setfacl -Rm u:benutzername:r pfad-zur/test-datei</code>
Weiterführende Informationen zu Access Control Lists inklusive einer Erklärung der "flags" finden sich auf der Seite des Ohio Supercomputing Centre: https://www.osc.edu/resources/getting_started/howto/howto_manage_access_control_list_acls/howto_use_posix_acl


Sollte es notwendig sein die Zugriffsrechte auf spezifische Benutzer (und nicht nur einen Fachbereich) zu begrenzen wird folgender Vorgang empfohlen:

Die regulären UNIX/POSIX-Rechte werden auf den Eigentümer reduziert, ohne Zugriffsrechte für die Gruppe oder Welt. Dies entspräche einem <code>r-x------</code> (500) oder <code>rwx------</code> (700). Das Aufzeigen von Inhalten in Ordnern erfordert hierbei die Ausführungsrechte (<code>x</code>). Für Dateien welche nicht ausgeführt werden reichen Lese- und Schreibrechte (<code>r--</code> / <code>rw-</code> ).

Im nächsten Schritt werden berechtigen Nutzern über die ACLs Zugriffsrechte eingeräumt - der Gruppe bleibt hierbei weiter der Zugriff auf der POSIX-Basis verwehrt.

Anmerkung: Sollte die Vertraulichkeit von Daten eine Einschränkung der Zugriffsrechte erfordern, sollte im Allgemeinen minimalste Rechte eingeräumt werden. So wenige wie möglich, so viele wie erforderlich. Andererseits ist ein konventionelles HPC-Cluster nicht für hochsensible Daten ausgelegt. In diesem Fall bitten wir darum dass mit dem HPC-Team unter [mailto:hpc-suppport@hu-berlin.de hpc-suppport@hu-berlin.de] Kontakt aufgenommen wird um eventuelle Lösungsansätze zu besprechen.

==== Externer Zugriff: ====
Der Zugriff auf das Dateisystem erfolgt über sftp (ftp ûber ssh) aus dem Netz der Humboldt Universität heraus.

Die ist unter Windows mit WinScp ( https://winscp.net/ ) möglich - auch in Verbindung mit putty ( https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html ) für die Befehlszeile - und wird unter Linux im Plasma Desktop nativ von Dolphin unterstützt.

Testbetrieb - Dateistruktur

2024-07-19T14:41:27Z

Mielczad: /* Zugriffsrechte: */

==== Dateistruktur: ====
Im Rahmen des Testbetriebs sind die endgültigen Dateipfade sowie die endgültigen Dateisysteme noch nicht vollständig konfiguriert.

Langfristig wird ein Lustre als zentrales "scratch" bereitgestellt, dieses ist aber aktuell noch nicht verfügbar.

Im Testbetrieb sind folgende Laufwerke verfügbar:

<code>/tmp</code> als lokaler scratch, über 'auto_tmpdir', etwa 1TB

<code>/lustre</code> als geteiltes zentrales Netzwerklaufwerk mit etwa 1.5PB auf das alle Knoten direkt zugreifen können. Es werden automatisch Unterordner für Fachbereiche und Nutzer, ähnlich <code>$HOME</code> angelegt.

<code>/home/<Fachbereich>/<UserID></code> für <code>$HOME</code> als zentrales "home directory" auf das per NFS zugegriffen wird.



Es wird empfohlen im Testbetrieb das lokale Laufwerk zu privilegieren. Auch im Regelbetrieb dürfte dies aufgrund von Latenzen der bevorzugte Pfad sein.

Um die Nutzung des lokalen scratch zu unterstützen wird das Plugin "auto_tmpdir" der University of Delaware genutzt (https://github.com/University-of-Delaware-IT-RCI/auto_tmpdir/tree/master).

Dieses Plugin erstellt einen dedizierten Ordner für einen ausgeführten job welcher dann unter /<code>tmp</code> erreichbar ist (sowie <code>/var/tm</code> und <code>/dev/shm</code> ).

Der Vorteil des Plugins ist, dass sich dieses um de Erstellung der Mounts sowie dem Löschen der Mounts und Dateien kümmert. Da die Dateien nach Ende des Jobs gelöscht werden, ist es wichtig die Ausgabe anderweitig zu "streamen" oder das Endergebnis zu kopieren.

Exemplarisch könnte ein Script für die Nutzung wie folgt aussehen:
#!/bin/bash
#SBATCH --ntasks=1 # Run on a single CPU
#SBATCH --mem=1gb # Job memory request
#SBATCH --time=00:05:00 # Time limit hrs:min:sec
#SBATCH --partition=std
#SBATCH --account=nutzername

## set path to root of job data
basedir=/globalscratch/nutzername/myjob

## copy job data
cp -r $basedir/* /tmp
## change to working director
cd /tmp

## do the work
hostname > $basedir/result.log

## copy the results if they are required
cp -r /tmp/* $basedir

===== Zugriffsrechte: =====
'''NOTE TO DO: Update auf lustre access control lists -''' Lustre hat seine eigenen Einstellungen für Access Control lists, dieser Abschnitt muss entsprechend überarbeitet werden.

Typisch für ein klassisches SLURM cluster, werden die regulären UNIX Rechte und Gruppen eingesetzt. Diese ermöglichen es Ordner auf dem geteilten Laufwerk nur für bestimmte Nutzer und Gruppen freizugeben. Allerdings ist die regulären Linux Rechteverwaltung hier in Bezug auf eine detaillierte Rechteverteilung stak eingeschränkt. (Da es nicht praktisch möglich ist für alle möglichen Kombinationen dedizierte Gruppen anzulegen.)

Eine feinere Rechteverwaltung, sofern notwendig ist über Access Control Lists (ACL) möglich.

In der der aktuellen Implementierung lassen sich diese über <code>nfs4_getfacl</code> in Erfahrung bringen, über <code>nf4_setfacl</code> setzen und über <code>nfs4_editfacl</code> editieren.

Es ist möglich die Rechte über den Benutzernamen zu setzen, dabei muss dieser als <code>benutzername@localdomain</code> eingegeben werden.

Alternativ kann die ID des Nutzers oder einer Gruppe genutzt werden, welche sich über <code>id -u benutzername</code> oder <code>getent group gruppenname</code> abfragen lassen.

Leserechte für eine Datei liesen sich wie folgt setzen:
nfs4_setfacl -a "A::benutzername@localdomain:RX" test-datei
Rechte lassen sich ebenfalls rekursiv setzen, wodurch alle Dateien und Ordner abgedeckt sind, mit den Optionen <code>d</code> und <code>f</code> werden die Zugriffsrechte auf neu erstellte Dateien und Unterverzeichnisse vererbt.
nfs4_setfacl -R -a "A:df:benutzername@localdomain:rx" pfad-zur/test-datei
Weiterführende Informationen zu Access Control Lists inklusive einer Erklärung der "flags" finden sich auf der Seite des Ohio Supercomputing Centre: https://www.osc.edu/book/export/html/4523

Sollte es notwendig sein die Zugriffsrechte auf spezifische Benutzer (und nicht nur einen Fachbereich) zu begrenzen wird folgender Vorgang empfohlen:

Die regulären UNIX/POSIX-Rechte werden auf den Eigentümer reduziert, ohne Zugriffsrechte für die Gruppe oder Welt. Dies entspräche einem <code>r-x------</code> (500) oder <code>rwx------</code> (700). Das Aufzeigen von Inhalten in Ordnern erfordert hierbei die Ausführungsrechte (<code>x</code>). Für Dateien welche nicht ausgeführt werden reichen Lese- und Schreibrechte (<code>r--</code> / <code>rw-</code> ).

Im nächsten Schritt werden berechtigen Nutzern über die ACLs Zugriffsrechte eingeräumt - der Gruppe bleibt hierbei weiter der Zugriff auf der POSIX-Basis verwehrt.

Anmerkung: Sollte die Vertraulichkeit von Daten eine Einschränkung der Zugriffsrechte erfordern, sollte im Allgemeinen minimalste Rechte eingeräumt werden. So wenige wie möglich, so viele wie erforderlich. Andererseits ist ein konventionelles HPC-Cluster nicht für hochsensible Daten ausgelegt. In diesem Fall bitten wir darum dass mit dem HPC-Team unter [mailto:hpc-suppport@hu-berlin.de hpc-suppport@hu-berlin.de] Kontakt aufgenommen wird um eventuelle Lösungsansätze zu besprechen.

==== Externer Zugriff: ====
Der Zugriff auf das Dateisystem erfolgt über sftp (ftp ûber ssh) aus dem Netz der Humboldt Universität heraus.

Die ist unter Windows mit WinScp ( https://winscp.net/ ) möglich - auch in Verbindung mit putty ( https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html ) für die Befehlszeile - und wird unter Linux im Plasma Desktop nativ von Dolphin unterstützt.