Modules & Verfûgbare Software: Unterschied zwischen den Versionen

Version vom 18. Juli 2024, 08:43 Uhr

Ü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 module avail sowie module spider <name> 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

- 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

- 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. PATH für ausführbare Binärdateien sowie LD_LIBRARY_PATH für verlinkte Bibliotheken.

Über ein export PATH=/new/path:$PATH sowie export LD_LIBRARY_PATH=/new/path:$LD_LIBRARY_PATH 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 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):

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 PYTHONPATH 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 conda, welches in der Form von miniconda angeboten wird. Mit conda lässt sich ebenfalls eine Umgebung erstellen, wobei der Funktionsumfang umfangreicher als bei pip ist, für eine Umgebung in einem bestimmten Pfad lautet der Befehl dann wir folgt:

conda create --prefix /Pfad/zur/neuen/conda_Umgebung

Mit conda init oder mamba init 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.

@@ Zeile 312: / Zeile 312: @@
 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.