<note tip>In eigener Sache: Die Liste der Fragen ist noch klein. Jeder, der eine Frage (zum Modul) 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>

Die kurze Antwort: Um dem Nutzer eine einfache und komfortable Möglichkeit zu bieten, spinpolarisierte EPR-Spektren von Triplett-Zuständen sowohl zu simulieren als auch zu fitten.

Die ausführliche Antwort: Ausgangspunkt war eine Sammlung von Matlab®-Funktionen aus dem Jahr 2005, die ein studentischer Mitarbeiter geschrieben hatte. Diese Routinen fragten über eine textbasierte Schnittstelle (CLI) alle für einen Fit von Triplett-Spektren notwendigen Parameter vom Nutzer ab und starteten dann den eigentlichen Fit. Diese Funktionen waren in die Jahre gekommen und ungepflegt, u.a. gab es Routinen gar nicht mehr, auf denen sie aufbauten. Eine Überarbeitung war also zwingende Voraussetzung für die Nutzung.

Da mit der trEPR-Toolbox mittlerweile eine halbwegs stabile Toolbox zur Handhabung transienter EPR-Spektren zur Verfügung steht und erste Erfahrungen mit der Erweiterung dieser Toolbox durch Module ebenfalls existiert, war die Überführung der alten Routinen in ein Modul für die trEPR-Toolbox naheliegend.

Durch die komplette Überarbeitung der Nutzerschnittstelle (aktuell – Stand 10/2013 – lediglich eine textbasierte Schnittstelle, CLI) und den weitgehend modularen Aufbau sowie die Entwicklung einiger Schlüsselkonzepte ist ein Prototyp für Simulations- und Fitaufgaben im Allgemeinen entstanden.

Welche Vorteile bietet die Verwendung des trEPRTSim-Moduls? Letztlich kann ich doch gleich die Funktion pepper aus der EasySpin-Toolbox aufrufen.

Die kurze Antwort: Weil das trEPRTSim-Modul eine komfortable Schnittstelle bietet, zum Einlesen von Daten auf die trEPR-Toolbox zurückgreift und weil es eine komplette Historie der Simulations- und Fitdurchläufe schreibt, die (Stand 2013/10: künftig) in komfortablen Berichten zusammengefaßt werden.

Die ausführliche Antwort: Tatsächlich könnte man momentan das trEPRTSim-Modul auf eine recht aufwendige „Verpackung“ eines einzelnen Aufrufs der Funktion pepper aus der EasySpin-Toolbox reduzieren. Allerdings wird das dem Modul nicht gerecht und verstellt den Blick auf die Vorzüge der entwickelten Schlüsselkonzepte. Die wichtigsten dieser Schlüsselkonzepte seien hier kurz aufgeführt:

• Datenimport über die trEPR-Toolbox
  Alle Datenformate, die die trEPR-Toolbox „versteht“, können innerhalb des trEPRTSim-Moduls verwendet werden.
• Datensatz als kleinste Einheit
  Alle Routinen operieren direkt auf Datensätzen (im Format der trEPR-Toolbox). Das ermöglicht es dem (fortgeschrittenen) Nutzer, auch ohne die zur Verfügung gestellte textbasierte Schnittstelle Simulations- und Fitaufgaben einfach und komfortabel durchzuführen.
• Historie
  Alle Simulations- und Fitvorgänge werden im Datensatz selbst dokumentiert. Daraus lassen sich dann Berichte erstellen, aus denen detailliert hervorgeht, was gemacht wurde.

Aus eigener (leidvoller) Erfahrung ist gerade die automatische Erstellung einer Historie ein zentraler Vorteil des Moduls. Gerade bei vielen kleinen Änderungen in Simulationen gibt es wohl nur wenige Nutzer, die alle Parameter immer konsequent in ihrem Laborbuch oder anderweitig dokumentieren.

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 des Moduls (→ trEPRTSiminfo)

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 das Modul Bugs eingetragen werden können.
Bitte beim Bug berichten mindestens die jeweilige Komponente und Modulversion auswählen.</note>

Ein Wort zur Sprache bei Bug Reports mit BugZilla: Im Hinblick auf einen weiteren Nutzerkreis ist es kein Fehler, Bug Reports auf Englisch zu schreiben. Grundsätzlich gilt aber: Lieber einen Bug Report auf Deutsch schreiben, als keinen Report zu schreiben. Die Sprache sollte niemanden daran hindern, Bugs zu berichten. Lieber auf Deutsch einen ausführlicheren Bericht schreiben als auf Englisch keinen oder einen nicht eindeutigen.