Zur Erinnerung: Als Beispiel für meine Mini-Serie über Lehre dient eine Einsteigerkurs, der das Ziel hat WissenschaftlerInnen, die einen Hochleistungsrechner (auch Cluster) nutzen, die Grundlagen zum selbstständigem Arbeit mit dem Cluster zu vermitteln. Und im ersten Artikel dieser Serie habe ich angedeutet, dass Lehre für HPC-NutzerInnen mit Tücken behaftet ist …

Zuerst: Ein Rückblick

Ungefähr zeitgleich mit mir fing ein Kollege als Computational Scientist am Rechenzentrum in Mainz. Das liegt inzwischen etwa 5 Jahre zurück. Unsere Aufgaben sollten sein: Unterstützung der NutzerInnen unseres Clusters, Lehre und eigene Forschung in unseren jeweiligen Bereichen. Wie an deutschen Universitäten üblich waren wir zunächst in Projekte eingebunden. Besagter Einführungskurs damals wenige Stunden Umfang und wurde vom damaligen PostDoc der benachbarten Forschungsgruppe gegeben. Innerhalb der erste anderthalb Jahre fand dieser Kurs nur einmal statt.

Ideale Bedingungen also, das Rad neu zu erfinden (als die Zeit gekommen war) — und dazulernen: Denn die eigene Tätigkeit bei der Unterstützung von Nutzern hat dazu beigetragen deren Schwierigkeiten besser zu verstehen und auch einen Katalog dessen aufzustellen, was an wichtigen Inhalten vermittelt werden muss. Im Laufe der Zeit bin ich es, der hauptverantworlich für die Lehre unserer Gruppe ist. Und die Veranstaltung durfte wachsen: Inhaltlich und zeitlich. Denn wir haben ihren Wert erkannt.

Anforderung und Ziele

Das es sich um eine Einführungsveranstaltung handelt, die ich hier exemplarisch behandle, kann ich nicht genug betonen. Und dennoch ist der Einstieg in die Verwendung eines Clusters bereits mit dem Erlernen einiger neuer Konzepte verbunden. Um noch mal die wesentlichen Rahmenbedingungen zu benennen:

  • viele neue Konzepte (je nach Zählweise ca. ein halbes Dutzend)
  • zwei Tage Zeit — das ist sicher nicht repräsentativ, anderswo gibt es weniger; ggf. haben auch andere Kollegen mehr Zeit?
  • sehr heterogener fachlicher Hintergrund der TeilnehmerInnen
  • sehr unterschiedliches, meist geringes IT-Ausgangswissen (an vielen Standorten — und bei uns auch — ist es leider so, dass die Fachbereiche zwar Studiengänge anbieten, die wissenschaftliches Programmieren beinhalten; Studierende jedoch, die sich auf ihre jeweiligen Fächer konzentrieren haben geringe Chancen sich substantielle IT-Kenntnisse anzueignen).

Dem unterschiedlichen Ausgangswissen versuchen wir durch einen “Bash-Crash”-Vorbereitungskurs entgegenzuwirken (ebenfalls zwei Tage), denn der eigentliche Einführungskurs setzt auf Beispiele in Bash. Bash ist gewissermaßen der kleinste gemeinsame Nenner; natürliche könnte man andere “Skriptsprachen” verwenden, aber das Batchsystem setzt in seiner Dokumentation bereits auf die Shell bzw. Bash und alles Andere würde eine weitere Hürde zum Verstehen aufstellen. HPC-Systeme laufen nun einmal mit Linux bzw. unixoiden Systemen.

Zu den Zielen+ zählen — ich erwähnte es schon:

  • NutzerInnen über die Services unserer Gruppe aufzuklären.
  • (zukünftige) NutzerInnen des Cluster mit den notwendigen Fähigkeiten auszustatten dieses selbsttätig zu nutzen, dazu zählen:
    • Beherrschung des Batch-Systems mit der notwendigen Parameterisierung der sog. Jobs (z. B. Anforderung des notwendigen Speichers in einem heterogen ausgestattetem Cluster, Anforderung der notwendigen CPUs bzw. Kerne und Teilrechner (auch Knoten genannt), Anforderung eines ad-hoc Filesystems (z. B. eine ramdisk), etc. etc. etc.)
    • Kenntnis der parallelen Fileserver, ihrer Stärken und “Anfälligkeiten”
    • Zusammenstellung von Arbeitsflüssen bei mehrschrittigen Rechnungen (gemeint ist, dass verschiedene Analyse-Programme unterschiedliche Anforderungen an Ressourcen haben können und diese müssen dann in verschiedenen, voneinander abhängigen Jobs ausgeführt werden — dazu ein anderes Mal mehr). Hierzu bietet das Batch-System verschiedene Möglichkeiten.
  • nicht zuletzt ist ein Ziel auch die Zahl der Anfängerfragen zu verringern, so dass unsere Gruppe sich auf komplexere, zeitintensivere Fragestellungen konzentrieren kann.

Über Kenngrößen

Wie gut ist eine Schulung? Nun zunächst einmal kann man die Zufriedenheit der TeilnehmerInnen erfassen. Das machen wir und dabei schneiden wir nicht schlecht ab: So eine Veranstaltung hat unvermeidliche Längen und dennoch erhalten wir/ich regelmäßig gute Noten. Einzig auffallend ist, dass TeilnehmerInnen mit sehr geringem Vorwissen oft die Geschwindigkeit monieren und über mangelnde Beispiele klagen, obwohl wir davon nicht wenige in Form interaktiver Aufgaben anbieten. (N.B.: Unsere Befragungen sind anonym, dennoch kann man diese Rückschlüsse ziehen, da wir auch nach Programmierkenntnissen und anderen Dingen fragen.) Wir/Ich greife(n) diese Einwände auf, insbesondere versuche ich immer neue didaktische Kniffe, mehr Beispiele, Diagramme und hands-on Teile einzubauen — und das alles mit Blick auf die zur Verfügung stehende Zeit. Diese und weitere Verbesserungen werden stetig eingepflegt.

Mit derartigen Befragungen kann selbstverständlich nur die Wirkung bzw. das Empfinden der Teilnehmenden erfasst werden, nicht den Fähigkeitenzuwachs. Hierzu kann ich objektiv nur anmerken: Ja, das Ziel der extrem naiven Anfängerfragen auf ein erträgliches Maß zu senken ist erreicht! Das ist tatsächlich nicht gering zu schätzen. Diese Fragen gibt es immer noch — vornehmlich durch Leute, die (noch) keine unserer Einführungskurse besucht haben oder wenn TeilnehmerInnen unmittelbar nach dem Kurs das Cluster nicht nutzen und dann, Monate später, wieder ihr Wissen zusammen kramen.

Und darüber hinaus? Wir führen keine Tests, Klausuren oder dergleichen durch. Die Teilnahme ist schließlich freiwillig, wir können (und wollen) uns nicht in jedem Fachbereich in die Prüfungsordnung schreiben lassen. Außerdem: Kann man mit einem Testat nach einem zweitägigem Crash-Kurs etwas Anderes erfassen als Kurzzeitgedächtnis und die Fähigkeit sich auf Testate einzustellen? Schließlich können TeilnehmerInnen nicht vorher büffeln und üben.

Auch eine Erfassung der Codequalität der Jobscripte unserer Nutzer können wir nicht systematisch durchführen. Ich versuche mal ehrlich zu sein: Gerade in der Datenanalytik/Bioinformatik sehe ich den Einfluss der Kurse auf die selbst erarbeiteten Arbeitsflüsse als sehr gering an. Das ist erkennbar an der Art der Fragen, der Art der Skripte (immer eines pro Arbeitsschritt) und der Frustration der Anwender.

Insgesamt bleibt die Erfassung von Kursqualitäten ein generelles Problem. Ich hoffe mit Kollegen diesen Aspekt in den nächsten Jahren zu verbessern. Mehr dazu im nächsten Artikel.

Die (Ab-)Gründe

Man muss sich klar machen, dass die HPC-Nutzung auch (zumindest z. Zt. und bei uns) Programmierung/Skripte schreiben und das eigenständige Parameterisieren von Jobs beinhaltet. Und DAS bedeutet die Notwendigkeit völlig neue Konzepte zu vermitteln, denn die meisten Teilnehmenden sind WissenschaftlerInnen ohne IT-Hintergrund. Hinzukommt für viele die Notwendigkeit ganze Arbeitsflüsse per Skript zu beschreiben — und das auf einer Maschine, die eben nicht einem x-beliebigen Server gleichkommt. Das überfordert viele.

Warum das so ist wird klar, wenn man sich mit der Psychologie des Lernens ein wenig befasst. Wie ich bereits beschrieb, muss ich mich auf einen heterogenen Hintergrund von Nutzern einstellen und davon ausgehen, dass diese kaum Kenntnisse des wissenschaftlichen Rechnens und Programmierens mitbringen. Oder anders ausgedrückt: Meine Situation als Lehrer ist analog zu Informatikern, die den Einstieg in die Programmierung unterrichten. Mangels Studien im eigenen Bereich, kann ich meine Situation immerhin mit dieser vergleichen und sehen, dass man lange und wiederholt zu der Erkenntnis gekommen ist, dass Befunde übertragbar sind. Dankenswerterweise ist die Vermittlung von Grundlagenwissen in der Programmierung schon länger Forschungsgegenstand (weil viele DozentInnen bemerkt haben, dass prinzipiell einfachste Dinge nicht im ersten Anlauf vermittelbar sind)[Soloway and Bonar, 1983; McCracken et al., 2001; Lister et al., 2004]. Und wir/ich haben/habe nur diesen einen Anlauf den TeilnehmerInnen mehrere neue Konzepte zu vermitteln. Also verbleiben unweigerlich ein großer Teil der KursteilnehmerInnen auf einem Niveau, dass ein selbsttätiges Verfassen mehrschrittiger Analyseverfahren in Form von Jobscripten nicht erlaubt. Dieses Ziel ist also — unter dem gegebenen Rahmen — nicht zu erreichen. Sollte jemand den heiligen Gral gefunden haben und mit Belegen (!) widersprechen können, räume ich einen Gastartikel ein!

Lösungswege?

Also den Kopf in den Sand stecken?  Die stete Verbesserung des Kurses, die Einbettung in weitere Kurse (z. B. Programmierung), das Herausgehen in die Fachbereiche und dort für unsere Services zu werben (z. B. Versionsverwaltung, Mit-Betreuung studentischer Arbeiten – gerade in AGs ohne IT-Bezug, etc.) sind selbstverständlich.

Vor allem — kenntnisreichen Mitlesenden ist es bestimmt aufgefallen — habe ich noch gar nicht über Workflowmanager geschrieben. Ich bin überzeugt: Wenn es nicht möglich ist einer breiten Masse zu vermitteln, wie sie beliebige, reproduzierbare Datenverarbeitung auf einem HPC-System gestalten kann, dann gilt es das System weitmöglichst zu abstrahieren, um die Nutzung des Systems attraktiv zu gestalten. HPC-Systeme sind einfach umständlich: Batchsysteme, besondere Filesysteme und nicht zuletzt der Nimbus des unnötig Komplexen, schrecken manche Nutzergruppen ab.

Und die Hoffnung stirbt zuletzt: Die angewandte Informatik ist noch jung. Die gegenwärtige Professorengeneration wurde zu einer Zeit vor den Flachbildschirmen und allgegenwärtiger IT sozialisiert. Noch herrscht in weiten Teilen die Idee, dass Turnschuhadministration das non-plus Ultra ist, browserbasierte Datenanalytik das Maß der Dinge darstellt und Leute, die ein Skript schreiben können noch(!) als unschlagbare Experten gelten. Mit mehr Kursen — auch zu Themen wie Programmierung, Profiling, etc. — wollen wir vor Ort die Situation verbessern und ich weiß: Anderswo gibt es Bestrebungen in dieselbe Richtung. Wir sind schon ein Stück weit gekommen. Also, mein Dank an alle, die rund um wissenschaftliche Datenanalytik gute Lehre machen!

Und die Moral von der Geschicht’?

Im Grunde habe ich hier beschrieben, in welche Fettnäpfchen ich getreten bin. Fortbildung im Bereich der Hochschuldidaktik ist freiwillig und nicht unbedingt auch evidenzbasiert. Und so gibt es enorm viele Behauptungen und in meinem Fall auch Anforderungen von externer Seite. Die einzige Möglichkeit dennoch wirklich gute Lehre zu machen:

  • Scheuklappen anlegen: Sind die externen Anforderungen gut, plausibel und umzusetzen? Na ja, denn spricht nichts gegen sie. Trifft das nicht zu, aber man muss sie umsetzen? Pech gehabt.
  • Daten sammeln, Daten sammeln, Daten sammeln: Nichts wirkt so gut wie Daten. Insbesondere bei fakultativen Kursen. Je mehr Daten, desto besser das Argument, denn fakultative Kurse stehen früher oder später in der Diskussion, womöglich sogar zur Disposition …
  • Vor Konzeption der Veranstaltung Rat suchen und / oder Literatur zu Rate pflegen. Ist trivial? Ich wette das geschieht nur höchst selten …

Weiter geht es mit einem Beitrag zum “HPC Certification Forum” (einem Forum zur Verbesserung der Lehre in unserem Bereich), “Dokumentation für Anwender” und einem Ausblick. Und später  warum Workflowsysteme auf Clustern hochinteressant und zugleich nicht trivial zu implementieren sind und was sie kennzeichnet.

— — — —

+ Das sind unsere Ziele: Andere Einrichtungen mögen andere Ziele verfolgen, z. B. gibt es Cluster an denen Nutzer Software selber installieren. Wie das, in HPC-konformermer Weise, geht ist dann auch Teil eines solchen Einführungskurses.

 

flattr this!