Woche #30

(Zeitraum: 14.5.2012 - 16.5.2012)
Wieder nur eine kurze Woche in der ich mich mit Bochum- und CUDA-Übungen beschäftige.

Im Bochum-Aufgabenblatt schreiben wir unseren eigenen, auf eine Funktion spezifizierten Monte-Carlo-Würfeler. Cool.

Bei CUDA muss ich immer noch auf holen. Langsam komme ich mir doof vor, im EVO (von uns ab jetzt EVIO genannt) zu sagen, dass die Germans wieder mal einen Holiday hätten. Aber gerade ist's auch wirklich feiertagsdichtgepackt.

Am Ende der Woche stelle ich fest, dass mein Arbeitscomputer die GPU rausgeschmissen hat und das Device nicht mehr als »CUDA compatible« erkannt wird. Problemlösung: Wochenende machen und Montag genauer anschauen.

Woche #29

(Zeitraum: 7.5.2012 - 11.5.2012)
Eine Woche nicht anwesend gewesen, eine ganze Reihe Übungen verpasst. Ich starte also, Übungen für den Programmierkurs in Bochum und Übungen für den CUDA-Kurs aufzuholen.

Langsam wird's bei beiden Kursen tatsächlich interessant.
In Bochum starten wir damit, eine Detektorgeometrie zu entwickeln. Das theoretische, struktur-lernende Programmieren der letzten Wochen findet also langsam ein Ende und wir machen praktischen Kram. Cool!

Und auch in Ohio beim CUDA-Kurs geht's langsam ans Eingemachte. Wir erarbeiten uns paralleliserte Fit-Methoden. Unser Tutor hat dazu in seiner Dissertation ein Fit-Framework in CUDA entwickelt, das ROOT-Funktionen (TMinuit) involviert. Ganz schön crazy. Aber auch ganz schön wirsch.
Vorher gibt's noch eine Übung in der wir uns mit Matrix-Multiplikation auseinander setzen sollen. Dabei hätte er gerne »double ** Matrix«-Pointer verwandt, die ganz schön doof zu initialisieren sind. Und noch doofer auf die GPU zu kriegen.

Woche #27

(Zeitraum: 23.4.2012 - 27.4.2012)
Eigentlich nichts geschafft. An meinem Thema.
Viel Zeit mit der dieswöchigen CUDA-Übung verbracht, die partout nicht laufen wollte. Hab's auch nicht vollständig hingekriegt, mich aber zum Glück durch viele Diskussionen mit dem Tutor im Forum auf einen guten Weg begeben. Aus dieser Sicht ist es dann doch auch irgendwie positiv, zu merken, dass man das Konstrukt langsam beginnt zu verstehen. Diese Gefühlslage hält vermutlich genau so lange an, bis ich die nächste Übung in den Händen halte. Naja.
Außerdem habe ich Programmierübung für Bochum gemacht. Xcode gefällt mir tatsächlich ganz gut.

Diese Woche bekam ich auch meine eigene CUDA-fähige Grafikkarte – eine nVidia GeForce GTX 580. Ein schmuckes Stück, was, laut Ansage des Admins, nur so gerade ins Computergehäuse reingepasst hat. Das brauchte alles etwas Zeit, weil ich zusätzlich zur Grafikkarte auch noch ein neues Computernetzteil benötigte, was überhaupt in der Lage ist, die notwendige Leistung beizusteuern. Nice.

Die nächste Woche bin ich in Berlin auf der re:publica, einer Konferenz über Internetweb2.0undso. Habe also frei.

ROOT in Xcode

Zumindest halb, nämlich Autovervollständigung.
In Xcode im passenden »Project« unter »Build Settings« den »Library Search Path« zum include-Verzeichnis der ROOT-Installation zeigen lassen. Bei mir ist das Verzeichnis »/Applications/root/include«.

Wenn man nun im ROOT-Makro die einzelnen .h-Files einbindet, z.B. »#include "TH1.h"«, dann hat man auch Autovervollständigung. Yay.

Es geht wohl sogar noch mehr, aber für mich reicht Obiges: http://root.cern.ch/drupal/content/how-use-root-libraries-xcode-mac-os-x
Vorlesung

Woche #26

(Zeitraum: 16.4.2012 - 20.4.2012)
Und wieder eine kurze Arbeitswoche.

Montag und Dienstag kümmere ich mich um die aktuelle  CUDA-Übung. Es geht um Thrust. Thrust benutzt viele Iteratoren. Ein bescheuertes Konzept. Am bescheuertesten: thrust::constant_iterator. Wird angelegt als Array, also ungefähr so: thrust::constant_iterator bla(10). Eine Anfrage auf irgendein Element des bla-Arrays gibt dann aber als Rückgabe 10. Egal ob bla[100] oder bla[42]. Crazy. Kostet irgendwie weniger Speicherplatz im Memory.
Übung schaffe ich nach einigem hin und her (structs müssen also außerhalb der main definiert werden…) fast in letzter Sekunde. Sie scheint auch ganz gut zu sein, der Tutor wird sie in der folgenden Woche in der Vorlesung als Lösungsleitfaden vorstellen. Ha!

Am Mittwoch kümmere ich mich um die Übung zur Vorlesung in Bochum, die in der letzten Woche angefangen hat.

Donnerstag fahren wir nach Bochum. Ein Kollege hat seine Verteidigung – ein Doktor mehr im Institut.
Und auch Freitag geht's nach Bochum, es ist schließlich wieder Vorlesungszeit. Dieses Jahr heißt die Vorlesung, die wir besuchen, »Detektoren und Algorithmen zur Spurrekonstruktion geladener Teilchen«. Momentan kriegen wir noch C++ beigebracht, bald geht's um ROOT und kompliziertere Sachen der Programmiersprache. Irgendwann werden wir einen Detektor nachbauen und ganze Algorithmen schreiben. Klingt spannend.
Beim einfachen Objektorientiert-C++-Krams fällt mir auf, dass ich tatsächlich immer noch nicht vernünftig und stringent mit Pointern und Referenzen umgehen kann. Das verwirrt mich dauernd und meistens finde ich die Problemlösung eher über Trail-and-Error-Methode als durch intelligentes Nachdenken. Ich sollte daran arbeiten ;).

Außerdem beantragen wir eine neue Dienstreise. Im Juli geht's nach Turin zu einem einwöchigen Computing-Workshop. Das wird bestimmt cool.

Woche #25

Hcgcv

(Zeitraum: 10.4.2012 - 13.4.2012)
1,5 effektive Arbeitstage diese Woche. In denen ich mich damit beschäftige, meinen CUDA-Kurs nachzuholen. Eine Vorlesung habe ich verpasst, es ging um Debugging (cuPrintf, andere Debugger) und die verschiedenen Arten von Memory (shared, constant und noch zwei). In der passenden Übung sollen wir einen Reduktionscode verfeinern. Auch drei Tage nach Übungsabgabeschluss scheint noch keiner ein Resultat beim Tutor abgeliefert zu haben (ich auch nicht), er mutmaßt, es war zu schwer und er wird eine Lösung anbieten.
In der aktuellen Lecture geht es um Thrust, einer Erweiterung für CUDA. Meine Definition: Thrust ist für CUDA das, was C++ für C ist. Des Kursleiters Definition: Thrust ist die Std-Library für CUDA. Wie auch immer: Thrust nimmt einem ganz viel Kram ab. Zum Beispiel das fiese Zuweisen von Speicher und solche blöder, technischer Overhead. Endlich!

Am Mittwochabend machen wir uns auf für einen Workshop zum Schloss Rauischholzhausen, ein Tagungsort der Universität Gießen und ein Schloss, das erst 150 Jahre alt ist. Der Workshop geht über DAQ und FEE (Dataaquisition und Front End Electronic) – es wird koordiniert und ausgetauscht, wie der Datenfluss von den innersten Detektoren zur Speicherfestplatte stattfindet. Interessant, prinzipiell, aber aus GPU-Sicht nicht sehr Vieles dabei. In Gießen lässt man Helix-Tracking-Algorithmen auf FPGAs laufen – aber sehr weit ist man da noch nicht.

Das Schloss ist interessant und Eduroam wirklich eine tolle Sache. Und Informatiker sind härtere Nerds als Physiker, damit wir dieses Vorurteil auch mal geklärt hätten.

Achja: Mein erstes halbes Jahr Promotion ist am Sonntag vorbei. Wie diese Zeit vergeht. Puh.

Woche #24

(Zeitraum: 2.4.2012 - 5.4.2012)
Ich bearbeite meine erste Übung vom CUDA-Kurs. Nicht so schrecklich schwer, aber ganz zu Ende krieg ich sie trotzdem nicht. Immerhin bekomme ich noch 10 von 11 Punkten.
Beim letzten Programmierschritt (Reduktion (=Summation) via GPU-Kernel) stolpere ich. Wiederholt. Wie sich herausstellen wird, waren Pointer und Referenzen zu doubles mein Problem – wer macht denn auch sowas? Außerdem gab es wohl auf dem GPU-Supercomputing-Cluster ein Problem mit der CUDA-Methode cudaMemcpy(), die mir auch noch wild dazwischen gespielt haben könnte.
Außer-Außerdem: Auf meinem MacBook scheint CUDA doch nicht so astrein zu laufen. Wenn ich mal Ruhe habe, muss ich das investigieren – die nVidia-Karte für meinen Arbeits-PC ist noch nicht einsatzfähig (Karte zwar da, aber leistungsfähigeres Netzteil fehlt noch…).

Wir buchen unser Hostel für Chicago. Die »Urban Holiday Wicker Park Dorm Beds«. Sehen ganz nett aus, sind frisch renoviert (noch nicht eröffnet), liegen zentral und sind günstig.

Den Rest der Woche bin ich in den Alpen auf dem Familienwinterurlaub (mit Scheißwetter).

Woche #23

(Zeitraum: 26.3.2012 - 30.3.2012)
Posttagungswoche. Äußerst unproduktiv.
Papierkrams erledigen und nur wenig an meinem Thema schaffen.

Ich schaffe es, meinen Code zu fixen. Ein Programmierproblem behebe ich. Und warum es dann immer noch nicht stimmt, darauf bringt mich ein Kommentar von André: Wenn man Histogramme in Stacks packt (wegen der Farben!) – dann ist da bei mir eigentlich meistens die Draw()-Option "nostack" die Richtige. In dem Fall aber nicht, da waren die unterschiedlichen Farben nämlich hintereinander. Tricky.
Jetzt muss ich nur noch den kleinen AvgDist-Schnittwert finden, bei dem ich von allen MC-überprüften wahren Quell-Tracks mindestens einen erwischt habe. Ich befürchte, ich muss wieder einiges neuprogrammieren.
Nebenbei steht auch noch die Hough-Transform-eske Idee der Überprüfung der Multiplizität der einzelnen Track-Fit-Parameter meines Betreuers auf dem To-Do-Menü. Mal sehen, wann ich dazu komme. Vermutlich implementiere ich das noch vorher.

Die meiste Zeit der Woche verbringe ich allerdings damit, einen GPU-CUDA-Programmierkurs zu besuchen. In Ohio. Oder Stanford, da bin ich mir nicht so sicher. Das funktioniert per Videochat auf EVO. Eine Stunde Vorlesung und eine Übungsabgabe pro Woche. Mal sehen, wie das wird.

Woche #22

(Zeitraum: 19.3.2012 - 23.3.2012)
Wir sind auf der Frühjahrstagung der Deutschen Physikalischen Gesellschaft an der Universität Mainz. Von diesen Tagungen gibt's im Jahr vier, wir (»Hadronen und Kerne«) sind zusammen mit der Didaktik der Physik an der Johannes-Gutenberg-Universität, die sich selbst »Johannes Gutenberg-Universität« schreibt und sich damit als geisteswissenschaftlich-zentrierte Universität einen um ε peinlicheren Fehler leistet als sowieso schon.

Auch bei meiner zweiten DPG bestätigt sich der Eindruck, den ich schon bei der ersten gehabt hab: Das Prinzip »Jeder darf Vortragen« ist in der Theorie wirklich super – praktisch ist aber der ganze Tag voller lange und kurzer Talks die einen nicht interessieren, die man nicht versteht oder beides. Nur selten gibt's ein paar Rosinen, bei denen man zwischen Comic Sans, überlappenden, regenbogenbunten Bildern und überziehenden Rednern interessante, neue Informationen kriegt.
Man könnte sich die langweiligen Vorträge mit Arbeit am Computer spannender machen – gäbe es Steckdosen in den Hörsälen. Gibt's aber nicht.

Wir besuchten den Forschungsreaktor des Mainzer Instituts für Kernchemie: .

Positiv an Mainz gegenüber dem Rand-Darmstadt-Nichts vom GSI: Man kann abends was trinken gehen. Toll. Das lässt selbst über den Umstand hinwegsehen, dass wir drei Tage vor Konferenzbeginn erfuhren, das unser Hotel storniert war, und wir nun in einem außerhalbigen Stundenhotel-eskigem Dings unterkommen sollten (Randnotiz: Laute Heizungen verfolgen mich!).