Modules & Verfûgbare Software: Unterschied zwischen den Versionen

Aktuelle Version vom 24. Juli 2024, 10:01 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 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. 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, 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):

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 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.

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

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 /lustre/<Fakultät>/<Benutzername> lauten.

Mit conda init oder mamba init 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 lmod einzubinden, wie in der Dokumentation beschrieben: https://lmod.readthedocs.io/en/latest/020_advanced.html

Eine Môglichkeit besteht in dem Befehl module use /path/to/personal/modulefiles, alternativ kann der Pfad zu privaten Moduldateien auch gleich zur Variable $MODULEPATH 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 /software/modules als Inspiration dienen.

Für Nutzer:

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