Woche #54

(Zeitraum: 29.10.2012 – 31.10.2012)

Montag ist ein inter-experimentelles Seminar zu Online-Tracking an der GSI. Menschen von PANDA und CBM, aber auch von ALICE und HADES stellen sich vor, was sie wissen, was sie gelernt haben und was sie in der Zukunft zum Thema Online Event Reconstruction geplant haben.
Auch wenn es vielleicht bei den etwas erfahreneren Teilnehmern nicht ganz gut war, ich fand’s zumindest ein mal interessant, einen Überblick zu bekommen, was sonst so überall gemacht wird. Welche politischen Entscheidungen das Meeting jetzt nach sich zieht, kann ich allerdings nicht sagen.

Beim Meeting erfrage ich mir von einem Mit-PANDA’ler den Source Code, um ein spezielles Feature aus unserem STT-Detektor via Hough Transformation zu extrahieren.
Der STT-Detektor braucht nämlich eine Startzeit, damit man aus ihm verwertbare Daten rausbekommt. Die Startzeit ist allerdings keine naive Größe des Detektor. Wie ich das jetzt sehe, ist die wahrscheinlichste Quelle der Zeit schlussendlich entweder der etwas weiter außen liegende, aber schnelle Sci-Til-Detektor oder der ganz innen sitzende, allerdings nicht ganz so schnelle MVD-Detektor. Der PANDA-Kollege hatte aber die Idee, beim STT durch brute force einfach alle möglichen Startzeiten durch zu testen und die zu nehmen, die den geringsten Fehler auf die Messungen gibt. Pro: Immanente Berechnung der Startzeit ohne weitere, ‘externe’ Detektorinformationen; Con: Viel Rechenpower, evtl. größere Fehler (?).
Er hat den Code erst ein mal testweise in C geschrieben. Seine Arbeitsgruppe untersucht aber die Möglichkeit, FPGAs zum Online-Tracking zu benutzen (KONKURRENZ!). Das heißt, er wird als nächstes seinen Code in der FPGA-Programmiersprache VHDL schreiben. Damit wir weiterhin vergleichbare Werte haben, soll ich den Code für die GPU umsetzen. Und, mit dem Triggerwort brute force wisst ihr, dass das vermutlich tatsächlich ein hervorragendes GPU-Problem ist.
Den Code kriege ich zwar, brauche aber noch ein paar Hilfestellungen, bevor ich loslegen kann.

Die Zwischenzeit vertreibe ich mir damit, ein paar Sachen in meiner eigenen Thrust-powered Hough Transformation umzusetzen, die ich mir schon lange vorgenommen hatte: Das extrahieren der eigentlichen Hough Transformation (inkl. Conformal Map) in eine eigene Klasse. Im Zuge dessen probiere ich auch mal das git-Feature unterschiedlicher branches aus. Git gefällt mir immer mehr, aber noch stolpere ich zwischendurch. Allerdings das veröffentlichen auf github macht Spaß (da ist sie wieder, die stille Hoffnung, jemand interessiert sich mal für meinen Kram…). Während ich so die Klasse umbaue, implementiere ich außerdem ein etwas intelligenteres umkopieren von (vec a, vec b) –> vec (a,b).
Allerdings ist das auch erstmal nur temporär – ein wildes Rumlesen eben versteinerte die Erkenntnis, dass ein solches »Array of Structs« performance-mäßig super schlecht ist. Eventuell muss ich da noch mal anders umsetzen.

Jedenfalls: Jetzt gibt’s zwei hübsche Klassen, die alles wichtige erledigen, und von Conformal Map, Hough Transformation (AhHoughTransformation), Histogrammerzeugung (AhTwoArraysToMatrix) alles durch kleine Aufrufe erledigen:
AhHoughTransformation * houghTrans = new AhHoughTransformation(h_x, h_y, maxAngle, everyXDegrees);
thrust::device_vector<double> alphas = houghTrans->GetAngles();
std::vector<thrust::device_vector<double> > transformedPoints = houghTrans->GetVectorOfTransformedPoints();
etc.
Außerdem setze ich das Timing, das ich in die Histogrammerzeugungs-Klasse eingebaut hab, auf GPU-CUDA-Timings um. Präziser! Im Zuge dessen fällt mir auf, dass ich das in AhHoughTransformation noch gar keine Timing Hooks eingebaut hab. Todo.

Die Woche ist kurz. Allerheiligen ist zum Glück in NRW ein Feiertag, so dass ich Hessen Mittwochabend über eine volle Autobahn gen Heimat verlassen kann. Und: Aloha Brückenfreitag.