Rechenläufe automatisieren: wann sich der Aufwand lohnt

Eine Parameterstudie mit vielen Varianten läuft über Nacht. Am nächsten Morgen ist der größte Teil durch, einzelne Läufe sind abgestürzt, und niemand weiß warum. Also startet man sie neu, wartet wieder, und am Nachmittag beginnt die Auswertung von Hand.

Wer Rechenläufe automatisieren will, hat genau diesen Zustand vor Augen.

Es gelingt nicht immer, und die Frage, wann es gelingt, wird selten gestellt.

Die Rechnung, die vorher fällig ist

Automatisierung kostet einmal Zeit und spart danach jedes Mal.

Dafür braucht man drei Größen: wie lange der Vorgang von Hand dauert, ehrlich gemessen; wie oft im Jahr er anfällt; und wie lange es dauert, ihn zu automatisieren.

Der Fehler steckt meistens in der ersten Größe.

Geschätzt dauert die Auswertung einen Bruchteil dessen, was eine ehrliche Messung ergibt, weil das Suchen der Dateien, das Öffnen der Vorlage und das mehrfache Nachrechnen mitzählen.

Diese Verzerrung ist gut untersucht. Menschen unterschätzen die Dauer der eigenen Vorhaben, während sie die Dauer fremder Vorhaben durchaus realistisch einschätzen. Der Grund liegt darin, dass die Schätzung am Plan für den kommenden Durchlauf hängt, während vergleichbare frühere Fälle unberücksichtigt bleiben.

In derselben Untersuchung verschwand die Verzerrung, sobald die Beteiligten angewiesen wurden, frühere Fälle heranzuziehen. Genau das leistet eine Messung: Sie ersetzt den Plan durch Erfahrung.

Die zweite Größe wirkt harmlos. Gezählt wird meist die geplante Häufigkeit, während die Wiederholungen nach einer geänderten Randbedingung unter den Tisch fallen. Gerade sie vervielfachen den Vorgang in der Praxis, und gerade sie sprechen für das Skript.

Der zweite Fehler steckt in der dritten Größe.

Ein Skript, das nur den Normalfall abdeckt, ist schnell geschrieben. Eines, das auch mit einem abgestürzten Lauf, einer halb geschriebenen Datei und abweichenden Ordnerstrukturen umgeht, kostet ein Vielfaches davon.

Wer die erste Größe zu klein ansetzt und die dritte ebenfalls, bekommt eine Rechnung, die auf dem Papier immer aufgeht.

Was zuerst automatisiert gehört

Ein Rechenlauf läuft ohnehin allein, sobald er gestartet ist.

Was Zeit frisst, ist das, was davor und danach passiert: Varianten aufsetzen, Ergebnisse einsammeln, Kennwerte herausziehen, in eine vergleichbare Form bringen.

Deshalb lohnt der erste Schritt fast immer bei der Auswertung der Parameterstudie. Sie fällt jedes Mal wieder an, unabhängig davon, welches Modell gerechnet wurde. Wer die Simulationsauswertung automatisieren will, fängt bei den Kennwerten an, die am Ende in der Tabelle stehen sollen. Ein Skript, das pro Variante eine Zeile schreibt, mit den Kennwerten in festen Spalten und dem Namen des Laufs als Schlüssel, bleibt schlank und ist nicht an ein einzelnes Modell gebunden. Voraussetzung ist, dass Ordner und Dateien einer Regel folgen, die auch derjenige einhält, der die Studie später fortsetzt.

Der Punkt, an dem die meisten Skripte scheitern

Ein Skript für Rechenläufe, das eine ganze Serie startet, muss wissen, was zu tun ist, wenn ein Lauf mittendrin abstürzt.

Die Möglichkeiten sind abbrechen, überspringen, wiederholen. Dazu kommt das geordnete Auslaufen, bei dem die bereits gestarteten Läufe zu Ende gerechnet und keine neuen mehr angestoßen werden.

Jede der vier Möglichkeiten hat ihren Fall. Wiederholen passt bei sporadischen Fehlern der Rechenumgebung, wenn ein Knoten wegbricht, die Platte volläuft oder die Lizenz belegt ist. Überspringen passt, wenn einzelne Varianten erwartbar nicht konvergieren und die Serie trotzdem vergleichbar bleibt. Abbrechen passt bei Fehlern in Modell oder Eingabe, weil dann alle Folgeläufe denselben Fehler tragen. Das geordnete Auslaufen passt, wenn die Serie verworfen wird, laufende Rechnungen aber teuer sind.

Genau deshalb gehört die Entscheidung in eine Konfiguration und nicht fest ins Skript. Nextflow hält es so: Der Umgang mit dem Fehlerfall ist dort eine Einstellung mit genau diesen Werten, und voreingestellt ist der sofortige Abbruch.

Wichtiger noch: Ein abgestürzter Lauf muss erkennbar abgestürzt sein.

Ein Solver, der eine unvollständige Ergebnisdatei hinterlässt, sieht für ein naives Skript aus wie ein erfolgreicher Lauf.

Die Auswertung liest dann Zahlen, die nichts bedeuten, und niemand merkt es, weil die Zahlen plausibel aussehen.

Die Prüfung gehört deshalb vor die Auswertung: Ist die Datei vollständig, steht die Abschlussmeldung des Solvers darin, stimmt die Anzahl der Zeitschritte.

Auch dafür gibt es Vorbilder. In Snakemake ist der unvollständige Lauf ein eigener, benannter Zustand, für den ein eigener Aufruf zum erneuten Rechnen bereitsteht. Wer das nachbaut, braucht dafür wenig: eine Datei, in der pro Lauf steht, ob er sauber beendet wurde.

Drei Fälle, in denen man es lassen sollte

Der Vorgang fällt nur wenige Male im Jahr an.

Dann ist die eingesparte Zeit kleiner als die Pflege.

Skripte veralten: Der Solver bekommt eine neue Version, das Ausgabeformat ändert sich, und dann sitzt man an einem Skript, das man seit Monaten nicht angefasst hat.

Der Vorgang ändert sich jedes Mal. Automatisieren lohnt sich für Wiederholung; Ähnlichkeit genügt dafür nicht.

Nur ein Einziger versteht das Skript.

Dann ist es eine Abhängigkeit, die spätestens beim nächsten Bearbeiterwechsel sichtbar wird.

Was daraus folgt

Die gemessene Dauer, multipliziert mit der ehrlichen Häufigkeit im Jahr, ergibt die Ersparnis. Ihr gegenüber steht der Aufwand für das Skript, und zwar einschließlich der Fehlerbehandlung. Bleibt die Ersparnis eines Jahres unter diesem Aufwand, trägt die Automatisierung sich noch nicht.

Im laufenden Betrieb erkennt man den Umschlagpunkt daran, dass vor jedem Einsatz zuerst das Skript angepasst wird: an ein neues Ausgabeformat, an eine geänderte Ordnerstruktur, an eine neue Version des Solvers. Wer das mehrfach hintereinander erlebt, pflegt ein Skript, das mehr kostet, als es spart.

Quellen

Quellen zuletzt geprüft am 25. August 2026.

• Exploring the „Planning Fallacy“: Why People Underestimate Their Task Completion Times, Journal of Personality and Social Psychology 1994, Vol. 67, No. 3, S. 366–381. Daher stammt der Befund zur ersten Größe: „People underestimate their own but not others‘ completion times“, und die Ursache: „people focus on plan-based scenarios rather than on relevant past experiences“. Studie 4 zeigt: Wer angewiesen wird, frühere Fälle heranzuziehen, schätzt realistisch. web.mit.edu, Journal of Personality and Social Psychology 1994, Vol. 67, No. 3 (PDF)

• Nextflow: errorStrategy, Seqera Docs. Die Möglichkeiten aus dem Beitrag sind dort genau die Einstellwerte: terminate („terminate the pipeline immediately“, Voreinstellung), ignore („ignore it and continue the pipeline execution“), retry („retry it“), dazu finish für das geordnete Auslaufen. Sie stehen in der Konfiguration und nicht im Skript. docs.seqera.io, errorStrategy

• Snakemake: Command line interface, Fassung 9.25.2. Dort ist der unvollständige Lauf ein eigener, benannter Zustand und kein gewöhnliches Ergebnis: –rerun-incomplete heißt „Re-run all jobs the output of which is recognized as incomplete.“ snakemake.readthedocs.io, CLI

Ohne Quellenbeleg, aus eigener Erfahrung mit eigenen Läufen: der Solver, der eine unvollständige Ergebnisdatei hinterlässt und dabei wie ein Erfolg aussieht, die drei Gründe gegen das Automatisieren und der Satz zum Skript, das nur einer versteht.