Thomas Zeiser

Some comments by Thomas Zeiser about HPC@RRZE and other things

Content

Recipe for building OpenFOAM-1.7.1 with Intel Compilers and Intel MPI

Compared with other software, installing OpenFOAM is (still) a nightmare. They use their very own build system, there are tons of environment variables to set, etc. But it seems that users in academia and industry accept OpenFOAM nevertheless. For release 1.7.1, I took the time to create a little receipt (in some parts very specifically tailored to RRZE’s installation of software packages) to more or less automatically build OpenFOAM and some accompanying Third Party packages from scratch using the Intel Compilers (icc/icpc) and Intel MPI instead of Gcc and Open MPI (only Qt and Paraview are still built using gcc). The script is provided as-is without any guarantee that it works elsewhere and of course also without any support. The script assumes that the required source code packages have already been downloaded. Where necessary, the unpacked sources are patched and the compilation commands are executed. Finally, two new tar balls are created which contain the required “output” for a clean binary installation, i.e. intermediate output files (e.g. *.dep) are not included …

Compilation takes ages, but that’s not really surprising. Only extracting the tar balls with the sources amounts to 1.6 GB in almost 45k files/directories. After compilation (although neither Open MPI nor Gcc are built) the size is increased to 6.5 GB or 120k files. If all intermediate compilation files are removed, there are still about 1 GB or 30k files/directories remaining in my “clean installation” (with only the Qt/ParaView libraries/binaries in the ThirdParty tree).

RRZE users find OpenFOAM-1.7.1 as module on Woody and TinyBlue. The binaries used for Woody and TinyBlue are slightly different as both were natively compiled on SuSE SLES 10SP3 and Ubuntu 8.04, respectively. The main difference should only be in the Qt/Paraview part as SLES10 and Ubuntu 8.04 come with different Python versions. ParaView should also be compiled with MPI support.

Note (2012-06-08): to be able to compile src/finiteVolume/fields/fvPatchFields/constraint/wedge/wedgeFvPatchScalarField.C with recent versions of the Intel compiler, one has to patch this file to avoid an no instance of overloaded function “Foam:operator==” matches the argument list error message; cf. http://www.cfd-online.com/Forums/openfoam-installation/101961-compiling-2-1-0-rhel6-2-icc.html and https://github.com/OpenFOAM/OpenFOAM-2.1.x/commit/8cf1d398d16551c4931d20d9fc3e42957d0f93ca. These links are for OF-2.1.x but the fix works for OF-1.7.1 as well.

Halbzeit beim Projekt SKALB

Beim BMBF-HPC-Verbundprojekt “SKALB” (Lattice-Boltzmann-Methoden für skalierbare Multi-Physik-Anwendungen) ist inzwischen die Hälfte der Projektlaufzeit verstrichen. Wer sich über die bisherigen Projektergebnisse informieren will, findet auf der Projekt-Webseite www.skalb.de in der Rubrik Ergebnisse & Showcases neben einer Auflistung von Vorträgen und Publikationen auch die Managementzusammenfassungen der Projektzwischenberichte für die ersten drei Halbjahre.

Rechnerzuwachs und Generationswechsel bei den HPC-Clustern am RRZE

Vorarbeiten

Kabeltrassen, Stromverteilung und Kaltwasserverrohrung im Doppelboden.

Rechnerzuwachs klingt doch recht bescheiden, aber so sind wir eben. Dennoch ist am RRZE seit Wochen eine deutlich erhöhte Betriebsamkeit und Bautätigkeit zu beobachten. Es werden dicke Wasserrohre (15 cm Durchmesser) geschleppt und vom Keller bis in den ersten Stock verlegt und zusammengeschweißt, die Decken durchlöchert (Kernbohrungen mit bis ca. 25 Durchmesser für die Kaltwasserrohre inkl. deren Isolierung), neue Stromleitungen (Kabel mit ca. 5cm Durchmesser) verlegt und Vorbereitungen für einen neuen Trafo getroffen, der Doppelboden in Teilen des Rechnerraums verstärkt, etc. — nicht zuletzt wurde zuvor bereits der ehemalige Medizinbereich im Rechnerraum freigeräumt und auch einige ISER-Stücke mussten für die HPC-Installation weichen (finden aber z.T. in anderen Bereichen des Rechnerraums wieder Unterschlupf).

Anlieferung der Rechenknoten

... bis auf 5 Paletten war der gesamte Inhalt des Lasters für uns -- aber es war nicht der einzige LKW, der mit harter Ware für uns vorgefahren ist.


Anlieferung der Racks. Überall wo jetzt noch Löcher in den Bodenplatten zu sehen sind, werden Racks stehen.

Seit einer Woche Rollen nun schon immer wieder LKWs mit IT-Equipment an; inzwischen dürften es mehr als 60 Paletten mit Rechenknoten, Servern, Festplatten, Netzkomponenten, vielen vielen Kabeln, Racks und Kühleinheiten gewesen sein — so 5-10 Tonnen dürften da schon zusammengekommen sein.

Möglich wurde all dies durch einen Forschungsgroßgeräteantrag, zusätzliche Mittel von einigen Lehrstühlen und auch noch Restmittel aus dem Konjunkturpaket-II (letzteres speziell auch für diverse Bau-/Infrastrukturmaßnahmen), etc. …

Der neue HPC-Rechner wird LiMa heißen

  • Das Akronym LiMa entstand zunächst durch die Abkürzung zweier Leuchtturmprojekte aus dem Forschungsgroßgeräteantrag.
  • Wikipedia hat für Lima (mit kleinem “M”) auch viele Optionen zu Auswahl:
    Angefangen von der Hauptstadt Perus und weiterer Städte weltweit (geographische Angaben sind ja durchaus beliebt zur Benennung von IT-Dingen, vgl. nicht zuletzt Intel/AMD-Prozessoren),
    … über die malaysische/indonesische Zahl “fünf” oder die tibetische Bezeichnung für eine aus mindestens fünf verschiedenen Metallen bestehende Legierung zur Herstellung von Statuen und Glocken (wir haben mindestens fünf zentrale Bestandteile: Rechenknoten, Hochgeschwindigkeitsnetzwerk, paralleles Filesystem, Software und Stromversorgung/Kühlung)
    … bis hin zum Buchstaben “L” im ICAO-Buchstabieralphabet.
  • Nachdem der LiMa-Cluster aber etwas größer wird als TinyBlue, verglichen mit großen Clustern (z.B. JuRoPa am JSC/FZ-Jülich) aber noch klein ist, kann LiMa auch für Little Machine stehen. Hieran erkennt man die fränkische Bescheidenheit. Obwohl LiMa zum Zeitpunkt der Inbetriebnahme der leistungsstärkste Rechner (bezogen auf die Peak-Performance und wohl auch die Linpack-Leistung) sein wird und mit seinen 63.8 TFlop/s Peak einen (kleinen) Vorsprung vor dem HLRB-II mit 62.3 TFop/s hat, erscheint “SuperFranke”, “SuperERL” oder gar “SuperFranconianAdvancedCluster” (in Anlehnung an SuperMUC, dem aktuellen Beschaffungsprojekt am LRZ) unpassend und übertrieben …

Mal abwarten, welche Erklärung sich für das Akronym letztendlich durchsetzen wird …

Zurück zu den harten Fakten des LiMa-Clusters

Im Rahmen eines europaweiten Ausschreibungsverfahrens wurde die HPC-Lösung mit dem besten Preis-Leistungsverhältnis bestimmt, wobei das Gesamtbudget vorgegebenem war. Neben der Menge der Hardware spielte dabei insbesondere auch die zugesicherte Leistung für einen typischen Erlanger Applikationsmix eine zentrale Rolle. Neun Firmen haben Ende Mai gültige Angebote abgegeben. Als Gewinner der Ausschreibung und somit Lieferant des LiMa-Clusters ist NEC hervorgegangen (Link zur NEC-PRessemeldung).

Der jetzt installierte Cluster stammt aus der NEC LX-2400 HPC-Cluster-Serie und umfasst:

  • 500 Rechenknoten mit jeweils zwei Intel Xeon 5650 Prozessoren (6-Core Westmere 2,66 GHz), 24 GB DDR3 RAM, QDR-Infiniband, ohne lokale Festplatte; jeweils 4 Rechenknoten sind dabei in einem 2U hohen Gehäuse untergebracht (“Twin2”); insgesamt sind es also 6000 (physikalische) Rechenkerne und knapp 12 TB (verteilter) Hauptspeicher
  • paralleles Filesystem (NEC LXFS = auf Lustre-Basis) mit 120 TB Nutzkapazität auf rund 180 Festplatten (inkl. RAID6-Parity-Platten und Hot-Spare-Platten) und einer aggregierten Bandbreite von 3 GB/s zur kurzfristigen Ablage von Simulationsdaten
  • QDR-Infiniband-Netzwerk mit vollständiger Fat-Tree Topologie ohne Ausdünnungen
  • 11 geschlossene Racks mit beigestellten Kühleinheiten (=> Rechenknoten); 3 offene Racks (=> Netzwerkkomponenten, Storage, Login- und Managementserver)
  • CentOS 5.5 als Betriebssystem, torque/maui als Batchsystem, …

Aktueller Stand der LiMa-Installation

Verlegung der Infiniband-Verkabelung.

Die NEC-Mitarbeiter kämpfen derzeit noch fleißig mit dem Verlegen der Kabel (insgesamt knapp 2000 Stück; insbesondere die Infiniband-Kabel sind dabei auch noch unhandlich dick) …

Auch die Kaltwasserverrohrung vom Keller bis hoch in den Rechnerraum im 1. OG ist noch nicht vollständig fertiggestellt.

Die Arbeiten gehen aber grundsätzlich zügig voran. Die erste Inbetriebnahme wird jedoch trotzdem noch ein paar Tage auf sich warten lassen — rechtzeitig vor der Frist für die Einreichung zur nächsten Top500-Liste, die im November veröffentlicht wird, sollte jedoch alles laufen. Nicht dass wir auf den Linpack-Wert besonders scharf sind, aber es schadet sicherlich nicht, wenn Franken mal wieder im vorderen Mittelfeld der Top500 sichtbar ist …

Auf die Frage, wann denn der reguläre Benutzerbetrieb beginnt, gibt es eine sehr einfache FAQ-Antwort: wenn alles fertig ist und stabil läuft. Nicht früher und auch nicht später. Weitere Fragen nach einem Termin erübrigen sich damit hoffentlich.

Komplementäre Ergänzung durch TinyFat

Parallel zu LiMa wurden in einem weiteren gekühlten Rack dicke Knoten für Anwender mit hohem Hauptspeicherbedarf beschafft und durch das RRZE installiert:

  • 17 Knoten (HL DL385G7) mit jeweils zwei 8-Core AMD MagnyCours Prozessoren (2,3 GHz), 128 GB Hauptspeicher und ebenfalls QDR-Infiniband
  • 1 Knoten (HP DL580G7) mit vier 8-Core Intel Nehalem EX Prozessoren und 512 GB (=0.5 TB) Hauptspeicher

TinyFat — der Ursprung für den Namen dürfte klar sein — geht in den Betrieb, sobald die Kühlung der Knoten sichergestellt ist, d.h. die Kühleinheiten mit Kaltwasser aus der zentralen Kälteversorgung verbunden sind.

Betriebsende für (weitere) Teile des “Cluster32” steht bevor

Bereits im vergangenen Jahr musste der älteste Teil des alten Cluster32 (“Transtec-Cluster”) mit den snode0xx-Knoten für TinyBlue weichen. Nachdem jetzt insbesondere mit LiMa so viel neue Hardware gekommen ist, wird in den nächsten Monaten wohl der nächste Teil des “Cluster32” außer Betrieb genommen werden. Insbesondere die beiden Racks mit den snode1xx-Knoten sind nach über 5 Jahren Betrieb nicht mehr wirklich auf der Höhe der Zeit, obwohl die Knoten durchaus noch immer gut ausgelastet sind. Neun (seit der letzten Abschaltung evtl. auch ein paar mehr) der ursprünglich einmal 64 Knoten mit je zwei “Nocona”-CPUs (d.h. der ersten Generation von Intel NetBurst-Prozessoren mit “EM64T”) sind aufgrund von Hardwaredefekten sowieso bereits aus …

2009 ist also die 32-bit Ära bei uns mit der Abschaltung der snode0xx-Knoten zu Ende gegangen, 2010 wird mit der Abschaltung der snode1xx-Knoten dann auch noch die Single-Core-Ära für HPC@RRZE beendet werden. Willkommen im reinen Multi-/ManyCore-Zeitalter

Details zur Abschaltung werden aber noch rechtzeitig folgen.

slight change of the Intel compiler modules: MKL modules loaded automatically

Starting from today, our intel64 compiler modules for version 11.0 and 11.1 of the Intel compilers will automatically load the MKL module corresponding to the bundled version in the Intel Processional Compilers, too.

  • If you do not use MKL, this change will not affect you.
  • If you want (or have) to use a different version of MKL, you have to load the MKL module before loading the compiler module OR you have to unload the automatically loaded MKL module before loading your desired version.

Motivation for this change was to make the compiler option -mkl work properly (or at least better), i.e. give the user a reasonable chance to find the MKL libraries at runtime. You still have to load the compiler (or mkl) module at runtime OR you have to add -Wl,-rpath,$MKLPATH explicitly to your linker arguments …

Zuwachs im TinyGPU-Cluster

TinyGPU hat Zuwachs bekommen: tg010. Die Hardware-Ausstattung und aktuell auch die Software dieses “Fermi-Knotens” sind anders als bei den restlichen acht Knoten:

  • Ubuntu 10.04 LTS (statt 8.04 LTS) als Betriebssystem.
    Hinweis: Um lokal auf tg010 mit Intel Compilern <= 11.1 übersetzen zu können, muss [derzeit] das gcc/3.3.6 Modul geladen werden, da sonst libstdc++.so.5 nicht gefunden wird, da diese Bibliothek in Ununtu 10.04 nicht mehr enthalten ist. Das gcc/3.3.6-Modul wird nur zum Übersetzen benötigt – fertige Intel-Binaries laufen auch ohne problemlos.
  • Die Nvidia-Treiberversion ist inzwischen auf allen Knoten identisch; aktuell: 256.40 / seit 8. Sept. 2010 überall 256.53
  • /home/hpc und /home/vault sind (nur) per NFS gemountet (und nativ via GPFS-Cross-Cluster-Mount)
  • Dual-Socket-System mit Intel Westmere X5650 (2.66 GHz) Prozessoren mit 6 physikalischen Kernen pro Socket (statt Dual-Socket-System mit Intel Nehalem X5550 (2.66 GHz) mit 4 physikalischen Kernen pro Socket)
  • 48 GB DDR3 RAM (statt 24 GB DDR3 RAM)
  • 1x NVidia Tesla C2050 (“Fermi” mit 3 GB GDDR5 mit ECC)
  • 1x NVidia GTX 280 (Consumer-Karte mit 1 GB RAM – war früher im Testcluster)
  • 2 weitere PCIe2.0 16x Slots werden in Q4 wohl noch mit NVidia C2070 Karten (“Fermi” mit 6 GB GDDR5 mit ECC) bestückt werden
  • statt 2x NVidia Tesla M1060 (“Tesla” mit 4 GB RAM) wie in den restlichen TinyGPU-Knoten
  • SuperServer 7046GT-TRF / X8DTG-QF mit Dual Intel 5520 (Tylersburg) Chipset statt SuperServer 6016GT-TF-TM2 / X8DTG-DF mit einem Intel 5520 (Tylersburg) Chipset

Um den “Fermi-Knoten” anzufordern, müssen Jobs :ppn=24 verwenden (statt :ppn=16) und explizit in die neue TinyGPU-Queue fermi submittiert werden. Das Laufzeitlimit ist wie üblich 24h. Ob ECC auf der Fermi-Karte aktuell ein- oder ausgeschaltet ist, wird beim Jobstart angezeigt.