Schlagwort: MegaMol

[:de]Dieser Artikel präsentiert die Details zu Plugin-Plugin-Abhängigkeiten in MegaMol™. Als Hauptszenario nutzt ein Plugin (oder mehrere) exportierte Call-Klassen eine anderen Plugins (und nicht des MegaMol™-Cores).

Tatsächlich wurde am MegaMol™-Core nichts geändert. Die Plugin-Plugin-Abhängigkeiten funktionierten bereits größtenteils. Die Einschränkungen und im Besonderen die Probleme im Fehlerfall sind unten beschrieben.

Testproject: interplugin_test

Dieses Projekt hat zwei Plugins:

https://bitbucket.org/MegaMolDev/megamol_interplugin_test

Plugin A exportiert 2 Module und 1 Call.

Plugin B exportiert ein Modul, welches aber den Call aus Plugin A nutzt.

Export des Call-Header

Normalerweise werden Module und Calls nur über ihrer Metadaten-Description exportiert, als Teil der Implementierung in „plugin_instance“. Diese Metadaten reichen dem MegaMol™-Core um die Module und Calls zur Laufzeit zu instanziieren. Die Klassen selbst werden üblicherweise nicht direkt exportiert.

Wenn wir nun allerdings einen Klasse, einen Call, in einem anderen Plugin zur Compile-Zeit nutzen wollen, dann muss diese Klasse exportiert sein. Zunächst muss der Header der Klasse im Ordner der öffentlichen Header des exportierenden Plugins liegen. Typischerweise sieht das so aus wie im Demoprojekt: „./a/include/interplugin_test_a/IplgDemoCall.h“ Ich empfehle auch die Headerdatei im Visual Studio Solution Explorer in den Filter “Public Header Files” zu legen um hier konsistent zu sein.

Zusätzlich muss die Klasse noch exportiert werden. Das geschieht mit dem API-Macro des Plugins: z. B. „INTERPLUGIN_TEST_A_API”, welches in Haupt-Header des Plugins definiert ist, z. B. „interplugin_test_a/interplugin_test_a.h“

Natürlich müssen die Metadaten-Descriptions des Calls trotzdem nach wie vor in der „plugin_instance“ exportiert werden (vglf. „interplugin_test_a.cpp“ Zeile 51).

Calls in einem anderen Plugin einsetzen

Um den Call nun in einem anderen Plugin zu nutzen muss dieses prinzipiell nur gegen das exportierende Plugin linken. Dem Demoprojekt folgend nennen wir das exportierende Plugin A und das nutzende Plugin B.

Zunächst sind beides einfach nur Bibliotheken, und A ist eine Abhängigkeit für B. Für Visual Studio empfehle ich das Skript „configure.win.pl“ und die Datei „ExtLibs.props.input“ anzupassen, als würde man irgendeine andere Drittherstellerbibliothek hinzufügen. Im Demoprojekt ist der Pfad von Plugin A in „ExtLibs.props.input“ hardgecoded. Anschließend kann das neue User-Macro in den Projekteinstellungen genutzt werden:

  • C/C++ > General > Additional Include Directories
    • Z. B. $(PluginAPath)include\
  • Linker > General > Additional Library Directories
    • Z. B. $(PluginAPath)lib\$(PlatformName)\$(Configuration)\
  • Linker > Input > Additional Dependencies
    • Z. B. interplugin_test_a.lib

Der Linker nutzt nur die Import-Bibliothek von Plugin A, nicht das kompilierte Plugin selbst.

Nun können auch die öffentlichen Header von Plugin A gefunden und Includet werden, vgl. „./b/src/IplgValueInvertB.cpp“ Zeile 3. Plugin B kann nun die exportierte Klasse ganz normal nutzen, wie jede andere Klasse jeder anderen Bibliothek auch. Keine Sonderbehandlung ist notwendig.

Unter Linux könnte man im „CMakeLists.txt“ auch entsprechende Einstellungen einbauen. Ich habe das nicht gemacht.

Ich installiere alles von MegaMol™ beim Bauen in ein lokales Unterverzeichnis in meinem Home (angegeben durch den Install-Prefix bei den Build-Skripten). Dadurch sind alle Teile MegaMols™ an derselben Stelle. Das betrifft natürlich auch den Core, welcher bereits durch das „CMakeLists.txt“ gefunden wird, und auch Plugin A, welches daher versehentlich gefunden wurde. Daher ist der Include-Pfad für die öffentlichen Header des „installierten“ Plugins bereits bekannt. Außerdem ist es unter Linux nicht notwendig Shared Objects gegen ihre Abhängigkeiten zu linken. Das ist Aufgabe des Runtime-Loaders sämtliche Referenzen aufzulösen. Daher sind weitere Einstellungen zum Bauen des Plugins schlicht nicht notwendig.

Wenn Sie trotzdem das exportierende Plugin explizit finden möchten, beispielsweise, weil es nicht installiert sein sollte, dann müssten Sie am sinnvollsten ein entsprechendes CMake-Find-Skript schreiben und in der „CMakeLists.txt“ des abhängigen Plugins „find_package“ nutzen. Zumindest augenblicklich ist mir das aber egal, da das exportierende Plugin sowieso installiert sein muss, damit alles zur Laufzeit funktionieren kann.

MegaMol™ mit beiden Plugins konfigurieren

In der MegaMol™-Konfigurationsdatei müssen beide Plugins ganz normal angegeben werden, entweder explizit mit ihren Namen (empfohlen) oder per File-Globbing. Sie sollten aber die Anhängigkeiten beachten und die Plugins in der richtigen Reihenfolge laden, z. B. Plugin A sollte vor Plugin B geladen werden. Technisch ist es aber egal.

Beide Plugins, alle Plugins, sind im Prinzip nur Dlls. Wird Plugin B zuerst geladen, also die Dll, so werden auch alle abhängigen Dlls geladen. Dabei ist auch die Dll Plugin A dabei welche daher in den Speicher geladen wird. Allerdings sind die Metadaten von Plugin A noch nicht in den Core geladen und seine Module und Calls daher noch nicht zur Laufzeit verfügbar. Wird nun das Kommando ausgeführt um Plugin A zu laden, und das Betriebssystem aufgefordert diese Dll zu laden, so befindet diese sich schon im Hauptspeicher. Anschließend werden die Metadaten in den Core geladen und stehen den Factories zur Verfügung.

Warnung vor zyklischen Abhängigkeiten

Zyklische Abhängigkeiten sollten, wie immer, vermieden werden. In der Theorie sollte es möglich sein zyklische Abhängigkeiten aufzulösen. Allerdings, sollten Sie ihren Code in diese Richtung entwickeln, dann empfehle ich dringend ein weiteres Plugin zu starten in dem Sie alle gemeinsam genutzten Klassen auslagern, z. B. Calls.

Laufzeitverhalten wenn abhängige Plugins nicht gefunden wurden

Die Fehlermeldungen des Betriebssystems wenn eine Dll (Plugin) nicht geladen werden kann sind ziemlich nutzlos. (Ich arbeite hier an Verbesserungen, aber das ist weit nicht so einfach wie man denken würde.) Normalerweise sagt die Fehlermeldung nur, dass die Dll nicht geladen werden konnte. Denken Sie also daran, dass diese Fehlermeldung nun auch kommen kann wenn ein Plugin die Plugins nicht laden kann von denen es selbst abhängt. Die Plugin-Abhängigkeiten müssen also sowohl zur Compile-Zeit als auch zur Laufzeit auflösbar sein. Beides löst sich selbst wenn einfach alle Plugins in den gleichen lokalen Ordner „installiert“ werden.

Versionsnummertests

Alle Plugins prüfen zum Zeitpunkt wenn sie geladen werden die Versionsnummern von Core und Vislib. Damit werden Inkonsistenzen zur Laufzeit verhindert. Stellen Sie sich vor, sie bauen den Core und arbeiten dann an ihrem Plugin. Dabei fällt eine Bugt in der Vislib auf und wird von ihnen gefixt. Core und Plugin würden nun unterschiedliche Vislibs benutzt und nur diese Versionsnummerprüfungen teilen ihnen mit, dass das eine wirklich schlechte Idee ist.

Nun ersetzen Sie in diesem Szenario die Vislib mit Plugin A. Willkommen in der Hölle. Augenblicklich gibt es keinen Mechanismus um Versionsnummer zwischen Plugins zu überprüfen. (Wahrscheinlich kommt auch keiner vor der Implementierung des berüchtigten „Call-Interface-Redesigns“.) Sie müssen einfach aufpassen!

 [:en]This article details the work with inter-plugin dependencies in MegaMol™. The primary scenario is to have one (or many) plugins use Call classes exported by another plugin (and not the MegaMol™ core).

Actually, nothing was changed in the MegaMol™ core. Inter-plugin dependencies already worked, to some extent. The limits, and especially the behavior in error cases are described below.

Test Project: interplugin_test

The following project shows two plugins:

https://bitbucket.org/MegaMolDev/megamol_interplugin_test

Plugin A exports 2 modules and 1 call.

Plugin B exports one module using the call exported by modul A.

Exporting Call Header

Usually, modules and calls are only exported via their meta data description classes as part of the implementation in “plugin_instance”. This meta data is sufficient for the MegaMol™ core to instantiate the module at runtime. However, these classes are normally not exported by the plugins.

If you want to use a class, a Call, in other plugins at compile time, you have to export the type. You need to place the corresponding header file in the public export folder. For a typical case, have a look at the demo project: “./a/include/interplugin_test_a/IplgDemoCall.h” I also recommend to add the header files to the filter “Public Header Files” in the Visual Studio Solution Explorer.

Additionally, you need to export the class using the corresponding API macro: e.g. “INTERPLUGIN_TEST_A_API”, which is defined in the plugin’s primary header file, e.g. “interplugin_test_a/interplugin_test_a.h”

Of course, you still need to export the meta data description for the call itself in the “plugin_instance” definition (cf. “interplugin_test_a.cpp” line 51).

Using Call in another Plugin

Now, to use the Call in another Plugin, that one basically needs to link against the exporting Plugin. Following the demo project, the exporting plugin is called A and the using plugin in named B.

First A is a library and a normal development dependency for B. For Visual Studio, I recommend using the “configure.win.pl” and “ExtLibs.props.input” similar to any other 3rd-party library. In the demo project, the access to the subdirectory of A is hard coded in the “ExtLibs.props.input”. Then, you can use this user macro in the project settings:

  • C/C++ > General > Additional Include Directories
    • E.g. $(PluginAPath)include\
  • Linker > General > Additional Library Directories
    • E.g. $(PluginAPath)lib\$(PlatformName)\$(Configuration)\
  • Linker > Input > Additional Dependencies
    • E.g. interplugin_test_a.lib

As you see, the linker only uses the built input library of the plugin, not the compiled plugin A itself.

Now you can find the public header file of the call exported by the plugin, cf. “./b/src/IplgValueInvertB.cpp” line 3. Plugin B uses this class like any class exported from the core. Nothing special is required.

For Linux you could introduce similar settings in the “CMakeLists.txt” file. I did not.

Since I install everything of MegaMol™ into a local user directory (using the install prefix settings in the build scripts) all parts of MegaMol™ are available at the same location. This includes the core, which the “CMakeLists.txt” file already searches for and Plugin A, which is thus accidentally found too. So the public include files, which were copied when Plugin A was “installed” are already available. Linux does not require shared objects to link against their dependencies. The runtime loader is expected to resolve all issues. Thus, for building on Linux no additional settings are required.

If you want to be able to work with plugins not locally installed, you should write a corresponding find script for the base plugin A and use “find_package” in the “CMakeLists.txt” of plugin B. For now, I don’t care.

Configuring MegaMol™ with both Plugins

Just add both plugins, as usual, to the MegaMol™ configuration file. Either explicitly (recommended) or using file globing. You should keep the dependencies in mind. So you should load plugin A before you load plugin B. But technically, it does not matter.

Both plugins, all plugins, are basically Dlls. So if you load plugin B first, the Dll is loaded with all its dependencies. These include the Dll plugin A. So plugin A is in memory the, but the meta data is not known to the core yet. If then the command for loading plugin A is executed, the OS runtime is asked to load the Dll plugin A. Since that Dll is already in memory, the load succeeds and the plugins meta data is received and added to the core factory constructs.

Beware of Cyclic Dependencies

Cyclic Dependencies should be avoided, as always. In theory, they could work, like Plugin A uses a class from Plugin B and the other way round at the same time. However, if you are going towards such a scenario, I strongly recommend to create a third Plugin holding the shared classes, e.g. Calls.

Runtime Behavior if Dependent Plugin is not found

The OS runtime errors when a Dll (Plugin) cannot be loaded are rather useless. (I am working on something better here, but it is not as easy as one would think.) Usually, it only tells you that the Dll could not be loaded. So keep in mind, if you developing your plugins that other plugins you depend on, not only need to be available at compile time, but also need to be installed in the same bin directory for runtime access.

Version Number Tests

All plugins check their version numbers of Core and Vislib with the loading core. This is to avoid inconstancies at runtime. Imagine you build the Core, then work on your Plugin. In this work you stumble upon a bug in the Vislib and fix that. Then your core and your plugin use different Vislibs and only this very version check tells you that this is a bad idea.

Now, use that scenario and replace Vislib with plugin A. Welcome to hell. There currently is not version check implemented for cross-plugin dependencies. (Most likely, there will be no such check before the infamous coming “Call Interface Redesign”.) You need to be careful![:]

Veröffentlicht am Keine Kommentare Veröffentlicht in Meine Tools Tagged with

[:de]Ich hab zwar schon vorher mal darüber geschrieben, aber hier der offizielle News-Artikel von der SFB-716-Webseite.

Zur interaktiven GPU-basierte Visualisierung großer Partikeldaten

20151112_vis2015_tutorialEnde Oktober fand in Chicago die größte Konferenz zum Thema der wissenschaftlichen Visualisierung statt – die IEEE VIS 2015. Hier treffen sich jährlich Experten aus aller Welt, um neueste Forschungsergebnisse zu präsentieren und aktuelle Herausforderungen zu diskutieren. Die Konferenz gilt mit über 1.100 Teilnehmern als die größte und wichtigste internationale Plattform in diesem Bereich.

In diesem Jahr organisierten Michael Krone und Guido Reina aus der Forschergruppe von Prof. Thomas Ertl gemeinsam mit Sebastian Grottel (TU Dresden) und Martin Falk (Universität Linköping, Schweden) ein Tutorial zur interaktiven GPU-basierten Visualisierung großer Partikeldaten. Hier wurden die im SFB716 entwickelten technischen Aspekte zur Erhaltung von Qualität und Interaktivität der Partikelvisualisierung erläutert, die mittlerweile als Stand der Technik akzeptiert sind. Zusätzlich wurde auf die erforderlichen Abstraktionen, die durch ständig wachsende Datensatzgrößen unabdingbar werden, eingegangen, sowohl im Kontext von Biomolekülen und Materialoberflächen als auch in der Visualisierung ganzer Zellen.

Mit mehr als 50 Teilnehmern war das Tutorial sehr gut besucht. Die dort ausgehändigten Materialien, wie Folien, Programmcode und Beispieldatensätze können hier heruntergeladen werden.

[:en]I have written about this before, but here is the official news reblogged from the SFB 716 website.

GPU-based interactive Visualization of Large Particle Data

20151112_vis2015_tutorialAt the end of October, the largest conference on scientific visualization – the IEEE VIS 2015 – took place in Chicago. This is an anual venue for experts from all over the world to present current research and discuss future challenges. With more than 1100 participants, the conference is considered the largest and most important international forum in this domain.

This year, Michael Krone and Guido Reina from the group of Prof. Ertl, together with Sebastian Grottel (TU Dresden) and Martin Falk (Linköping University, Sweden) organized a tutorial on interactive GPU-based Visualization of large particle data. They explained the technical aspects for ensuring high quality and interactivity of particle visualizaton, which are nowadays accepted as state of the art. Part of these techniques have been developed in the SFB716. Additionally, the presentation included details on abstractions required by continuosly growing data sets. Such abstractions were disucssed in the context of biomolecules and material surfaces as well as in the context of whole cell visualization.

The tutorial was very well received with over 50 participants. The course materials distributed there, including slides, source code and example data sets can be downloaded here.

[:]

Veröffentlicht am Keine Kommentare Veröffentlicht in Forschung & Lehre Tagged with ,

[:de]Es ist soweit! Der neue Release von MegaMol ist auf seiner Projekt-Webseite verfügbar:

megamol.org

Release 1.1

Weitere Infos zur IEEE VIS aus Chicago gibt es kommenden Sonntag.[:en]It is time! The new release of MegaMol is available on its project website:

megamol.org

Release 1.1

There will be more info on the IEEE VIS conference in Chicago on next Sunday.[:]

Veröffentlicht am Keine Kommentare Veröffentlicht in Forschung & Lehre, Meine Tools Tagged with

[:en]We updated MegaMol to use cmake to build on Linux OS. This greatly improved the build process on Linux. But this also makes some more uncommon scenarios difficult to realize. For example, cmake usually automatically detects required dependencies. But, in some scenarios you need to override this magic.

In this article I show how to compile a second MegaMol on a system on which a MegaMol already has been compiled and installed. This is useful when working with experimental versions.

VISlib and visglut

First off you build the visglut the usual way. I assume here, that the installed MegaMol uses a different visglut as the one you want to build now:

mkdir megamol_x2
cd megamol_x2
svn co https://svn.vis.uni-stuttgart.de/utilities/visglut/tags/forMegaMol11 visglut
cd visglut/build_linux_make
make

If everything worked you can find the following files:

in megamol_x1/visglut/include:

GL/freeglut_ext.h
GL/freeglut.h
GL/freeglut_std.h
GL/glut.h
visglut.h
visglutversion.h

and in megamol_x2/visglut/lib:

libvisglut64.a
libvisglut64d.a

If so, let’s continue with the VISlib:

cd megamol_x2
svn co https://svn.vis.uni-stuttgart.de/utilities/vislib/tags/release_2_0 vislib
cd vislib

Now, there is the first action which is different from the default build process. As usual we will use the script cmake_build.sh. This script, however, per default registers the build directories in the cmake package registry. This enables cmake to find this package in its build trees. In this scenario, however, we do not want this special build to be automatically found, because we do not want to get in the way of our system-installed MegaMol. We thus deactivate the package registry.

This command configures and builds the VISlib, both for debug and release version:

./cmake_build.sh -dcmn

As always, if you encounter build problems due to the multi-job make, reduce the number of compile jobs:

./cmake_build.she -dcmnj 1

Note that I do not specify an install directory. I do not plan to install this special MegaMol. I just want to build, for example for a bug hunt.

MegaMolCore

It’s now time for the core.

cd megamol_x2
svn co https://svn.vis.uni-stuttgart.de/projects/megamol/core/branches/v1.1rc core
cd core

We first test the configuration by only configuring release and not building anything:

./cmake_build.sh -cv ../vislib -C -DCMAKE_DISABLE_FIND_PACKAGE_MPI=TRUE

Note that I also disabled MPI-Support here. The system I am building on has MPI installed, but I don’t want this MegaMol to use it.

The output should contain this line:

-- Found vislib: /home/sgrottel/megamol20150726/vislib/build.release/libvislib.a

This points to the right vislib, the one we specified. So all is well. We can build MegaMol, again without registering it’s build trees in the cmake package repository:

./cmake_build.sh -dcmnv ../vislib -C -DCMAKE_DISABLE_FIND_PACKAGE_MPI=TRUE

When all worked you got yourself the binaries:

megamol_x2/core/build.debug/libMegaMolCored.so
megamol_x2/core/build.release/libMegaMolCore.so

MegaMolConsole

Get yourself a working copy of the console:

cd megamol_x2
svn co https://svn.vis.uni-stuttgart.de/projects/megamol/frontends/console/branches/v1.1rc console
cd console

Again, we test if everything works by only configuring release and not building:

./cmake_build.sh -c -f ../core

The Console does not register its build tree per default, since no other project depends on the console. So we are fine here.

The output should contain these lines:

-- Looking for MegaMolCore with hints: ../core;../core/build.release;../core/share/cmake/MegaMolCore
-- Found MegaMolCore: /home/sgrottel/megamol20150726/core/build.release/libMegaMolCore.so
-- MegaMolCore suggests vislib at: /home/sgrottel/megamol20150726/vislib/build.release
-- MegaMolCore suggests install prefix: /usr/local
-- Using MegaMolCore install prefix
-- Found vislib: /home/sgrottel/megamol20150726/vislib/build.release/libvislib.a
-- Found AntTweakBar: /home/sgrottel/AntTweakBar/lib/libAntTweakBar.so
-- Found visglut: /home/sgrottel/megamol20150726/visglut/lib/libvisglut64.a

If the directories for other libraries are wrong, for example the AntTweakBar or the visglut use the cmake-typical DIR variable to give a search hint. Remember, relative paths might be confusion. Better use absolute paths. I don’t:

./cmake_build.sh -c -f ../core -C -Dvisglut_DIR=~/megamol20150709/visglut -C -DAntTweakBar_DIR=../../AntTweakBar

But in my case the cmake-magic worked fine in the first place. So, I configure both build types again:

./cmake_build.sh -dc -f ../core

Double check the output. Make sure the core, the vislib and the visglut are found in all the right places. If they are, built it:

./cmake_build.sh -dm

At this point you can quickly test your MegaMol. First open the megamol.cfg configuration file in a text editor and adjust the paths in there to yours. Then run MegaMol:

cd build.release
./MegaMolCon

If this seems ok, and if you have a local graphics card you can run the demo renderer:

./MegaMolCon -i demospheres s

Some MegaMol Plugin

Finally we need a plugin. I go for the mmstd_moldyn:

cd megamol_x2
svn co https://svn.vis.uni-stuttgart.de/projects/megamol/plugins/mmstd_moldyn/branches/v1.1rc mmstd_moldyn
cd mmstd_moldyn

The process is now exactly the same as with the console:

./cmake_build.sh -dcf ../core

The double check the directories for the core and the VISlib. If they are good, build the plugin:

./cmake_build.sh -dm

To test this plugin we go back to the console, and adjust the config file to load the plugin:

cd megamol_x2/console/build.release

Include the following lines in the config file. Obviously adjust the paths to what you need:

<plugin path="/home/dude/megamol_x2/mmstd_moldyn/build.release" name="mmstd_moldyn.mmplg" action="include" />
<shaderdir path="/home/dude/megamol_x2/mmstd_moldyn/Shaders" />

If you now run MegaMol it will try to load your plugin and will report it. The output console should contain something like:

200|Plugin mmstd_moldyn loaded: 11 Modules, 0 Calls
200|Plugin "mmstd_moldyn" (/home/sgrottel/megamol20150726/mmstd_moldyn/build.release/mmstd_moldyn.mmplg) loaded: 11 Modules, 0 Calls registered

And that’s it.[:]

Veröffentlicht am Keine Kommentare Veröffentlicht in Forschung & Lehre, Meine Tools Tagged with

[:de]Kommenden Montag und Dienstag ist die VII. Jahrestagung der Boltzmann-Zuse-Gesellschaft für Computational Molecular Engineering, dieses Jahr turnusgemäß mal wieder in Kaiserslautern, organisiert bei Martin Horsch. Im Großen Treffen Sich die Gruppen aus Stuttgart (VISUS, HLRS), Paderborn, Kaiserslautern und Dresden um über Simulation, Analyse und Visualisierung von Molekulardynamik-Daten zu sprechen und die gemeinsamen Forschungs- und Entwicklungsprojekte zu diskutieren. Natürlich werden Joachim und ich über die aktuellen Arbeiten mit und an MegaMol berichten. Übrigens: http://megamol.org[:en]This Monday and Thursday the VII. Annual Meeting of the Boltzmann-Zuse-Society for Computational Molecular Engineering takes place in Kaiserslautern, organized by Martin Horsch. Basically it is a meeting for the groups from Stuttgart (VISUS, HLRS), Paderborn, Kaiserslautern and Dresden, to talk about simulation, analysis and visualization of molecular dynamics data. And to discuss our joint research and development projects. Of course, Joachim and I will be talking about current works with and on MegaMol. By the way: http://megamol.org[:]

Veröffentlicht am Keine Kommentare Veröffentlicht in Forschung & Lehre Tagged with

Die ESF-geförderte Nachwuchsforschergruppe VICCI beschäftigte sich von 2012 bis Ende 2014 an der Fakultät Informatik der Technischen Universität Dresden mit der Entwicklung, Steuerung und Integration von cyber-physikalischen Systemen (CPS). Der Anwendungsbereich umfasst Smart Home-Umgebungen und die Unterstützung von Menschen im Ambient Assisted Living.

Mein Arbeitspaket für Visualisierung und visuelle Analyse hatte im Rahmen des Projekts drei wesentliche Aspekte untersucht und entsprechende Lösungen erarbeitet:

  • die visuelle Analyse komplexer, multi-dimensionaler, multimodaler,  dynamischer Raumzeit-Daten,
  • die Visualisierung in heterogener, mobiler und verteilter IT-Infrastruktur und
  • die Realisierung von Visualisierungssystemen und -Komponenten.

Heute schreibe ich über die visuelle Analyse komplexer Raumzeit-Daten.

teaser

Die visuelle Analyse dient der administrativen Übersicht über eines laufenden CPS aus Gründen der Sicherheit, als Hilfestellung während Entwicklung und des Betrieb des Systems. Im Besonderen sind außergewöhnliches (Fehl-)Verhalten und das Entstehen von emergenten Systemeigenschaften hierbei von Bedeutung. Da hierfür eine visuelle Exploration notwendig ist, dürfen nur minimal wenige vorherige Annahmen getroffen und einschränkende Darstellungsmetaphern genutzt werden. Beispielsweise, können bestimmte Daten, wie auf die Gelenke eines Roboterarms wirkenden Kräfte, effektiver Visualisiert werden, wenn diese im geometrischen Kontext dargestellt werden. Diese Annahme jedoch verringert die Allgemeingültigkeit der Visualisierung.

Ausgehend von einer entsprechenden Anforderungsanalyse wurde daher eine grundlegende Visualisierung erarbeitet, welche koordinierten Ansichten, zeit-kontinuierlichen Scatterplot-Matrizen, zeit-kontinuierlichen parallelen-Koordinaten-Plots und zeitliche Heatmaps nutzt um die im CPS erhobenen Daten direkt darstellt. Diese Anwendung ist in der Lage generische multidimensionale Daten in Echtzeit interaktiv darzustellen und bietet somit eine hervorragende Möglichkeit für erste visuelle Analyseschritte. Das erarbeitete System wurde in der Fachzeitschrift Computer Graphics Forum, dem führenden europäischen Visualisierungsjournal, veröffentlicht. Im Rahmen der Evaluierung wurden die Daten des CPS live dargestellt und in Diskussion mit dem Publikum diskutiert. Das CPS wurde durch die weiteren direkt vor Ort und in entfernten Laboren betriebenen Demonstratoren und Sensoren gebildet.

[bibtex key=Grottel2014HDTraj]
DOI: 10.1111/cgf.12352

Diese Visualisierung wurde als Plugin für das Visualisierungssystem MegaMol realisiert. Der Quellcode dieses Plugins kann frei hier heruntergeladen und entsprechend der beigelegten Lizenz verwendet werden:

hdtraj.mmplugin.ziphdtraj.mmplugin.zip Multi-Dimensional Trajectory Visualization MegaMol Plugin
[99.7 KB; MD5: 0a6eaf465318b0f256ecfdf8a8b4ad50; Mehr Info]

Um das MegaMol-System und das Plugin zu kompilieren, nutzen Sie die entsprechenden Anleitungen auf der MegaMol-Webseite.The ESF-funded junior research group VICCI dealt from 2012 until the end of 2014 with the development, control and integration of cyber physical systems (CPS) at the Faculty of Computer Science of the Dresden University of Technology. The scope includes smart home environments and supporting people in the ambient assisted living.

My work package for visualization and visual analysis has within the project investigated three essential aspects and corresponding solutions:

  • visual analysis of complex, multi-dimensional, multimodal, dynamic space-time data,
  • visualization in heterogeneous, mobile and distributed IT infrastructure, and
  • implementation of visualization systems and components.

Today I am writing about the visual analysis of complex space-time data.

teaser

Visual analysis serves as administrative overview of a current CPS, mainly for security reasons, as assistance during development, and the operation of the system. Particularly interesting are out-of-the-ordinary (erroneous) behavior and the formation of emergent system properties. For this a visual exploration with minimal previous assumptions is necessary. For example, certain data, like forces acting upon joints of a robot arm, be visualized more effectively by representations in geometrical context. This assumption however reduced the generality of visualization.

I thus developed a corresponding visualization of data collected by the CPS using coordinated views of continuous-time scatter plots, continuous-time parallel coordinate plots and temporal heatmaps. This application is capable of interactive real-time representation of generic multi-dimensional data and offers the means for a visual analysis. The developed system was published in the journal Computer Graphics Forum, the leading European Journal on Visualization. In the context of the evaluation, live data from our laboratory CPS war visualized, presented and discussed with a broad audience.

[bibtex key=Grottel2014HDTraj]

DOI: 10.1111/cgf.12352

This visualization was implemented as a plugin for the MegaMol visualization system. The source code can be downloaded freely and can be used according to the enclosed License:

hdtraj.mmplugin.ziphdtraj.mmplugin.zip Multi-Dimensional Trajectory Visualization MegaMol Plugin
[99.7 KB; MD5: 0a6eaf465318b0f256ecfdf8a8b4ad50; Mehr Info]

To compile the MegaMol system and the plugin, use the appropriate Instructions on the MegaMol website.

Veröffentlicht am Keine Kommentare Veröffentlicht in Forschung & Lehre Tagged with , ,

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

Next week the SIGGRAPH ASIA 2014 finally takes place in Shenzhen, China. I am prepared and looking forward to a great conference and to the opportunity to present my work: Technical Papers – Special Session: Visualization, Thursday, 4th December; 11:00 o’clock.

Veröffentlicht am Keine Kommentare Veröffentlicht in Forschung & Lehre Tagged with

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.

MegaMol-Highlevel-ArchitectureTatsä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.

configurator2MegaMol-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!

I like working with Software. I have fun handling large data sets and producing interactive 3D visualizations which are useful, nice and cool. On the way to create them I, of course, need a huge lot of functions, libraries and services. It is a painful fight till all those parts fit nicely together. But, I would be lying if I would say that this fight is not part of the fun. It is great seeing the parts from different persons matching together to a working whole. In my current projects source code combines from colleagues from Dresden, ex-colleagues from Stuttgart, my student assistants and my advised students.

However, the real pain are the interfaces and the stability of those parts. Of course, you could swap the implementation of anything behind a good interfaces without influencing the rest of the system. But, someone needs to show me a good interface, yet! I haven’t seen one without its problems, and I have seen many. The continuous development get increasingly difficult with each component added. Especially if there is no overseeing architect.

MegaMol-Highlevel-ArchitectureAs a matter of fact, MegaMol is currently exactly on that way down. It is actively used in Stuttgart and Dresden. I, of course, want to foster and extend that process. After all, MegaMol is my project and I am proud of it. But, the larger it gets and the more it is used, the harder it gets to continue the development. Several fundamental problems can only be solved with fundamental changes. These will bring displeasure. And I am not sure how to handle the necessary work load. On the one hand I am reducing my active development to act more like a director of the future development. On the other hand, the actual development is passed from one Ph.D. student to the next, like a scapegoat. This, of course, does not help. I am really not sure how to solve this.

configurator2MegaMol Modul Graph (10.1109/TVCG.2012.282)

But, I have my plans. “Partitioning”! And I know exactly which parts need to have my priority and which are critical. The main problems, however, are the interfaces in between. Those are far from being clean and therefore the whole current partitioning is in vain. The first tries to solve that were … semi-successful. But, I don’t even think of quitting!

Veröffentlicht am Keine Kommentare Veröffentlicht in Forschung & Lehre Tagged with

[:de]Heute gibt es auch nur eine kurze Notiz zum Thema MegaMol.

Es ist vollbracht! Das System Paper zu MegaMol selbst ist veröffentlicht:

[bibtex key=grottel2014megamol]
Doi: 10.1109/TVCG.2014.2350479

Die harte Arbeit hat sich gelohnt. MegaMol ist damit nun im IEEE Journal „Transactions on Visualization and Computer Graphics“, kurz TVCG, veröffentlich, dem Top-Journal in der Visualisierungs-Community. Ich muss zugeben, ich bin schon ziemlich stolz drauf.

Mal sehen wie es jetzt weiter geht. An sich wäre es schon möglich und gut MegaMol nun tatsächlich weiter zu bringen und zu pflegen als bisher. Ich würde das gerne machen. Aber natürlich hängt es von meiner beruflichen Zukunft ab in wie weit ich das können werde. Die Software hat so viel Potential. *hach*[:en]Today, I am only writing a short note on MegaMol.

We have done it! We published the MegaMol system as systems paper:

[bibtex key=grottel2014megamol]
Doi: 10.1109/TVCG.2014.2350479

All the hard work really paid off. MegaMol has now been published in the IEEE Journal “Transactions on Visualization and Computer Graphics”, in short TVCG. That is the top journal of the visualization community. I have to admit, I am pretty proud.

And I am curious what will come next. I would like to continue working with MegaMol, and to help to evolve the software even further. But, of course, this depends on my future employment. MegaMol has such a potential. *sigh*[:]

Veröffentlicht am Keine Kommentare Veröffentlicht in Forschung & Lehre Tagged with ,