GIS auf dem GFZ Computercluster: Stand 2012 - Präsentation im Geoinformatik-Kolloquium des GFZ, Juni 2012

1. Geoinformatik-Kolloquium
GRASS GIS auf dem High Performance Cluster
Peter Löwe, Jan Thaler
(CeGIT)

2. Gliederung
 Überblick und Historie von GRASS GIS
 GRASS GIS auf dem GFZ Compute Cluster
 Praktische Beispiele aus dem TRIDEC Projekt

3. GRASS GIS in seinen „Späten Zwanzigern“
 1982: Entwicklung von GRASS GIS beginnt (US Army)
 1987: Promotion-Video, erzählt von William Shatner
 1997: Software veröffentlicht als Public Domain (GRASS 4.2)
 1999: GRASS wird Free and Open Source Software (GPL)
 2011: GRASS Version 7.0 in Entwicklung
http://grass.osgeo.org/grass_movie_CERL_1987/
http://grass.fbk.eu/images/gbanner.gif

4. Überblick
 GRASS GIS ist Open Source Software (GPL-Lizenz)
 Große Nutzerbasis
 Umfangreiche Dokumentation
 > 350 Module (Raster- / Vektor- /Volumenprozessierung)
 Eingebaute 3D-Visualisierung (NVIZ)
 Schnittstellen zu R, Paraview, PostGREs, und vielen weiteren
 Module-Code: C
 Scripting in Python, Shell, Perl, etc.
 Verfügbar für MS Windows / OS X / Linux; embedded in
Quantum GIS (QGIS)

5. Beispiele
Source: http://grass.fbk.eu/images/

6. Anwendungsfälle für Clusternutzung
 Langwierige Berechnungen
– Der Cluster ist immer verfügbar
– Zeitaufwändigste Berechnung bisher: 20 Tage
 Gleichartige Berechnungen
– Anwendung des gleichen Algorithmus auf verschiedene Ausgangsdaten bzw. auf die
gleichen Daten mit unterschiedlichen Parametern – einfache Parallelisierbarkeit
 „Teile und herrsche“
– Zeitaufwendige Berechnungen auf sehr großen Daten bei denen man an schnellen
Ergebnissen interessiert ist.
– Aufteilung der Daten in kleinere Teile, die parallel prozessiert werden. (GRASS Modul:
r.tileset)

7. Der GFZ Compute Cluster
• Linux-Cluster aktuell: 234 Knoten, 480
CPUs, 3084 Kerne
• Zu Beginn (2004) 32 Knoten, mehrere
Erweiterungen
• AMD Opteron CPUs, SLES 11
• Teilweise exklusive Nutzung, teilweise
bevorrechtigte Nutzung für finanzierende
Gruppen
• Infiniband Netzwerk
• Netzwerk-Dateisystem und lokaler
Speicher auf Knoten
• LSF Batch-System mit Queues für die
verschiedenen Bereiche

8. Benutzung des Clusters
• Bedingung: Cluster-Account
• Zu beantragen bei Marina Köhler (koe@gfz-potsdam.de)
 Zugriff von jedem Computer im GFZ-Netzwerk
 Linux: ssh
 Windows: PuTTY
 Zugriff von außerhalb via VPN
 Dateitransfer: sftp, scp, (Filezilla)

9. GRASS GIS auf dem GFZ Compute Cluster
 Erste Experimente in 2008
 GRASS GIS läuft auf dem Zugangsknoten und allen
anderen 234 Knoten
 Status:
 GRASS 6.4.2 („stable“) ist für alle Nutzer installiert
 GRASS 7 („trunk“) befindet sich in der Testphase
 Ziel: Bereitstellung einer Auswahl von Versionen für alle
Nutzer

10. Nutzung von GRASS auf dem Cluster
 GRASS kann benutzt werden via
– Kommandozeile (Command line interface, CLI)
– CLI + Kartenfenster bzw. GRASS „Monitore“: GRASS 6.4
– Grafische Benutzeroberfläche: GRASS 6.4 / 7.0
• Login am Zugangsknoten glic des Clusters
• Laden des GRASS-Moduls
• Ggf. Starten einer GRASS-Session
• Ausführen einfacher Operationen auf dem Portalknoten möglich
• Ausführen rechenintensiver Operationen auf den Knoten über
ein GRASS-Skript mit dem speziellem Befehl grass_clusterjob

11. Praxisbeispiel:
Login
PuTTY unter MS Windows

12. Praxisbeispiel:
Login
PuTTY unter MS Windows
Load GRASS
module

13. Praxisbeispiel:
Login
PuTTY unter MS Windows
Load GRASS
module
Start GRASS

14. Praxisbeispiel:
Login
PuTTY unter MS Windows
Load GRASS
module
Start GRASS

15. Praxisbeispiel:
Login
PuTTY unter MS Windows
Load GRASS
module
Start GRASS
Kommando-
zeileneingabe

16. Praxisbeispiel:
Login
PuTTY unter MS Windows
Load GRASS
module
Start GRASS
Kommando- Graphisches
zeileneingabe Interface

17. Praxisbeispiel:
Login
PuTTY unter MS Windows
Load GRASS
module
Start GRASS
Kommando- Graphisches Darstellungs-
zeileneingabe Interface fenster

18. Wissensbasis Dokuwiki: GRASS GIS
http://dokuwiki.gfz-potsdam.de/gis

19. Dokuwiki: Geodaten / GRASS

20. Datenhaltung und Beispiele
• Geodaten werden in GRASS meist als „GIS-Projekt“ vorgehalten
• „Projekt“ = GRASS-Location:
– Projektionsinformation (aus EPSG, Daten, etc.)
• Eine Location umfasst 1-n Mapsets:
– Mapsets enthalten Vektoren, Rasterdaten und Volumen
– Die Mapsets einer Location können unterschiedliche räumliche Ausdehnungen und
Auflösungen haben
– Mit Mapsets können Daten räumlich oder thematisch gegliedert werden
– Inhalte können zwischen Mapsets ausgetauscht werden
• Demo-Location: „Spearfish, North Dakota“
– Eine fertige GRASS-Location kann in das eigene Nutzerverzeichnis kopiert und benutzt
werden.
– Weitere Informationen und Tutorials liegen im Wiki.

21. Extra-Modul zur Lastverteilung:
grass_clusterjob
• Syntax: grass_clusterjob [parameters] SCRIPT_NAME SCRIPT_PARAMETERS
• Parameter:
– -q QUEUE_NAME Benutze die genannte Queue
– -o OUTPUT_FILE Schreibe Ausgabe in Datei (ansonsten per Mail)
– -d GISDBASE Benutze das genannte Verzeichnis
– -l LOCATION_NAME Benutze die genannte Location
– -m MAPSET Benutze das genannte Mapset
– -n Benutze das Netzwerkdateisystem anstatt des lokalen Speichers
– -r Entferne das GRASS-Skript nach Ausführung
• Das Skript muss ausführbar sein und gefunden werden (Angabe
mit Pfad oder in PATH).

22. Dokuwiki: grass_clusterjob Dokumentation

23. Beispiel-Anwendungen im Dokuwiki
Payload = Auf einem HPC-Kern
auszuführende GRASS-Befehle
GRASS Modul-Aufruf
GRASS Modul-Aufruf
Mehrfacher Aufruf des
GRASS-Moduls in einer
FOR-Schleife

24. Geschachtelte parametrisierte Skripte
• Inhalt des auszuführenden GRASS-Skript Templates:
r.in.gdal –oe input=wave2d_XXX output=simulation_XXX Name:
„TEMPLATE“
• Inhalt des steuernden Shell-Skripts:
for i in {1..100}
do
cat TEMPLATE | sed "s/XXX/${i}/g" > SKRIPT_${i}.CLW
grass_clusterjob SKRIPT_${i}.CLW
done
Delegieren der 100 konfigurierten
r.in.gdal GRASS-Kommandos auf die
HPC Knoten

25. Hinter den Kulissen
• Es wird eine neue GRASS-Session auf einem Knoten erzeugt, die
unabhängig von einer evtl. aktiven GRASS-Session ist.
• Aus GRASS heraus: Verzeichnis, aktive Location und Mapset werden übernommen.
• Aus der Login-Shell: Nutzer muss Verzeichnis, Location und Mapset angeben.
• Die Session ist nicht interaktiv und arbeitet nur das Skript ab.
• Ein temporäres Mapset mit eindeutigem Namen wird angelegt
• Alle Karten des Original-Mapsets sind weiter verfügbar.
• In diesem Mapset wird das Skript ausgeführt.
• Anschließend werden die Ergebnisse in das Original-Mapset
zurückkopiert und das temporäre Mapset wird gelöscht.

26. Was macht mein Skript?
• Das Skript wird als normaler Job auf dem Cluster ausgeführt.
• Zur Kontrolle dienen die üblichen Befehle
– bjobs zeigt alle aktiven Jobs an
– bpeek zeigt die Ausgabe
– bkill beendet Jobs
• Nach Beendigung des Jobs wird die Ausgabe per Mail verschickt
oder in einer Datei abgelegt.
• Ergebnisse, auch von längeren Skripten, stehen erst am Ende zur
Verfügung.

27. Aufgetretene Probleme
• Überlastung des NFS bei vielen parallelen Jobs
– Nutzung des lokalen Speichers auf den Knoten
– Sequentielles Zurückkopieren der Ergebnisse?
• Löschen der Daten bei Abbruch
– Abbruch beendet Skript, daher separates Post-Execution-Skript
– Daten auf Knoten werden gelöscht
• Angehaltene und neu gestartete Jobs
– Jobs niedriger Priorität können angehalten und auf anderem Knoten neu gestartet werden
– Neues temporäres Mapset bei Neustart
• Flutung des User-Mailaccounts durch „Erfolgsmeldungen“
– Job-Abschlußmeldungen können alternativ in Textdateien geschrieben werden

28. Praxisbeispiele:
Tsunami-Produkte
• Kartierung und Analyse der Wellenausbreitungen
– TRIDEC-Projekt:
• Daten-Qualitätssicherung
• Öffentlichkeitsarbeit im TRIDEC Projekt
– GFZ Support der EXPO 2012 in Korea
– Präsentationen im GeoLab (LangeNacht 2012)

29. Praxis: Tsunamiatlas
• Kartierung von Tsunami Simulationen für das östliche Mittelmeer
– Ausgangsbasis: 391 Tsunamisimulationen
– Aufgabe: Zwei unterschiedliche thematische Karten (Isochronen, Max.
Wellenhöhen) pro Simulation

30. Praxis: Visualisierung Tohoku-Tsunami
• Testlauf am 13.April 2012:
– Ableitung 751 thematischer Karten aus Tsunamisimulationen
– Ausführung als parallele Jobs
– Minimale Job-Dauer: 250 Sekunden, Maximale Dauer: 280 Sekunden
• Der Cluster benötigte 68 Minuten um die 751 Jobs parallel zu
bearbeiten
• Anwendung:
– Diskussionsbasis / QC
– Globusanimationen

31. Praxisbeispiel Visualisierung Tohoku-Tsunami
• Abschätzung serielle Bearbeitung auf gleicher Hardware:
– 751 Jobs a 250 Sekunden
– = 187750 Sekunden
– = ca. 3219 Minuten
– = ca. 52 Stunden 9 Minuten
Serielle Berechnung versagt als Basis für iterative
Erstellungsprozesse und QC-Defintion !

32. Fazit
GRASS GIS auf dem High Performance Cluster:
• … bietet den Cluster-Benutzern ein neues Werkzeug im GIS-
Bereich
• … bietet der Geoinformatik/GIS-Community eine neue mächtige
Arbeitsumgebung jenseits der Limitierungen von Desktop-
Maschinen
• … wird als Zusammenarbeit von Rechenzentrum und CeGIT als
„Software as a Service“ bereitgestellt
Alle GFZ-Mitarbeiter sind eingeladen, dieses Service-Angebot
zu nutzen.

33. Ausblick
• Weitere interne Tests mit sehr großen Datenmengen
• In Erprobung: GRASS 7 (wxGUI, temporale Geodaten)
• Externe Nutzungsmöglichkeit ohne Clusteraccount
• Anpassung an Nutzerbedürfnisse
– Einbindung von GRASS Add-on Modulen
– Zusätzliche Geodaten-Formate
– Zusätzliche Datenbanken
– Verbesserung der Bedienbarkeit
– Wir freuen uns auf Feedback!
• Training:
– Summer School ?
– Winter School parallel zum GIS DAY 2012 ?

34. Dank
Die Arbeiten am GFZ basieren auf Vorarbeiten in der GRASS
GIS Developer Community durch
Markus Neteler und Luca Delucchi
von der Fondazione Edmund Mach - Research and Innovation
Centre).

35. Danke für die Aufmerksamkeit !
Fragen ?