C3Grid-INAD: towards an INfrastructure for general Access to climate Data. D4.1.2 A: User-Defined Workflows

Transkript

1 C3Grid-INAD: towards an INfrastructure for general Access to climate Data D4.1.2 A: User-Defined Workflows Autors: Markus Kemmerling, Benny Bräuer, Ulrike Golas, Thomas Schartner, Jens Wahnes Editor: Markus Kemmerling Partner(s): AWI, DKRZ, FUB, RRZK, TUDo, ZIB Lead Partner: TU Dortmund Workpackage: AP4.1.2: user-generated workflows Deliverable: D4.1.2 Version Identifier: 1.0 Date: 28. September 2012 Document Classification: Public

2

3 Project: C3-INAD: Towards an INfrastructure for general Access to climate Data Gefördert vom BMBF, Förderkennzeichen: 01LG1004A-I Laufzeit: Oktober 2010 September 2013 Abstract In C3Grid gibt es eine Menge von vordefinierten Workflows (auch als Standardworkflows bezeichnet), aus denen der Nutzer auswählen kann. Sie können vom Nutzer konfiguriert werden und decken einen Großteil der täglichen Arbeit eines Klimaforschers ab. Erfahrene Nutzer wünschen sich darüber hinaus die Möglichkeit (Workflow-)Module zu einem User-Defined Workflow zu kombinieren. So können bequem Statistiken über die Ergebnisse von mehreren Analysen gebildet werden (wie es z. B. im Multi-Modell Multi-Ensemble Workflow gemacht wird). Ein weiterer, wichtiger Anwendungsfall ist die Verkettung von Aufrufen der Climate Data Operators (CDO). Dieses Dokument behandelt die User-Defined Workflows und gibt einen Überblick über die technische Umsetzung, den Stand der Arbeiten und die weitere Zeitplanung. Änderungen Version Date Name Brief summary M. Kemmerling Strukturvorschlag, Skizze Informationsbeschaffung Portal M. Kemmerling Skizze Zusammenstellung und Verarbeitung M. Kemmerling Zeitplan und Aufgabenbeschreibung J. Wahnes Beitraege aus Koeln zu Modulen und BDII T. Schartner Beitrag der FUB zum Stand der Arbeiten und MMME B. Bräuer Dateninformationssystem, Metabeschreibung, Portal und Anbindung an SVN/VolD M. Kemmerling Kleinere Korrekturen, Stand WSL und WSS, BDII Template-VM U. Golas Korrekturen, Stand DMS, VolD J. Wahnes Tippfehlerkorrektur, Erweiterung des Modulabschnitts B. Bräuer Stand der Arbeiten: Workflowmetabeschreibung und SVN M. Kemmerling Abstract, Aktualisierung Informationsgewinnung im Portal J. Wahnes Korrektur diverser Rechtschreibfehler M. Kemmerling Deckblatt B. Bräuer Tippfehler korrigiert M. Kemmerling

4 Inhaltsverzeichnis 1 Überblick Informationsbeschaffung und Präsentation im Portal Zusammenstellung und Verarbeitung eines Workflows Beispiel: Multi-Modell Multi-Ensemble Stand der Arbeiten Portal SVN Metabeschreibung von Modulen/Workflows Dateninformationssystem/OAI WSL WSS DMS VolD/ADiS BDII Module Multi-Modell Multi-Ensemble Zeitplan SVN Struktur definieren Feedback + Verfeinerung Struktur umsetzten Workflow Meta Language (WML) Sprache evaluieren Besprechung Entwicklung 1. Version Review Verfeinerung Portal WSS/DIS anbinden Workflows integrieren WF-Metabschreibungen erstellen Maskengenerator entwicklen SVN anbinden VolD anbinden BDII anbinden Interface für User-Defined Workflows

5 3.4 BDII BDII/VolD im WSS anbinden Toplevel-BDII installieren Sitelevel-BDII installieren VCPs (GT5, BDII) aufsetzen Treffen CP-Modell CP-Modell verfeinern Schedulinglogik und BDII-Anbindung im WSS anpassen Konfiguration Sitelevel-BDII anpassen Meilensteine C3neu Middleware (ohne Portal) Testversion C3neu

6 1 Überblick User-Defined Workflows sind eine sehr komplexe Aufgabe. Zur Realisierung wurden drei Teilaufgaben identifiziert: Zuerst müssen im Portal alle Informationen über die im C3Grid verfügbaren Module und Daten gesammelt und dem Nutzer präsentiert werden. Dann muss dem Nutzer die Möglichkeit gegeben werden, sich aus den präsentierten Bausteinen einen Workflow zusammenzustellen und zu konfigurieren. Zum Schluss muss dieser User-Defined Workflow im Grid ausgeführt werden. Die erste Teilaufgabe wird in Abschnitt 1.1 betrachtet. Abschnitt 1.2 geht auf die zweite Teilaufgabe, die Zusammenstellung und die Abarbeitung des Workflows ein. 1.1 Informationsbeschaffung und Präsentation im Portal Damit ein Nutzer sich einen Workflow aus Bausteinen zusammenstellen kann, müssen ihm zuerst die zur Verfügung stehenden Module und Datensätze angezeigt werden. Welche Module und Datensätze existieren, welche Datensätze mit welchen Modulen verarbeitet werden können und mit welchen Modulen die Ausgaben anderer Module weiterverarbeitet werden können, wird nicht im Portal direkt gespeichert. Stattdessen sammelt das Portal diese Informationen, wertet sie aus und präsentiert sie dem Nutzer. Die Darstellung der Module im Portal erfolgt aufgrund der in den Metabeschreibungen enthaltenen Informationen. Dieser Schritt wird in Abbildung 1.1 visualisiert. Die von verschiedenen Instituten angebotenen Daten werden über das OAI Protocol for Metadata Harvesting (OAI-PMH) in einem Dateninformationssystem (DIS) publiziert. Die im C3Grid verfügbaren Module liegen im SVN in einer bestimmten Ordnerstruktur zusammen mit ihren Metabeschreibungen. Die Metabeschreibung zu einem Workflow beinhaltet Informationen über verarbeitbare Daten, auswählbare Parameter und Konfigurationsmöglichkeiten. Die im gesamten System verfügbaren Module werden von den Compute Providern (CPs) im Berkeley Database Information Index (BDII) publiziert. Um dem Nutzer die Auswahlmöglichkeit zu bieten, wo Daten aus der Earth System Grid Federation (ESGF) 1 gestaged werden oder wohin die Ergebnisse des Workflows exportiert/publiziert werden können, muss das Portal die verfügbaren Sites kennen. Diese Informationen werden über den Volatile Directory Service (VolD) 2 publiziert. Die über VolD publizierten Daten können mit dem Advanced Discovery Service (ADiS) 3, einen speziell für C3Grid entwickelten Clienten, abgefragt werden. In Gelb hinterlegt ist in den Abbildungen 1.1 und 1.2 dargestellt, welche Institution bzw. welche Entwicklergruppe für die Entwicklung und Umsetzung verantwortlich ist

7 Enwicklung: AWI DKRZ TuDo ZIB Metabeschreibung Erstellung: WF Entwickler SVN Umsetzung: WF Entwickler getmoduleversion Realisierung: AWI List all Modules DataSets Portal getinfosaboutmodules List all Modules VolD List all DataSets Enwicklung: ZIB Implementierung: AWI OAI Abbildung 1.1: Informationsgewinnung und Darstellung durch das Portal. 7

8 1.2 Zusammenstellung und Verarbeitung eines Workflows Die zentrale Komponenten zur Realisierung der User-Defined Workflows ist das Portal. Über ein flexibles Interface werden dem Nutzer nicht nur die verfügbaren Module und Daten präsentiert, sondern ihm auch die Möglichkeit gegeben, die Module zu kombinieren und zu einem Workflow zusammenzustellen. Dieser Schritt und die anschließende Abarbeitung des Workflows im Grid wird in Abbildung 1.2 visualisiert. Damit der Workflow verarbeitet werden kann, muss er in der Workflow Specification Language (WSL) beschrieben werden. Das Portal generiert die Workflowbeschreibung basierend auf Beschreibungstemplates der Module und sendet sie an den Workflow Scheduling Service (WSS). Für die Arbeit des WSS ist die konkrete Instanz des Workflows irrelevant. Der WSS kann beliebige Workflows abarbeiten. Datenbezogene Aufgaben wie das Extrahieren von Daten aus Datenbanken und das transferieren von Daten zwischen Gridsites werden vom Datenmanagement System (DMS) ausgeführt. Zum Auffinden verschiedener DMS-Installationen z. B. zum Stagen von ESGF- Daten oder zum veröffentlichen von Ergebnissen bezieht der WSS Informationen aus VolD. Rechenaufgaben werden vom WSS bei CPs als GRAM-Jobs eingereicht. Dazu muss die GRAM-Schnittstelle angepasst werden, um Module zuerst zu laden und dann auszuführen. Ein Modul wird durch sogenannten Module-Files definiert. Diese müssen bei den CPs installiert werden. Damit der WSS weiß, bei welchen CPs eine Rechenaufgabe, welche Teil eines Moduls ist, ausgeführt werden kann, müssen die CPs die installierten Module publizieren. Dazu wird nicht VolD, sondern der im Grid-Umfeld weit verbreitete BDII verwendet. BDII ist in mehreren Ebenen aufgebaut. Die Informationen über eine Gridsite werden in einem Sitelevel-BDII publiziert. Die Sitelevel-BDIIs werden von einem Toplevel-BDII abgefragt, welcher alle Informationen des Grids beinhaltet. Der WSS holt die Informationen über die CPs aus dem Toplevel-BDII. 1.3 Beispiel: Multi-Modell Multi-Ensemble Ein User-Defined Workflow soll dem Benutzer ermöglichen einzelne Bausteine zu einem Workflow zu verbinden und zu konfigurieren. Eine einfache Möglichkeit dieses im C3Grid durchzuführen kann mit den Climate Data Operators (CDO) und einer Skriptsprache (z. B. Python) umgesetzt werden. Die CDOs haben den Vorteil, dass Optionen und Operatoren fast beliebig aneinander gehängt werden können. Das Programm ist quelloffen und somit auf fast jeder Plattform lauffähig und der Benutzer benötigt keine weiteren Programmierkenntnisse in höheren Programmiersprachen (z. B. Fortran). Der Multi-Model-Multi-Ensemble-Workflow (MMME) ist ein Prototyp für die Umsetzung eines User-Defined Workflows. Im MMME werden Python und CDO-Befehle/ Aufrufe so verschachtelt bzw. nacheinander aufgerufen, dass am Ende das gewünschte Produkt, ein gewichtetes Resultat einzelner Modelle bzw. Ensembles, entsteht. Es wird wie bei User-Defined Workflows lediglich ein Skript mit CDO-Befehlen ausgeführt. Durch dieses Verfahren kann der MMME flexibel auf die Anforderungen der Benutzer 8

9 Enwicklung: AWI flexibles Interface Realisierung: AWI GUI nutzen & Workflows zusammenstellen Portal generiere WSL WSL Definition: TuDo VolD DMS Enwicklung: TuDo extrahiere & transferiere Daten WSS arbeite WF ab hole Infos über CPs für WSS ein generischer Workflow Installation Toplevel: TuDo BDII Installation Sitelevel: RRZK Enwicklung: ZIB Datentransfers lade Modul & führe Gram Job aus publizieren Verfeinerung Modellierung: RRZK TuDo Realisierung: RRZK CP ModuleFiles geschrieben & installieren Erstellung: WF Entwickler RRZK Abbildung 1.2: Erstellung eines Workflows durch den Nutzer und Ausführung des Workflows im Grid 9

10 angepasst werden. Skizzieren lässt sich der MMME wie folgt: 1. bei jedem Modell wird mit cdo griddes die Gitterinformation ausgelesen 2. alle Modelle werden mit cdo remapcon auf ein einheitliches Gitter gebracht 3. mit cdo timavg wird das Zeitmittel einer jeden Datei gebildet 4. die Statististik (z. B. RMSE) wird mit cdo -sqrt -fldmean -sqr -sub gebildet 5. die Punkte 2 bis 4 lassen sich elegant zusammenfassen, um Speicherplatz auf dem Workspace zu sparen: cdo -sqrt -fldmean -sqr -sub -timavg -remapcon 6. das Resultat aus Punkt 5 wird verwendet um die Wichtungsfaktoren zu bestimmen 7. mit cdo -mulc, -timavg -remapcon werden die einzelnen Modellläufe mit den jeweiligen Wichtungsfaktoren gewichtet 8. cdo enssum fasst die Modellläufe zu einem gewichteten Mittel zusammen 9. die Punkte 7 und 8 lassen sich wieder zusammenfassen: cdo enssum -mulc, -timavg -remapcon Die Abbildung 1.3 veranschaulicht noch einmal das Verfahren: Dieses Verfahren zeigt beispielhaft, wie man mit den CDOs und einer Skriptsprache User-Defined Workflows definieren und umsetzen kann. 10

11 Abbildung 1.3: MMME Skizze für den Aufruf von cdo 11

12 2 Stand der Arbeiten In diesem Abschnitt werden der Stand der Arbeiten und die dabei gesammelten Erfahrungen diskutiert. 2.1 Portal Das Portal (Version C3-interim ) befindet sich derzeit in einem Zustand, in dem noch keine Workflows enthalten sind. Diese werden erst nach der Verbindung zum Scheduling- System in der nächsten Version ergänzt, je nach Fortschritt bei der Umsetzung der Metabeschreibungsentwicklung. Danach erfolgen auch die Anbindung an das SVN-Repository und an das Dateninformationssystem. 2.2 SVN Im SVN-Repository sind die verschiedenen Versionen der Workflows abgelegt. Diese werden künftig auch die jeweils aktuelle Metabeschreibung enthalten, welche zur weiteren Verarbeitung bei Auswahl des entsprechenden Workflows bzw. Moduls vom Portal angefordert werden wird. 2.3 Metabeschreibung von Modulen/Workflows Die Metabeschreibung für die einzelnen Workflows befindet sich aktuell in der Konzeptionsphase. Diese Beschreibung dient dem Entwickler, seinen Workflow auf eine standardisierte Weise zu definieren. Dabei werden kompatible Daten, Abhängigkeiten von Parametern u. ä. mit berücksichtigt soweit möglich. Diese Beschreibungen sollen automatisiert verarbeiten werden; am Ende dieses Prozesses werden im Portal Masken generiert. Dadurch soll sich eine große Zahl Workflows implementieren lassen, ohne dass eine indidividuelle Behandlung notwendig (bzw. auf wenige Ausnahmen reduziert) wird. Zur Zeit existieren Beispiele für die bestehenden Workflows, die mit dieser Metabeschreibung umgesetzt wurden, um darauf aufbauend weitere Arbeiten durchzuführen. 2.4 Dateninformationssystem/OAI Im Dateninformationssystem (basierend auf panfmp 1 ) werden alle im Grid verfügbaren Metadatensätze abgelegt. Diese gelangen via OAI-PMH von den Datenprovidern in das System und werden indiziert, so dass sie dem Portal zur Volltextsuche zur Verfügung stehen. Dieses System besteht schon seit der ersten Projektphase von C3Grid und wird auch für die User-Defined Workflows ohne Änderung weiterverwendet

13 2.5 WSL Für die Beschreibung eines Tasks wurde das Application-Tag in die WSL aufgenommen. Über dieses Tag kann das Workflowmodul und die Modulversion, zu dem der Task gehört, angegeben werden. Eine genaue Definition ist in der WSL Spezifikation [2] enthalten. Eine ausführliche Erklärung zur Verwendung und Beispiele befinden sich in den Best Practices in Packaging and Releasing C3Grid Software Modules [3]. Das Application-Tag ist Teil der Job Submission Description Language [4] des Open Grid Forums 2. Somit bleibt die Beschreibung von Rechenaufgaben in der WSL standardkonform. 2.6 WSS Für den WSS wurde eine übersichtliche und intuitive Schnittstelle entwickelt. Zur komfortablen Kommunikation mit dem WSS, z. B. vom Portal, wurde ein Java-Clientbibliothek implementiert. Der WSS wurde so konzipiert, dass er generische Workflows verarbeiten kann. Die Anzahl der beinhaltenden Tasks und ihre Abhängigkeiten untereinander unterliegen nur der Beschränkung, dass die Abhängigkeiten nichtzyklisch seien müssen. Um datenbezogenen Aufgaben durch das DMS ausführen zu lassen wurde die DMS- Clientbibiliothek an den WSS angebunden. Die Anbindung von VolD/ADiS und BDII, um mehr Informationen zu erhalten und die Schedulingentscheidungen weiter zu verbessern, wird z. Zt. noch implementiert und im September fertiggestellt. Die aktuelle Version der WSL, welche die Definition von Workflowmodulen umfasst, wird vom WSS unterstützt. Bei der Implementierung wurde auf die Abwärtskompatibilität geachtet um weiterhin Workflowbeschreibungen, in denen das Modul-Konzept nicht angewendet wird, zu verarbeiten. Um Rechenaufgaben bei Compute-Providern einzureichen wird die GRAM-Schnittstelle des aktuellen Globus Toolkit 5.2 verwendet. Bei der Generierung der Jobbeschreibungen für GRAM werden die Erweiterungen an der GRAM-Schnittstelle, um das Laden von Workflow-Umgebungen zu realisieren, vollständig unterstützt. Der GRAM-Dienst überprüft die Existenz eines Programms bevor es den Aufruf an das lokale Batchsystem weiterleitet. Da die Module i. d. R. nicht auf dem Grid-Frontend eines Compute-Provider sondern ausschließlich auf den Clusterknoten installiert, findet der GRAM-Dienst die Programme nicht. Zudem wird durch das Modul-Konzept der vollständige Pfad zum Programm nicht mehr bei der Ausführung angegeben. Das Laden der Workflow-Umgebungen macht die Angabe überflüssig. Der GRAM-Dienst überprüft allerdings schon vorher, ob das Programm existiert. Weil die Workflow-Umgebungen zu diesem Zeitpunkt noch nicht geladen ist, kann der GRAM-Dienst das Programm nicht finden. Dieses Problem wird im WSS umgangen, indem ein Programm nicht direkt ausgeführt wird. Es wird die BASH gestartet und der Programmaufruf mit dem Parameter

14 -c übergeben: /bin/bash -c Befehl. 2.7 DMS Das DMS muss für die Abarbeitung von User-Defined Workflows keine zusätzliche Funktionalität beinhalten. Die Workflows werden vom WSS als entsprechende Order beim DMS eingereicht und abgearbeitet, um die angeforderten Daten bereit zu stellen. Dabei kommen, abhängig von der konkreten Anforderung, die bereits für die Standard- Workflows implementierten Taskflows zu Ausführung. 2.8 VolD/ADiS Die Implementierung des VolD ist abgeschlossen. Abhängig von den konkreten Informationen, die bei VolD registriert werden sollen, müssen in ADiS noch entsprechende Methoden zum Registrieren und Abrufen dieser Informationen implementiert werden. 2.9 BDII Bei den Compute-Resource-Providern wird ein Site-Level-BDII-Server benötigt, der Auskunft über die zur Verfügung stehenden Hardware-Resourcen, das verwendete Batchsystem, dessen Auslastung sowie die im C3Grid vor Ort zur Verfügung stehenden Workflow- Komponenten gibt. Diese Informationen werden periodisch ermittelt und publiziert. Als Vorlage für die Installation und Konfiguration eines Site-Level-BDII-Server wurde an der TU Dortmund eine Virtuelle Maschine aufgesetzt, die bezüglich BDII eine vollständige Compute-Resource darstellt. Sie beinhaltet das Batchsystem PBS (die VM fungiert sowohl als PBS-Server wie auch als Workernode) und einen vollständig installierten und für die Verwendung in C3Grid konfiguerten Site-Level-BDII-Server. Die bei der Installation und Konfiguration gewonnenen Erfahrungen wurden in einer Installationsanleitung zusammengefasst und veröffentlicht. Diese umfasst insbesondere Anweisungen (großteils Skripte als Kopiervorlage), welche Konfigurationen vorgenommen und welche Skripte angepasst werden müssen, um den Site-Level-BDII-Server in C3Grid zusammen mit Globus zu betreiben. Beim Compute-Resource-Provider RRZK wurde ein solcher Site-Level-BDII-Server auf dem Grid-Frontend installiert und wird bis Ende September an die lokalen Gegebenheiten angepasst werden. Für den Prototyp des virtuellen Compute-Resource-Providers wird ebenfalls ein Site-Level-BDII-Server bis Ende November bereitgestellt werden, wobei die Erfahrungen des RRZK beim Aufsetzen eines Site-Level-BDII-Servers einfließen werden Module Um den Start von Workflows im C3Grid möglichst unabhängig von Compute-Resource- Providern zu gestalten und zusätzlich eine Versionierung der Workflows zu erlauben, soll die Bereitstellung der notwendigen Software-Komponenten über die sogenannten 14

15 Environment Modules erfolgen. Daher wurden für alle Workflows entsprechende Module- Files geschrieben. Wie die Module-Files aufgebaut sind und was beim Erstellen der Dateien zu beachten ist, wird im Deliverable D [3] genauer beschrieben. Zuvor war das Konzept der Module-Files bereits anhand einiger Muster-Workflows erprobt worden. Die Arbeiten an der Modularisierung der Workflows erlauben nun auch einen fließenden Übergang von C3-Alt auf C3-Neu, da die auf dem Module-Konzept aufbauenden Workflows ohne Änderungen direkt übernommen werden können, d. h. diese laufen sowohl im alten als auch im neuen System. Da die in C3-Neu betroffene Grid-Schnittstelle aus Globus 5, hier die GRAM-Schnittstelle, ein Pre-Load von Workflow-Umgebungen über die Environment Modules nicht automatisch unterstützt, wurde beim Compute-Resource-Provider RRZK eine Erweiterung der GRAM-Schnittstelle um die benötigte Funktionalität vorgenommen, so dass WSLseitig keinerlei Information mehr über die lokalen Gegebenheiten bei einem Compute- Resource-Provider notwendig sind. Einzig der global gültige Name des Workflows (genauer: der Name des Workflow-Moduls) im C3Grid und die Namen seiner Tasks müssen bekannt sein. Nach Inbetriebnahme des Site-Level-BDII-Servers werden bis Mitte Oktober beim Compute-Resource-Provider RRZK die notwendigen Skripte zur Ermittlung der angebotenen Workflow-Komponenten bereitgestellt. Die obige Anpassung der GRAM-Schnittstelle wird ebenfalls bis Ende November in den Prototyp des virtuellen Compute-Resource-Providers übernommen und der Site- Level-BDII-Server um die Bereitstellung der Workflow-Informationen erweitert werden Multi-Modell Multi-Ensemble Die Idee des Multi-Model-Multi-Ensemble-Workflows (MMME) ist es, Modelle oder Ensembles von Modellen nach bestimmten statistischen Kriterien zu bewerten und zusammenzufassen. Die Annahme dabei ist, dass ein Modell oder ein Ensemble von Modellen, welches die Gegenwart am besten simuliert, auch das zukünftige Klima am besten projizieren kann. Um Bandbreiten des zukünftigen Klimas zu erfassen, werden Modellsimulationen, die in der Gegenwart größere Abweichungen zeigen, nicht einfach verworfen, sondern gehen mit einer niedrigeren Gewichtung in das Multi-Model Multi-Ensemble mit ein. Der MMME wurde mit Hilfe der Climate Data Operators (CDO) und Python umgesetzt. Im Gegensatz zu höheren Programmiersprachen (z. B. Fortran), hat das den Vorteil, dass der Workflow skriptfähig ist, das heißt nicht kompiliert werden muss (plattformunhabhängig) und weniger Programmieraufwand benötigt wird. Aufgrund der Skriptfähigkeit lässt sich der MMME sehr leicht an die Bedürfnisse der wissenschaftlichen Community (z. B. MiKlip) anpassen. So lassen sich z. B. andere statistische Maßzahlen oder andere Wichtungsfaktoren verwenden. Mit dem MMME entstand ein Prototyp für die User-Defined Workflows (siehe Abschnitt 1.3). Der MMME benötigt als Eingabe einen Referenzdatensatz (z. B. eine Reanalyse), mindestens eine Kontrollsimulation (z. B. 20C Lauf eines Modells) und für die Ausgabe mindestens eine Klimasimulation (z. B. A1B Lauf eines Modells). Alle Datensätze müssen 15

16 die gleiche Variable besitzen und die Kontrollsimulation muss den gleichen Zeitraum wie der Referenzdatensatz überdecken. Aufgrund der Einschränkung im alten C3Grid, dass man nur einen Datensatz für einen Workflow verwenden kann, sind im alten C3Grid die Datensätze für den MMME fest vorgegeben. Diese Einschränkung fällt im neuen C3Grid weg. Im alten C3Grid wurde der NCEP/NCAR-Reanalyse-Datensatz und die Twentieth-Century-Läufe mit den Ensemblemembern 1 5 und der air pressure at sea level als Variable ausgewählt. Alle Datensätze werden mit einem konservativen Remapping (cdo remapcon) auf ein einheitliches Gitter gebracht. Prinzipiell werden alle Remapping- Arten der CDOs unterstützt. Für die statistische Bewertung im alten C3Grid wurde der RMSE genommen. Andere Bewertungen sind möglich, z. B. der Anomalie-Korrelationskoeffizient (ACC), aber noch nicht implementiert. Als Ergebnis erhält der Benutzer eine Textdatei mit Faktoren, RMSE, Ein- und Ausgabe, eine Ausgabedatei, die visualisiert werden kann und eine Metadatenbeschreibung in Form einer XML-Datei. Der MMME wird ständig weiterentwickelt und in Absprache mit dem MiKlip-Projekt Modul E - Validierung an die Bedürfnisse der Benutzer angepasst. 16

17 3 Zeitplan In diesem Abschnitt werden die noch nicht abgeschlossenen Arbeiten zur Realisierung der User-Defined Workflows aufgeführt und ein Zeitplan präsentiert. Abbildung 3.1 zeigt einen Gantt-Chart mit allen noch offenen Aufgaben, den Abhängigkeiten zwischen den Aufgaben und den Zeiträumen, in denen die Bearbeitung der Aufgaben geplant ist. Voraussichtlich werden alle Arbeiten zur Realisierung der User-Defined Workflows bis Februar 2013 abgeschlossen sein. Der Gantt-Chart stellt nur die Arbeiten zu den User- Defined Workflows ab September 2012 dar und berücksichtigt nicht die Arbeiten zu anderen Projektzielen des C3Grid-INAD Projekts oder die Arbeiten vor September. Auch wenn Aufgaben schon vor September bearbeitet wurden, werden sie mit Anfangsdatum (erster Arbeitstag im September) gelistet. 3.1 SVN Struktur definieren Im Rahmen der Versionierung von Workflows und Workflowmodulen wird die Versionsverwaltung Subversion (SVN) eingesetzt. Um stabile Versionen von Workflows (bzw. Workflowmodulen) über SVN festzulegen und zu organisieren wird in Deliverable D [3] eine Verzeichnisstruktur definiert Feedback + Verfeinerung Begutachtung der definierten Verzeichnisstruktur durch die Workflowentwickler. Basierend auf dem Feedback wird die Verzeichnisstruktur überarbeitet und verfeinert Struktur umsetzten Verantwortung: Workflowentwickler Alle Workflowentwickler müssen ihre Workflows gemäß der definierten Verzeichnisstruktur im SVN-Repository des AWI 1 ablegen. 3.2 Workflow Meta Language (WML) Sprache evaluieren

18 Abbildung 3.1: Zeitliche Planung der weiteren Arbeiten zur Realisierung von User- Defined Workflows (Gantt-Chart erstellt mit GanttProject [1]). 18

19 Unterstützung: DKRZ, TUDo, ZIB Die zu entwickelnde Metabeschreibungssprache kann auf verschiedenen Auszeichnungssprachen basieren. Zu den gängigen zählen z. B. XML, YAML und JSON. Es muss überprüft werden, welche Beschreibungssprache hinsichtlich Syntax, Komplexität und Werkzeugunterstützung für C3Grid geeignet ist. Auch muss überprüft werden, ob es existierende Standardsprachen in der Klima- und Geo-Community gibt, mit denen Softwarewerkzeuge beschrieben werden Besprechung Unterstützung: DKRZ, TUDo, ZIB Arbeitsstreffen zur Entwicklung einer Metabeschreibungssprache für Workflows. Die bisherigen Arbeiten im Portal (Filterrergeln für Daten, Maskenerstellung), zur WSL und die Evaluation von Beschreiungssprachen dienen als Grundlage für dieses Treffen Entwicklung 1. Version Unterstützung: DKRZ, TUDo, ZIB Es sollen ggf. mehrere Prototypen für eine Metabeschreibungssprache entwickelt werde Review Verantwortung: Workflowentwickler Die Prototypen für eine Metabeschreibungssprache werden von den Workflowentwicklern, die später die Metabeschreibungen zu ihren Workflows erstellen werden, begutachtet Verfeinerung Unterstützung: DKRZ, TUDo, ZIB, Workflowentwickler Basierenden auf dem Feedback der Workflowentwickler wird ein Prototyp ausgewählt und weiterentwickelt. 3.3 Portal WSS/DIS anbinden Unterstützung: TUDo Das neue Portal muss an den neuen WSS (Version 3.x - OSGI basiert) und das Dateninformationssystem (DIS) angebunden werden. 19

20 3.3.2 Workflows integrieren Die Workflows aus dem alten Portal müssen in das neue Portal übernommen werden. Teilweise werden die Masken für die Workflows wie im alten Portal manuell erzeugt. Für andere Workflows werden die Masken basierend auf der zu entwickelten Metabschreibungssprache und den zu erstellenden Metabschreibungen dynamisch erstellt WF-Metabschreibungen erstellen Für alle existierenden Workflows muss eine Metabeschreibung in WML erstellt werden. Für neue Workflows wird das Schreiben einer Metabschreibung Teil des Entwicklungsprozess sein (siehe Best Practices in Packaging and Releasing C3Grid Software Modules [3]) Maskengenerator entwicklen Basierend auf den Metadaten eines Workflows sollen die Eingabemasken im Portal automatisch erzeugt werden. Dafür ist ein Maskengenerator zu entwicklen SVN anbinden Alle Informationen zu einem Workflow sind im SVN-Repository des AWI abgelegt. Dazu gehören die verfügbaren Versionen, die Defaultversion, die Metadaten und evtl. ein WSLtemplate. Diese Informationen müssen vom Portal aus der Verzeichnisstruktur des SVN- Repository und den dort abgelegten Dateien ausgelesen werden VolD anbinden Unterstützung: ZIB Alle in C3Grid existierenden StagingSites für ESGF-Daten, Export- und PublishingSites registrieren sich in VolD. Das Portal muss mit dem Clienten ADiS den VolD abfragen und sich alle Sites geben lassen BDII anbinden Unterstützung: TUDo Alle in C3Grid verfügbaren Workflows/Module sollen über BDII publiziert werden. Das Portal muss den BDII abfragen und sich alle verfügbaren Workflows/Module inkl. Versionen geben lassen. 20

21 3.3.8 Interface für User-Defined Workflows Unterstützung: Workflowentwickler Es muss ein flexibles Interface entwickelt werden, mit dem ein Nutzer in der Lage ist einen Workflow aus verfügbaren Modulen zusammenzubauen. 3.4 BDII BDII/VolD im WSS anbinden Verantwortung: TUDo Unterstützung: ZIB (bezüglich DMS/VolD) Für Schedulingentscheidungen benötigt der WSS Informationen über Ausführungsumgebung bei CPs Auslastung der CPs Verfügbare DMS-Instanzen (z. B. ESGF-Staging Sites, Publishing Sites) Speicherkapazität und -auslastung bei CPs, Publishing Sites etc. Diese Informationen können teilweise direkt bei der DMS-Instanz abgefragt werden, teilweise werden sie mit VolD und teils mit BDII publiziert. Der WSS muss alle Informationen abfragen können und daher an alle Systeme angebunden werden Toplevel-BDII installieren Verantwortung: TUDo Der Toplevel-BDII sammelt alle Informationen der Sitelevel-BDIIs und wird vom WSS abgefragt. Er wird in Dortmund installiert wo auch der WSS betrieben wird Sitelevel-BDII installieren Verantwortung: RRZK Unterstützung: TUDo Die Sitelevel-BDII beinhalten alle Informationen über eine Site (z. B. ein Compute Provider). Die Sitelevel-BDIIs müssen bei den ComputeProvidern installiert werden VCPs (GT5, BDII) aufsetzen Verantwortung: RRZK In C3neu wird Globus GT5 eingesetzt. Daher müssen die VCPs mit GT5 ausgestattet werden. Damit der WSS Jobs zu ihnen submittieren kann, müssen sie ausßerdem über einen Sitelevel-BDII verfügen um Informationen zu publizieren. 21

22 3.4.5 Treffen CP-Modell Verantwortung: TUDo, RRZK Das bisher erarbeitete Informationsmodell eines Compute Provider, in welcher Form Informationen über einen Compute Provider in C3Grid mit BDII publiziert werden, basiert auf den Erfahrungen in C3alt. Die Arbeiten an der High-End-Visualisierung und deren Anforderungen an das Grid machen eine Überarbeitung dieses Modells notwendig. Dieses Treffen dient als Grund zur Verfeinerung des Modells um die aktuellen und zukünftigen Gegebenheiten bei den Compute Providern abzubilden CP-Modell verfeinern Verantwortung: TUDo, RRZK Basierend auf den Ergebnissen des Treffens zum CP-Modell muss das Modell überarbeitet werden Schedulinglogik und BDII-Anbindung im WSS anpassen Verantwortung: TUDo Wenn das Informationsmodell überarbeitet wurde, muss die BDII-Anbindung und die Schedulinglogik im WSS angepasst werden um die neue Modellstruktur und dort (neu) enthaltenen Informationen zu berücksichtigen Konfiguration Sitelevel-BDII anpassen Verantwortung: RRZK Die Konfiguration der Sitelevel-BDII-Installationen bei den Compute Providern muss derart angepasst werden, dass die neue Modellstruktur verwendet wird. 3.5 Meilensteine C3neu Middleware (ohne Portal) Testversion WSS, DMS, Datenanbieter und Compute Provider sind fertig implementiert und konfiguriert und können mit einander interagieren C3neu Das neue Portal wird an den WSS angebunden. Die gesamte Grid-Infrastruktur von C3neu ist implementiert und konfiguriert und die Komponenten können mit einander interagieren. 22

23 Literaturverzeichnis [1] Dmitry Barashev and Thomas Alexandre. Ganttproject Zugriff am 04. September [2] Christian Grimme, Alexander Papaspyrou, Tassilo Galonska, and Markus Kemmerling. Dokumentation der Workflow Specification language (WSL). Technical report, C3Grid-INAD, [3] Markus Kemmerling, Volker Winkelmann, Benny Bräuer, Jens Wahnes, and Tassilo Galonska. D best practices in packaging and releasing C3Grid software modules. Technical report, C3Grid-INAD, Deliverable D [4] Andreas Savva et al. Job submission description language (JSDL) specification, version 1.0. Technical report, Open Grid Forum,