<note tip>In eigener Sache: Die Liste der Fragen ist noch klein. Jeder, der eine Frage (zur Toolbox) hat, die hier nicht beantwortet wird, kann mir gerne eine entsprechende Email schreiben. Ich werde mich dann bemühen, zusammen mit einer Lösung auch einen entsprechenden Eintrag auf dieser Seite zu erstellen.</note>

Das ist vielleicht eine der häufigsten (un)gestellten Fragen. Die einfache Antwort: Bislang war die Codebasis zu uneinheitlich, um die Toolbox tatsächlich einer breiteren Öffentlichkeit zugänglich zu machen, schon gar mit dem Wissen, daß sie komplett neu geschrieben würde, im Hintergrund.

Diese Situation wird sich allerdings in Kürze (wohl im ersten Halbjahr 2012) mit der Freigabe der Version 0.3 ändern. Dann wird es auch einen offiziellen Link zum Herunterladen geben.

Kurz: Ja, alle datenverarbeitenden Routinen sind vollständig von der GUI getrennt.

Die gute Nachricht für alle Freunde der Kommandozeile und maximaler Kontrolle über ihre Datenverarbeitung/manipulation: Die neue GUI (ab Version 0.3 der Toolbox) führt die strikte Trennung von GUI und verarbeitenden Funktionen ein. Alle Funktionen, die eine Operation auf einem Datensatz durchführen, können selbstverständlich auch von der Kommandozeile aus aufgerufen werden.

Das Ziel der Neuimplementation der Toolbox ist nicht nur die Vereinheitlichung des Codes, sondern auch der Schnittstellen der einzelnen Routinen. Können einer Routine mehrere Parameter übergeben werden, wird das in aller Regel in Form einer Matlab-Struktur („struct“) erfolgen. Die GUI stellt deshalb (am Ende) eine komfortable Möglichkeit dar, die entsprechenden Routinen aufzurufen.

Durch die von der GUI mitgeschriebene Historie jedes Datensatzes ist aber auch jederzeit die volle Kontrolle und der vollständige Überblick darüber gewahrt, was mit einem einzelnen Datensatz gemacht wurde.

Immer wieder taucht die Frage auf: Warum und wozu eigentlich eine GUI? Die Frage wird meist von Menschen gestellt, die auf der Kommandozeile zuhause sind und gerne die volle Kontrolle über alles haben, was sie mit ihren Daten anstellen. Da die Frage aus zwei Teilen (Grund und Zweck) besteht, soll sie entsprechend beantwortet werden.

Es gibt tatsächlich Menschen, die gerne mit einer grafischen Oberfläche arbeiten und nicht alles per Hand auf der Kommandozeile machen wollen. Hinzu kommt, daß eine GUI oft einen intuitiveren Zugang zu den Funktionen einer Toolbox/Funktionssammlung liefert, als eine bloße Sammlung von Routinen ohne umfassende Dokumentation.

Kurz: Um es einer Person, die transiente Spektren mißt, leicht zu machen, die gemessenen Daten schnell und komfortabel darzustellen, vorzuverarbeiten und Abbildungen einzelner Spektren (oder kompletter Datensätze) zu erzeugen.

Zielgruppe sind u.a. Studenten, die zum ersten Mal mit der transienten EPR konfrontiert werden, aber nicht die Zeit haben, sich selbst in die Vorverarbeitung transienter EPR-Spektren einzuarbeiten, noch sich eigene Routinen für die Handhabung der Rohdaten zu schreiben.

Entsprechend ist (zumindest momentan) die Zielstellung der weiteren Entwicklung der GUI (und der Toolbox) die Bereitstellung all der Funktionen, die im Rahmen der Anwendung innerhalb z.B. einer Bachelor- oder Masterarbeit routinemäßig anfallen, inklusive der einfachen Erstellung von Abbildungen (die sich dann in Programmen wie Adobe Illustrator oder Inkscape weiterverarbeiten lassen).

Aus eigenem Interesse beider Seiten: Je aussagekräftiger ein Fehlerbericht ist, desto einfacher ist es für den Programmierer, das Problem nachzuvollziehen (und ggf. selbst nachzustellen) und in der Folge dann auch zu beheben. Je schneller (und aufgrund der ihm zur Verfügung stehenden Information einfacher) aber der Programmierer das Problem eingrenzen kann, desto schneller kann er es beheben. Ganz abgesehen davon, daß ein ordentlicher Fehlerbericht die Motivation, das Problem zu beheben, steigert bzw. bei einem Erkennen des Problems schon aus der Fehlerausgabe von MATLAB® die Lösung oftmals in vorhersehbar geringer Zeit möglich ist, was es dann einfacher macht, derlei Dinge kurz „zwischenzuschieben“.

Also, was braucht es zu einem brauchbaren Fehlerbericht? Eine kleine Checkliste:

• Eine kurze Beschreibung, was gerade gemacht/versucht wurde, als der Fehler auftrat (z.B.: Spektren laden, speichern, akkumulieren, …)
• Die Fehlerausgabe von MATLAB®, also das, was MATLAB® auf der Konsole ausgibt (meist in roter Schrift)
  • Sollte der Fehler keinerlei Fehlerausgabe produzieren, wäre mir eine möglichst detaillierte Beschreibung wichtig. Details dazu weiter unten.
• Die gerade verwendete Version der Toolbox (→ trEPRinfo)

Die ersten beiden Punkte sind unumgänglich, der dritte (Version der Toolbox) ist dann wichtig, wenn ich nicht aus aktuellen Gründen gerade sowieso weiß, welche Version dort läuft (und es sich gar gerade um eine „inoffizielle“ Entwicklerversion handelt).

wenn der begründete Verdacht besteht, daß das Problem entweder betriebssystem- oder MATLAB®-versionsabhängig sein könnte, wären folgende Angaben hilfreich:

• Verwendetes Betriebssystem
• Verwendete Version von MATLAB®

Wenn MATLAB® keinen Fehler auf der Konsole auswirft, dann wäre ich an einer möglichst detaillierten Beschreibung des Vorganges interessiert, der den Fehler produziert hat.

Sollten beim Einlesen von Daten Fehler auftreten, wäre ich über eine Beispieldatei (der „Kopf“ der Datei mit einem Kommentarkopf und den ersten Zeilen Daten reicht) glücklich, es sei denn, es handelt sich um ein mir bekanntes Format¹⁾. Es gibt eine Liste von Dateiformaten, mit der die Toolbox umgehen kann. Im letzteren Fall reicht die Nennung des Formates.

<note tip>Mittlerweile gibt's für Bug Reports eine Bugverwaltung (BugZilla), wo direkt für die Toolbox Bugs eingetragen werden können.
Bitte beim Bug berichten mindestens die jeweilige Komponente und Toolboxversion auswählen.</note>

Diese Frage ist schnell beantwortet: Weil sie (noch) lausig programmiert ist. Entstanden ist das Ganze als Sammlung von Skripten und Funktionen zum Eigengebrauch, und wie das so ist, wußte ich ja, was ich wollte. Entsprechend sind die Fehlerabfragen noch deutlich unzureichend und vieles unintuitiv. Abgesehen davon, daß die ganze Toolbox an einigen Stellen ziemlich lausig programmiert ist. Zwar gab und gibt es Ansätze, das zu ändern, aber die sind sehr davon abhängig, wieviel Zeit ich gerade habe.

Einfachste Lösung: Email mit einer möglichst detaillierten Problembeschreibung an mich schicken (Emailadresse im Impressum) - ich versuche dann, mich darum zu kümmern.

Manchmal ist es gerade für Debugzwecke sehr nützlich, an die internen Daten der GUI heranzukommen. Geht da aus irgendwelchen Gründen nämlich etwas schief, gibt es die Möglichkeit²⁾, das geradezubiegen und die GUI anschließend zum Weiterarbeiten zu bewegen.

Hier also eine Anleitung, wie man an die internen Daten der GUI herankommt, sie modifiziert und anschließend zurückschreibt. Erst einmal braucht man dazu das „Handle“ der GUI. Entweder man hat das noch vom Aufruf der GUI:

h = trEPR;

oder man muß es sich besorgen:

h = findall(0,'Title','trEPR toolbox : main window');

<note tip>Mit der momentanen Entwicklerversion der Toolbox (0.3.0beta) ist der zweite Schritt nicht notwendig. Wichtig: Der Befehl zum Aufruf der Toolbox lautet trEPRgui. Um an das handle zu gelangen, kann man einfach h=trEPRgui aufrufen, auch wenn die GUI bereits geöffnet ist.</note>

Dann kann man sich die „appdata“ der GUI besorgen:

ad = getappdata(h);

Die Struktur ist anderweitig etwas genauer beschrieben, man kann sich da dann beliebig „durchhangeln“ und die Einträge ändern (auf eigenes Risiko!).

Anschließend dann die „appdata“ wieder zurückschreiben (Achtung: Das muß für jeden „Teil“ der „appdata“ einzeln geschehen):

setappdata(h,'data',ad.data);
setappdata(h,'control',ad.control);

Dann sollten die neuen Daten in der GUI sein. Wenn man anzeigerelevante Einträge geändert hat, wird das erst beim nächsten Vorgang in der GUI, der die Anzeige auffrischt, berücksichtigt.

Beim „SpekSim“-Format handelt es sich um das Format, in dem das transiente Spektrometer in Freiburg seine Daten speichert. Grundsätzlich handelt es sich dabei um ein Textformat (wenngleich die Spektrometersoftware auch Binärdateien schreiben kann, die aber momentan nicht von der Toolbox gelesen werden können), das aus vier Spalten³⁾ und einem Dateikopf von fünf Zeilen besteht. Allgemein sieht eine solche Datei, wenn man sie mit einem Texteditor öffnet, also wie folgt aus:

Source : transient; Time : Mi Jul 4 19:14:50 2007
B0 = 12000.000000 Gauss, mw = 34.076301 GHz
 beliebiger Kommentar des Messenden...
1 4501 -1.001e-06 7.999e-06 0 0
s                        V                                                 
-0.000390625     -0.000476074     -0.00098877     -0.00115967     
-0.000756836     -0.00109863     -0.00125732     -0.00113525     

Grundsätzlich gibt es mehrere Möglichkeiten, mit diesen Dateien in der trEPR-Toolbox zu arbeiten, je nach Kontext und Zielstellung:

• GUI
  • Die GUI sollte grundsätzlich mit dem Dateiformat umgehen können. Wenn man vor dem Laden von Dateien in der Box für das Zusammenfügen mehrerer Dateien („combine“) ein Häkchen setzt, sollte sie das hinbekommen und die einzelnen Dateien beim Einlesen zu einem Datensatz zusammenfügen.
• Konsole
  • Diese Dateien können entweder über „trEPRload“ oder über „trEPRspeksimLoad“ eingelesen werden.

<note important>Die in der TREPR-Toolbox vorhandene Funktion trEPRspeksimLoad (die u.a. auch von trEPRload aufgerufen wird), hatte einen kritischen Fehler (alle Versionen < 0.2.3b), der das Einlesen dieser Daten unmöglich machte bzw. fehlerhaft durchführte.</note>

Ein zweites ebenfalls in Freiburg gebräuchliches Format ist sehr ähnlich aufgebaut und ist das Ergebnis des ersten Verarbeitungsschrittes (mit speman und Darstellung in GnuPlot). Grundsätzlich ist das ebenfalls ein Textformat, diesmal mit zwei Spalten, der ersten für die Zeitachse, der zweiten für die Intensitäten. Dazu kommen noch am Kopf drei Kommentarzeilen (mit „#“ eingeleitet). Grundsätzlich sieht eine solche Datei also wie folgt aus, wenn man sie mit einem Texteditor öffnet:

# Source : transient; Time : Tue Sep 28 12:58:26 2010 
# B0 = 2580.000000 Gauss, mw = 9.668968 GHz 
# beliebiger Kommentar des Messenden...
-2.00199997e-06 -0.000412524788 
-1.99799997e-06 -0.000528490788 
-1.99399997e-06 -0.000412524788 

Grundsätzlich gibt es mehrere Möglichkeiten, mit diesen Dateien in der trEPR-Toolbox zu arbeiten, je nach Kontext und Zielstellung:

• GUI
  • Die GUI sollte grundsätzlich mit dem Dateiformat umgehen können. Wenn man vor dem Laden von Dateien in der Box für das Zusammenfügen mehrerer Dateien („combine“) ein Häkchen setzt, sollte sie das hinbekommen und die einzelnen Dateien beim Einlesen zu einem Datensatz zusammenfügen.
• Konsole
  • Diese Dateien können entweder über „trEPRload“ oder über „trEPRgnuplotLoad“ eingelesen werden.

<note important>Die in der TREPR-Toolbox vorhandene Funktion trEPRgnuplotLoad (die u.a. auch von trEPRload aufgerufen wird), hatte einen Fehler (alle Versionen < 0.2.3b), der das Einlesen dieser Daten teilweise unmöglich machte.</note>

Kurz: Nein, die GUI folgt dem sogenannten „singleton“-Konzept und erlaubt immer nur eine Instanz pro Matlab-Instanz.

Es gibt eigentlich keinen Grund, mehrere GUI-Fenster (Hauptfenster) gleichzeitig geöffnet zu haben. Die Idee der GUI ist ja gerade, den einfachen und komfortablen Vergleich mehrerer Datensätze zu ermöglichen.

Die GUI ist in der Tat genau so programmiert, daß das mehrfache Öffnen des GUI-Fensters verhindert wird. Anderenfalls verlöre ein Anwender schnell den Überblick über die Fenster, und aufgrund des doch relativ hohen Speicherverbrauches von GUIs in Matlab wäre das System zusätzlich belastet. Die Routine zum Öffnen des GUI-Hauptfensters (und adäquat für die Unterfenster) fragt deshalb ganz zu Beginn ab, ob bereits ein identisches Fenster in Matlab geöffnet ist, und holt dieses in diesem Fall in den Vordergrund (sogenanntes „singleton“-Konzept).

Natürlich könnte man grundsätzlich versuchen, mehr als eine Matlab-Instanz auf demselben Rechner zu starten und in diesen dann jeweils die GUI der Toolbox zu öffnen, aber wie gesagt gibt es keinen offensichtlichen Grund, warum man das tun wollte.

Diese Frage betrifft die neue, seit Mai 2011 in Entwicklung befindliche GUI.

Problembeschreibung: Es wurden verschiedene Datensätze geladen und in die Liste der sichtbaren Datensätze verschoben, aber die Anzeige scheint nicht zu funktionieren.

Erklärung: Lädt man Datensätze mit stark unterschiedlichen Dimensionen, dann kann es vorkommen, daß die unterschiedlichen Anzeigemodi („2D“, „1D along x“, „1D along y“) nichts anzeigen bzw. die gesamte Anzeige nicht zu funktionieren scheint. Das liegt daran, daß die GUI normalerweise so eingestellt ist, daß sie die Achsengrenzen automatisch setzt, und zwar für die Gesamtheit der aktuell sichtbaren Datensätze.

Lösung: Um die Achsengrenzen auf den jeweils aktiven Datensatz zu setzen, muß die Einstellung, die Achsenlimits automatisch zu setzen, abgeschaltet werden. Das geht ganz einfach über die Einstellungen für die Achsengrenzen („axis limits“) in den Anzeigeoptionen („Display“, „page 1“): Einfach den Haken bei „determine automatically“ entfernen.

Grundsätzlich: Die Versionsnummern der trEPR-Toolbox lehnen sich an die Tradition anderer Projekte aus der freien Softwareentwicklung an, die ebenfalls lange brauchen, bis sie eine Version „1.0“ erreichen - oder das auch nie tun (gute Beispiele sind BIBTeX oder inkscape).

Momentan ist die Codebasis der Toolbox noch weit davon entfernt, „stabil“ und „konsistent“ genannt zu werden. Deshalb wird es wohl noch lange dauern, bis es eine Version gibt, die der „1“ nahekommt.

Eine ursprüngliche Planung sah vor, als Version „1.0“ die komplette Neuimplementation in C++ oder einer ähnlichen Programmiersprache zu unternehmen und damit von Matlab und allen anderen kommerziellen und nicht frei verfügbaren Programmen unabhängig zu werden. Dieses Ziel wird aber vermutlich nie erreicht werden.