Schlagwort: MegaMol

Nächste Woche ist es soweit die SIGGRAPH ASIA 2014 findet in Shenzhen, China, statt. Ich bin vorbereitet und freue mich auf eine tolle Konferenz und auf die Gelegenheit meine Arbeit vorstellen zu dürfen: Technical Papers – Special Session: Visualization, Donnerstag der 4. Dezember; 11:00 Uhr

Ich arbeite gerne mit Software. Es macht mir Spaß mit großen Daten zu hantieren und interaktive 3D-Visualisierungen zu schaffen die nützlich, schön und cool sind. Auf dem Weg brauch ich natürlich die Hilfe einer riesigen Vielzahl von Funktionen, Libraries und Services. Bis die ganzen tausend Bausteine gut zusammenpassen ist es ein ätzender Kampf. Aber, es wäre gelogen, wenn ich leugnen würde das mir dieser Kampf auch Spaß machen. Es ist toll an zu sehen wie sich die Einzelteile mehrerer Personen zu einem funktionieren Ganzen zusammenfügen. In meinen aktuellen Projekten verbinden sich so Source-Code-Teile von meinen Kollegen in Dresden, meinen Ex-Kollegen in Stuttgart, meinen SHK, den von mir betreuten Studenten und von mir selbst.

Was allerdings nervt sind die Interfaces und die Stabilität der Teilkomponenten. Natürlich kann man hinter einen guten Interface die Implementierungen austauschen ohne den Rest des Systems zu beeinflussen, aber zeigt mir ein gutes Interface! Ich hab noch keins gesehen das keine Probleme mit sich bringt, und ich hab mir einige angeschaut. Die Weiterentwicklung eines Systems wird immer schwieriger je mehr Komponenten hinein kommen. Vor allem wenn es keinen Architekten mehr gibt, der den wirklichen Überblick hat.

Tatsächlich ist MegaMol auf genau diesem Weg. Es wird immer aktiver in Stuttgart und Dresden eingesetzt, und natürlich möchte ich diesen Prozess fördern und ausweiten. Immerhin ist MegaMol mein Projekt und ich bin auch stolz drauf. Aber, je größer es wird und je mehr es eingesetzt wird, desto schwieriger ist es weiterzuentwickeln. Einige fundamentale Probleme brauchen fundamentale Änderungen. Das wird noch für viel Unmut sorgen. Mir ist auch nicht klar wer den ganzen Arbeitsaufwand stemmen wird können. Einerseits trete ich etwas zurück um andere Aufgaben zu erfüllen und versuche hauptsächlich dirigierend die Weiterentwicklung von MegaMol zu leiten. Andererseits wird die Entwicklung von MegaMol gerade wie der schwarze Peter von einem Doktoranden zum nächsten geschoben, was auch nicht gerade zielführend ist. Ich bin mir wirklich nicht sicher was kommen wird.

MegaMol-Modul-Graph (10.1109/TVCG.2012.282)

Aber ich habe meine Pläne. „Partitioning“! Und ich weiß genau welche Teile Priorität haben und welche kritisch sind. Das Problem sind aber die Interfaces zwischen den Teilen. Diese sind noch nicht sauber und damit ist das ganze Partitioning zurzeit für die Katz. Die ersten Versuche das zu korrigieren waren … semi-erfolgreich. Aber, ich denke gar nicht daran aufzugeben!

Während meinem Urlaub ergab sich mal wieder einiges. Einerseits durfte ich natürlich arbeiten und für einen ausgefallenen Reviewer einspringen. Andererseits wurde ich nun aber auch auf einen Workshop eingeladen um dort meine Arbeit vorzustellen, im Besondern natürlich MegaMol™. Schön wenn man geschätzt wird, auch wenn der Workshop direkt von meinen Kumpels aus dem SFB 716 veranstaltet wird.

Ein echter Dauerbrenner im Kontext der wissenschaftlichen Visualisierung ist das Problem mit Dateiformaten. Im Normalfall taugen die Formate nix oder es gibt keine etablierten Standards. Häufig grinsen einen Simulationsergebnisse als ASCII-Text-Dateien an, die nicht nur unglaublich groß sind, sondern auch unglaublich ätzend zu parsen.

Mit MegaMol™ haben wir mehrfach versucht dieses Problem anzugehen, mit mäßigem Erfolg. Die Liste der Dateiformate die wir wegen unseren Kooperationspartnern lesen können müssen haben wir schön ergänzt, um einen ganzen Zoo eigener Dateiformate die ähnlich wenig taugen. Dieses Jahr ist dann die Notwendigkeit entstanden größere Daten (nicht Big Data) so schnell wie möglich laden zu können. Das Ergebnis ist der augenblicklich sinnvollste Weg Daten für MegaMol anzulegen: das MMPLD-Dateiformat. Dahinter verbirgt sich nichts anderes als ein fetziger Binär-Memory-Dump der einfachsten internen Datenstruktur die MegaMol zu bieten hat.

Was soll ich sagen, es funktioniert. Natürlich ist das keine Lösung mit Nachhaltigkeit oder Skalierbarkeit, aber die große Vielzahl an gescheiterten Versuchen ein sinnvolles Dateiformat zu gründen wirft die Frage auf ob das überhaupt sinnvoll möglich ist. Ich möchte die Hoffnung nicht aufgeben. Wir, das sind CGV-TUD, VISUS, HLRS, ThEt-PB, SCCS TUM und TLD-KL, haben uns zumindest geeinigt, dass wir alle das gleiche Problem haben und zusammen an einer Lösung interessiert sind. Man darf gespannt sein, was die Zukunft bringt.