Reading Time: 11 minutes
  • Jupyter-Notebooks werden nur ~ 12,4% der Fälle erfolgreich ausgeführt, wenn Abhängigkeiten deklariert werden. Explicit Environment Management schließt diese Lücke
  • Das Fünf-Säulen-Framework von Ziemann et al. (2023) bietet eine strukturierte Basislinie für Dokumentation, Versionskontrolle, Umgebungsmanagement, Datenaustausch und faire Einhaltung
  • Die Repro-Checkliste (Hornung et al., 2026) bietet ein praktisches Self-Audit-Tool für Ordnerstruktur, Umgebungsspezifikation, Datenverfügbarkeit und deterministische Ausführung
  • Häufige Fallstricke wie absolute Pfade, unspezifische Abhängigkeiten und fehlende Readmes sind die Hauptursachen für Reproduzierbarkeitsfehler in der Computerforschung
  • Ein Schritt-für-Schritt-Workflow vom Simulationsdesign über Notebook-Dokumentation, Code-Archivierung und Journal-Einreichung bietet eine wiederholbare Produktionspipeline

Die Reproduzierbarkeitslücke in der Computerforschung

Wenn Sie ein simulationsbasiertes Papier einreichen, überprüfen die Prüfer Ihre Methodik, Randbedingungen, Konvergenzstudien und den Vergleich mit analytischen Benchmarks. Aber sie führen Ihren Code selten erneut aus. Die in Ihren Abbildungen und Tabellen dargestellten Ergebnisse werden zum veröffentlichten Datensatz – und wenn diese Ergebnisse durch einen nicht reproduzierbaren Workflow generiert wurden, beruht die Publikation auf einer nicht überprüften Grundlage.

Dies ist kein theoretisches Problem. Samuel & Mietchen (2024) analysierte 15.817 Python-basierte Jupyter-Notebooks aus biomedizinischen Veröffentlichungen, die in PubMed Central indexiert wurden. Von den Notebooks, in denen alle deklarierten Abhängigkeiten erfolgreich installiert werden konnten, führten 87,6% zu Ausnahmen während der automatischen Wiederholung. Nur 1.203 Notebooks wurden fehlerfrei abgeschlossen – und von diesen ergaben 324 Ergebnisse, die sich von den ursprünglich gemeldeten Ausgaben unterschieden. Die restlichen 879 Notebooks lieferten identische Ergebnisse. Diese 5,56%ige Erfolgsquote bei identischer Reproduktion war tatsächlich eine Verbesserung gegenüber dem ersten Lauf im Jahr 2021 (5,88%), was darauf hinweist, dass die letzten Notebooks tendenziell etwas besser sind – aber die Lücke bleibt enorm.

Was erschwert Reproduzierbarkeit für Computerwissenschaftler? Sie arbeiten mit numerischen Solvern, Netzverfeinerungen, Zeitintegrationsschemata und Kopplungsstrategien, die durch Ketten von Gleitkomma-Operationen Outputs erzeugen. Ein einzelner Python-Versionsstoß, ein geänderter Standardparameter in numpy oder scipy oder ein relativer Pfad, der auf einem anderen Computer nicht aufgelöst wird, können jede Abbildung und Tabelle in Ihrem Papier ungültig machen. Das Problem besteht darin, dass Ihr Workflow eine adaptive Netzverfeinerung, benutzerdefinierte Quellbegriffe oder nicht triviale Randbedingungen umfasst – genau die Art von fortgeschrittenen Mustern, die in FIPY-Ressourcen auf dieser Site dokumentiert sind .

Fünf Säulen reproduzierbarer Computerforschung

Ziemann et al. (2023) formalisierten die Säulen der reproduzierenden Reproduzierbarkeit als Rahmen für die Dokumentation und den Austausch reproduzierbarer Workflows. Diese Säulen, die ursprünglich im Kontext der Bioinformatik entwickelt wurden, gelten jedoch gleichermaßen für materialwissenschaftliche Simulationen, computergestützte Fluiddynamik und finite-volumenbasierte PDE-Solver.

1. Programmierkenntnisse

Literate Programmierung bedeutet, Ihren rechnerischen Workflow als eine Erzählung zu dokumentieren, die Erklärungs- und ausführbaren Code verschachtelt. In den Computerwissenschaften manifestiert sich dies normalerweise als Jupyter-Notizbücher, R-Markdown-Dokumente oder Python-Skripte mit umfangreichen DocStrings und Inline-Kommentaren.

Das Ziel besteht nicht nur darin, eine reproduzierbare Datei zu erstellen, sondern ein Dokument zu erstellen, das ein mit Ihrer Analyse nicht vertrauter Leser verfolgen, verstehen und erneut ausführen kann. Samuel & Mietchen (2024) stellte fest, dass eine klare Korrelation zwischen dem Markdown-zu-Code-Zellen-Verhältnis und der erfolgreichen Reproduktion: Notebooks mit höherem Dokumentationsaufwand (mehr Markdown-Zellen relativ zu Codezellen) sich deutlich häufiger identisch mit der ursprünglichen Ausgabe reproduzieren.

Für eine Phasenfeldsimulation in FIPY – eine Einführung in die Kernarchitektur – oder ein Diffusionsmodell mit der Finite Volume-Methode könnte die literarische Programmierung wie folgt aussehen:

# Set deterministic seed
import numpy as np
np.random.seed(42)

# Build a structured grid (this should match the mesh description in your paper)
nx, ny = 100, 100
mesh = CellGrid([nx, ny], varIndex=1)

# Define the transient diffusion term and boundary conditions
T = CellVariable(name='Temperature', mesh=mesh, value=initial_temperature)
eqn = TransientTerm() == DiffusionTerm(coeff=thermal_conductivity)

# Impose Dirichlet boundary conditions (see also our guide on FiPy BCs)
T.fixLeft(value=300)
T.fixRight(value=500)

Wenn Sie diese Notebook-Zelle schreiben, dokumentieren Sie gleichzeitig die Netzauflösung, die PDE und die Randbedingungen – und führen die Simulation aus, die Ihre veröffentlichte Figur erzeugt hat.

Empfehlung: Wenn Ihr Notebook weniger Markdown-Zellen als Codezellen hat, sind Sie unterdokumentiert. Streben Sie mindestens ein Verhältnis von 1: 1 an und idealerweise mehr. Der Samuel & Die Mietchen-Studie ergab, dass die Gruppe mit identischer Reproduktion ein Markdown-to-Code-Verhältnis von 0,73 hatte, während die Gruppe mit unterschiedlicher Reproduktion nur 0,49 hatte.

2. Code-Versionskontrolle und -freigabe

Die Versionskontrolle ist für Arbeiten in Publikationsqualität nicht optional. Git bietet einen permanenten, abfragefähigen Verlauf jeder Codeänderung – und GitHub, GitLab oder Zenodo archivieren Ihr Repository als zitables Objekt mit einem DOI.

Der Zweck der Versionskontrolle ist zweifach:

  • Reproduzierbarkeit: Ein spezifischer Commit-Hash (abc1234) gepaart mit einem bestimmten Commit-Datum zeigt jedem genau an, welcher Code Ihre veröffentlichten Ergebnisse erzeugt hat.
  • Accountability: Jede Änderung des Parameters, jede Änderung des Quellenbegriffs, jede Bearbeitung der Randbedingung wird aufgezeichnet. Wenn ein Rezensent fragt: „Warum haben Sie diesen Diffusionskoeffizienten verwendet?“ Sie können auf den genauen Commit verweisen, an dem es festgelegt wurde.

Archivieren Sie beim Veröffentlichen Ihr Repository auf zenodo (oder GitHub mit aktivierter Zenodo-Integration) und fügen Sie das DOI in die Datenverfügbarkeitserklärung Ihres Manuskripts ein. Dies verwandelt Ihren Simulationscode in ein permanentes, zitierfähiges Artefakt. Viele Zeitschriften empfehlen jetzt, Code in Repositories mit DOI-Zuweisung zu hinterlegen – siehe JOSS Simulation Science Guidelines für Journalerwartungen zu simulationsbasierten Publikationen.

Entscheidungsregel: GitHub vs. Zenodo? Verwenden Sie GitHub für aktive Entwicklung und Zusammenarbeit. Verwenden Sie Zenodo für die Archivierung. Zenodo weist bei der Verknüpfung automatisch ein DOI zu GitHub-Repositories zu, wodurch es zur bevorzugten Wahl für die Veröffentlichung wird. Sie können ein Live-GitHub-Repository pflegen und das endgültige Commit auf Zenodo zur Einreichung archivieren.

3. Rechenumgebungssteuerung

Die Umgebungskontrolle ist die wichtigste technische Intervention, die Sie vornehmen können. Wenn ein Reviewer versucht, Ihre Ergebnisse auf einem neuen Computer zu reproduzieren, muss er den genauen Software-Stack kennen: Python-Version, Numpy-Version, FIPY-Version, Solver-Bibliotheken. Ohne diese Informationen rät der Rezensent – und das Vermuten erzeugt ModuleNotFoundError, ImportError und FileNotFoundError (die drei häufigsten Ausnahmen, die von Samuel & Mietchen identifiziert wurden und für 41,65% aller Ausführungen verantwortlich sind Ausfälle).

So erfassen Sie Ihre Umgebung:

# In Python, use the session-info package to export your environment
!pip install session-info
import session_info
session_info.show()

# Conda environment export (alternative)
conda env export > environment.yml

# pip requirements (for simpler projects)
pip freeze > requirements.txt

Entscheidungsregel: Conda vs. Pip vs. Docker? Für die meisten Computational Science Workflows in Python ist Conda die beste Balance zwischen Praktikabilität und Vollständigkeit. Es behandelt sowohl Python-Pakete als auch Nicht-Python-Abhängigkeiten (z. B. HDF5-Bibliotheken oder MPI-Runtimes). Docker bietet vollständige Isolation auf Kosten der Komplexität. Verwenden Sie Docker, wenn Sie einen Workflow für Forscher auf verschiedenen Betriebssystemen freigeben müssen, die Conda nicht installieren können oder wenn Ihr Workflow von Bibliotheken auf Systemebene abhängt.

Die Repro-Checkliste (Hornung et al., 2026) empfiehlt explizit die Angabe von Softwareversionen in der Readme und die Bereitstellung einer Umgebungsspezifikationsdatei. Sie beachten: „Für die langfristige Reproduzierbarkeit muss auch die Softwareumgebung klar dokumentiert werden, einschließlich der Versionen aller verwendeten zusätzlichen Pakete.“

4. Persistente Datenfreigabe

Datenfreigabe geht Hand in Hand mit Code-Sharing. Ihre Simulationsausgaben – Mesh-Konfigurationen, Feldarrays, Zeitreihen von Variablen – sollten in einem Repository hinterlegt werden, das einen persistenten Bezeichner (DOI) zuweist.

Für Simulationsdaten bedeutet dies normalerweise:

  • Rohsimulationsausgaben (Feld-Arrays, Mesh-Dateien, Zeitreihen) neben dem Code hinterlegt
  • Zwischenergebnisse für rechenintensive Simulationen (siehe Empfehlung der Repro-Checkliste zu Zwischenergebnissen)
  • Synthetische Testdaten Wenn Ihre realen Daten aufgrund von Datenschutz oder gesetzlichen Einschränkungen nicht öffentlich geteilt werden können

Die Fair-Prinzipien (Wilkinson et al., 2016) bieten einen Rahmen für das Datenmanagement – siehe Die GO-Fair-Leitlinien zum Thema Grundsätze für die offiziellen Leitlinien zu Auffindbarkeit, Zugänglichkeit, Interoperabilität und Wiederverwendbarkeit.

  • Finderbar: Zuweisen von persistenten Bezeichnern (DOIs) und umfassende Metadaten
  • Zugriff: Speichern Sie Daten in Repositories mit offenen Protokollen (Zenodo, Figshare, Material Data Facility)
  • Interoperable: Verwenden Sie Standardformate (HDF5, NetCDF, JSON) und formale Vokabulare
  • Wiederverwendbar: Dokumente Provenienz, Lizenzierung und Datenkarten dokumentieren

Für Materialwissenschaften und Computerphysik sind Plattformen wie die Materials Cloud und die nomad repository Bietet eine faire Infrastruktur für Simulationsdaten, komplett mit Metadatenschemas und API-Zugriff.

5. Dokumentation

Die Repro-Checkliste legt großen Wert auf die Dokumentation – nicht als nachträgliche, sondern als struktureller Bestandteil reproduzierbarer Arbeit. Eine Readme-Datei sollte:

  • Listen Sie jede Datei im Repository und ihren Zweck auf
  • Geben Sie die genaue Ausführungsreihenfolge an (welche Skripte erzeugen welche Abbildungen oder Tabellen)
  • Stellen Sie ungefähre Laufzeiten und Hardwareanforderungen
  • Verweisen Sie auf die entsprechenden Abbildungs- und Tabellennummern aus der Publikation

Für Simulations-Workflows bedeutet die Dokumentation auch, Ihre numerischen Methoden zu dokumentieren. Wenn Sie einen benutzerdefinierten Solver oder ein FIPY-Skript mit Operator-Splitting schreiben, Strang-Splitting, und IMEX Schemes für PDE-Solver, Sie müssen dokumentieren:

  • Das Diskretisierungsschema
  • Die Zeitintegrationsmethode
  • Die Solvertoleranzen
  • Die Konvergenzkriterien

Wenn ein anderer Forscher die numerische Methode hinter Ihren Ergebnissen nicht verstehen kann, kann er nicht bewerten, ob die Ergebnisse gültig sind – oder sie auf einem anderen Löser reproduzieren.

Die Repro-Checkliste als Selbstaudit-Tool

Die Repro-Checkliste (Hornung et al., 2026), veröffentlicht in Royal Society Open Science (Full Paper), wurde von einem internationalen Konsortium von Journal-Reproduzierbarkeitsredakteuren entwickelt, um eine prägnante, umsetzbare Rahmen für reproduzierbare Forschung. Während es disziplinübergreifend gilt, sind mehrere Elemente für die rechnergestützte Simulationsarbeit besonders relevant.

So verwenden Sie die Repro-Checkliste als Selbstaudit vor der Einreichung:

A. Struktur und Readme

Check: Haben Sie ein Verzeichnis data/, code/ und results/ (oder output/)? Listet Ihre Readme-Datei jede Datei auf, gibt die Ausführungsreihenfolge an und verweist auf die entsprechenden Zahlen jedes Skripts?

Häufiger Fehler: Forscher organisieren ihren Simulationscode in einem einzigen Ordner ohne Struktur. Eine Readme-Datei wird oft ganz weggelassen. Ohne eine Readme kann ein Reviewer nicht wissen, welches Skript welche Figur produziert – und er kann die Skripte in der falschen Reihenfolge ausführen und völlig unterschiedliche Ergebnisse erzielen.

B. Umgebungsspezifikation

Check: Ist Ihr environment.yml oder requirements.txt im Archiv enthalten? Sind Python- und Paketversionen explizit angegeben?

Häufiger Fehler: Der häufigste Grund, warum Notebooks fehlschlagen, fehlen oder widersprüchliche Abhängigkeiten. Samuel & Mietchen stellte fest, dass 34,32% der Notebooks beim Installationsschritt der Abhängigkeit ausfielen – obwohl keine der Dateien fehlerhaft war. Die Hauptursache sind häufig nicht spezifizierte oder veraltete Paketversionen.

C. Datenverfügbarkeit

Check: Kann ein Reviewer Ihren Code mit den bereitgestellten Daten von Grund auf neu ausführen? Wenn Sie echte Daten nicht teilen können, haben Sie synthetische Daten aufgenommen, die die Berechnungsstruktur nachahmen?

Häufiger Fehler: Wenn die realen Daten nicht geteilt werden können (aufgrund von rechtlichen, ethischen oder institutionellen Einschränkungen), sollte der Code weiterhin mit synthetischen Daten ausgeführt werden. Die Repro-Checkliste empfiehlt, synthetische Daten mit Paketen wie synthpop oder simdata in R oder numpy.random in Python zu generieren.

D. Deterministische Ausführung

Check: Sind Zufallsgenerator-Seeds explizit gesetzt? Werden für parallele Simulationen reproduzierbare Zufallszahlenströme verwendet?

Häufiger Fehler: Dies ist eine der häufigsten und subtilsten Ursachen der Unreproduzierbarkeit. Eine Simulation, bei der numpy.random.randn() ohne Setzen eines Seeds verwendet wird, erzeugt bei jedem Lauf unterschiedliche Ergebnisse – und selbst bei einem Seed können parallele Arbeiter überlappende zufällige Ströme erzeugen. Die Repro-Checkliste empfiehlt die Verwendung der SeedSequence-basierten Generierung von Numpy für parallele, deterministische Zufallsströme.

from numpy.random import default_rng
rng = default_rng(42)  # Fixed seed

Verwenden Sie für parallele Simulationen numpy.random.SeedSequence, um unabhängige, reproduzierbare Ströme zu generieren:

from numpy.random import SeedSequence
seq = SeedSequence(42)
children = seq.spawn(n_children)  # Deterministic per-child seeds

E. Zwischenergebnisse

Check: Werden bei rechnerisch intensiven Simulationen (z. B. Parameter-Sweep, Monte-Carlo-Studien) Zwischenergebnisse gespeichert, damit die Rezensenten bestimmte Zahlen reproduzieren können, ohne die vollständige Analyse erneut durchzuführen?

Allgemeiner Fehler: Wenn eine Simulation Stunden oder Tage dauert, können die Prüfer sie nicht von Grund auf neu ausführen. In der Repro-Checkliste wird empfohlen, Zwischenergebnisse (Rohausgabe vor der endgültigen Abbildung der Abbildung) zu speichern, damit die Prüfer bestimmte Ausgaben schnell überprüfen können. Dies ist besonders wichtig für Simulationsstudien mit parallelen Replikationen.

Schritt-für-Schritt-Workflow vom Simulationsdesign bis zur Einreichung

Dieser Abschnitt enthält einen konkreten Workflow, der die fünf Säulen und die Repro-Checkliste in eine wiederholbare Produktionspipeline integriert.

Phase 1: Simulationsdesign und Codeorganisation

  1. Projektstruktur erstellen:
project/
├── README.md
├── environment.yml
├── data/
│   ├── input/         # Simulation inputs, initial conditions
│   ├── output/        # Raw simulation outputs
│   └── synthetic/     # Synthetic test data (if real data is restricted)
├── code/
│   ├── mesh.py        # Mesh configuration
│   ├── solve.py       # Main simulation script
│   ├── postprocess.py # Figure generation
│   └── test/          # Unit tests and convergence checks
└── results/
    ├── figures/
    └── tables/
  1. Versionskontrolle: Das Repository initialisieren und die Struktur festlegen.
git init
git add README.md environment.yml
git commit -m "Initial project structure"

Phase 2: Simulationsausführung und Dokumentation

  1. Schreiben Sie die Simulation in einem Leseformat. Verwenden Sie Jupyter-Notizbücher oder Skriptdateien mit umfangreichen Kommentaren. Dokumentieren Sie jede numerische Methode, jede Wahl des Solvers, jede Randbedingung.
  2. Setzen Sie deterministische Seeds. Schließen Sie np.random.seed(42) (oder ein ausgefeilteres SeedSequence-Setup für parallele Ausführungen) oben in jedem Skript ein.
  3. Erfassen Sie die Umgebung. Führen Sie session_info.show() oder conda env export während eines erfolgreichen Laufs aus und nehmen Sie die Ausgabe in die Readme auf.
  4. Zwischenergebnisse speichern. Wenn Ihre Simulation rechenintensiv ist, speichern Sie Rohausgaben an Prüfpunkten, damit die Prüfer bestimmte Zahlen überprüfen können, ohne alles erneut auszuführen.

Phase 3: Validierung und Überprüfung

  1. Konvergenzstudien durchführen. Stellen Sie sicher, dass Ihre Ergebnisse wie erwartet konvergieren, wenn Sie das Netz verfeinern. Dies ist Teil der Überprüfung – zu überprüfen, ob die numerische Lösung mit abnehmender Diskretisierungsparameter der genauen Lösung nähert. Einen praktischen Rahmen finden Sie in unserem Leitfaden zu Validierung und Verifikation für PDE-Simulationen .
  2. Einheitstests schreiben. Testen Sie einzelne Funktionen, Randbedingungen und Löser. Wenn Sie FIPY verwenden, kann dies das Testen der CellVariable-Werte einschließen, die korrekt initialisiert oder DiffusionTerm korrekt diskretisiert wird. Weitere Informationen finden Sie in unserem Artikel über Prüfmuster für wissenschaftlichen Code .

Phase 4: Archivierung und Einreichung

  1. Archiv auf Zenodo. Drücken Sie das endgültige Commit auf GitHub und verknüpfen Sie es mit Zenodo für die DOI-Zuweisung.
  2. Repro-Checklisten-Audit ausführen:
    • Readme-Datei mit Ausführungsreihenfolge?
    • Umweltspezifikation enthalten?
    • Daten verfügbar (echt oder synthetisch)?
    • deterministische Seeds-Set?
    • Zwischenergebnisse gespeichert?
  3. Senden Sie mit dem Code und den Daten DOI in der Datenverfügbarkeitserklärung Ihres Manuskripts. Viele Zeitschriften erfordern dies jetzt bei der Einreichung oder Überarbeitung.

Häufige Fallstricke und wie man sie vermeidet

Falle 1: Absolute Wege

Wenn Sie absolute Pfade wie /home/user/simulations/output/data.csv in Ihrem Code verwenden, wird die Reproduzierbarkeit auf einer anderen Maschine als dem, auf dem Sie das Projekt entwickelt haben, unterbrochen.

Fix: Relative Pfade aus dem Projektstamm verwenden. Wenn Ihre Skripte Daten in einem data/-Verzeichnis erwarten, verweisen Sie auf data/input.csv, unabhängig davon, wo das Projekt geklont wird.

Fallfall 2: Unplanmäßige Abhängigkeiten

Ein Notebook importiert scipy.stats, erklärt jedoch nicht, dass scipy erforderlich ist. Wenn ein anderer Forscher das Notebook ausführt, hat er möglicherweise eine inkompatible scipy -Version – oder verpasst es völlig.

Fix: Schließen Sie immer ein requirements.txt oder environment.yml ein und überprüfen Sie es, indem Sie die lokale Umgebung löschen und vor der Archivierung von Grund auf neu installieren.

Fallfall 3: Fehlende Readme

Ohne Readme können die Rezensenten nicht wissen:

  • Welches Skript produziert welche Figur
  • Welche Skripte der Reihenfolge sollten ausgeführt werden?
  • Welche ungefähre Laufzeit zu erwarten
  • Welche Python-Version oder Paketversionen wurden verwendet

Fix: Schreiben Sie eine Readme, die jede Datei, jeden Ausführungsschritt und jede Laufzeitschätzung auflistet. Verweisen Sie auf die Abbildungsnummern aus Ihrer Publikation.

Fallfall 4: Python-Version Drift

Python 3.6 war Sonnenuntergang im Jahr 2021; Python 3.7 war im Juni 2023 Sonnenuntergang. Viele Notizbücher im Samuel & Mietchen Corpus verwendet veraltete Python-Versionen und die Nichtübereinstimmung zwischen der Version bei der Veröffentlichung und der verfügbaren Version, wenn die Reproduktionsversuche die Reproduktion versuchen, verursacht subtile Inkompatibilitäten.

Fix: Verwenden Sie eine aktuelle, aktiv unterstützte Python-Version und geben Sie sie in Ihrer Umgebungsdatei an. Die Repro-Checkliste empfiehlt, die Python-Version in der Readme zu dokumentieren.

Fallstricke 5: Nicht-deterministische Zufallszahlen

Eine Simulation, die zufällige Anfangsbedingungen ohne Fixierung des Seeds erzeugt, erzeugt jedes Mal unterschiedliche Ausgaben. Selbst mit einem Saatgut können parallele Arbeiter überlappende Ströme erzeugen.

Fix: Setzen Sie einen festen Startwert für alle Zufallsoperationen. Verwenden Sie numpy.random.SeedSequence für die Parallel-Sicher-Reproduzierbarkeit. Die Repro-Checkliste empfiehlt dieses Muster explizit.

Wann wählen Sie Container im Vergleich zu leichten Umgebungen?

Für die meisten Simulations-Workflows ist ein leichtes Umgebungsmanagement (Conda, PIP, UV) ausreichend. Sie erhalten Reproduzierbarkeit, indem Sie genaue Paketversionen angeben – und Prüfer können die Umgebung mit einem einzigen Befehl installieren.

Wählen Sie Conda / UV / Pip, wenn:

  • Sie arbeiten mit Python-basierten Solvern (FIPY, OpenPDE, FENICS)
  • Sie haben die Kontrolle über die Rechenumgebung an Ihrem Ende
  • Sie möchten einen leichten, tragbaren Workflow

Wählen Sie Docker, wenn:

  • Sie müssen einen Workflow für Forscher freigeben, die Conda oder bestimmte Bibliotheken auf Systemebene nicht installieren können
  • Ihr Workflow hängt von C++/Fortran-Solvern ab, die kompiliert werden müssen
  • Sie reichen ein Journal ein, das containerisierte Reproduzierbarkeit erfordert (z. B. Computo).

Für die überwiegende Mehrheit der computergestützten Materialien ist Conda oder UV die bessere Wahl – sie ist einfacher, schneller und ausreichend für die Reproduzierbarkeit, die Rezensenten und Leser benötigen.

Ein praktischer Hinweis zu den Erwartungen der Zeitschriften

Die Repro-Checkliste dokumentiert die Heterogenität von Zeitschriftenreproduzierbarkeitsrichtlinien. Einige Zeitschriften (wie Biometric Journal oder Journal der American Statistical Association ) erfordern eine aktive Reproduzierbarkeitsprüfung durch engagierte Redakteure. Andere (wie das BMJ ) benötigen Code-Einreichung, führen jedoch keine unabhängigen Ausführungsprüfungen durch.

Für die rechnergestützte Simulationsarbeit ist die Mindesterwartung für die meisten Zeitschriften:

  • Verfügbarkeit des Codes: Der Analysecode sollte als ergänzende Datei oder in einem offenen Repository (Github, Zenodo) bereitgestellt werden.
  • Datenverfügbarkeit: Die zur Analyse verwendeten Daten sollten öffentlich zugänglich oder gerechtfertigt sein
  • Umgebungsspezifikation: Softwareversionen und Pakete sollten dokumentiert werden

Dies ist der Boden – nicht die Decke. Nach den fünf Säulen und der Repro-Checkliste positionieren Sie Ihre Arbeit über dem Boden und signalisieren, dass Sie die Reproduzierbarkeit ernst nehmen.

Nächste Schritte für Ihren Simulationsworkflow

Wenn Sie mit reproduzierbaren Simulationspraktiken noch nicht vertraut sind, beginnen Sie mit den drei wirkungsvollsten Änderungen:

  1. Readme-Datei zu Ihrem Projekt mit Dateibeschreibungen und Ausführungsreihenfolge hinzufügen
  2. Exportieren Sie Ihre Umgebung (conda env export oder uv export) und nehmen Sie sie in Ihr Archiv auf
  3. Setzen Sie zufällige Seeds in jedem Simulationsskript und verwenden Sie SeedSequence für parallele Läufe

Allein diese drei Änderungen werden 80% der von Samuel & Mieten.

Wenn Sie Hilfe beim Entwerfen eines reproduzierbaren Simulationsworkflows benötigen – von der Notebook-Dokumentation über die Code-Archivierung bis zur Übermittlung von Zeitschriften -, kann unser Team Beratung zum Workflow-Design, Umgebungsspezifikation und gerechtfertigter Datenarchivierung anbieten. Kontaktieren Sie uns, um Ihr spezifisches Simulationsprojekt zu besprechen. Der Aufbau einer nachhaltigen Forschungssoftware-Community ( Wie wir uns der Community-Wurzelentwicklung nähern ) ist Teil dieses Prozesses: Reproduzierbarkeit verbessert sich, wenn das gesamte Team gemeinsame Standards teilt.

Schlussfolgerung

Reproduzierbare Veröffentlichungspraktiken für Simulationsergebnisse sind kein optionales Add-On – sie sind eine Voraussetzung für eine glaubwürdige wissenschaftliche Kommunikation. Die fünf Säulen (Litenerating-Programmierung, Versionskontrolle, Umgebungsmanagement, Datenaustausch, Dokumentation) und die Repro-Checkliste bilden eine strukturierte, umsetzbare Grundlage für die Reproduzierbarkeit, die für alle rechnerischen Disziplinen gilt.

Die Skala der Reproduzierbarkeitslücke – 12,4% erfolgreiche identische Reproduktion im Samuel & Mietchen Study – ist ein Aufruf zum Handeln. Jeder Simulationsworkflow, der eine Readme, eine Umgebungsdatei und deterministische Seeds enthält, schließt einen messbaren Teil dieser Lücke. Die Investition ist bescheiden: Stunden, nicht Monate. Die Rückkehr ist die Möglichkeit für jeden Leser, Rezensenten oder zukünftigen Forscher, Ihre Ergebnisse unabhängig zu überprüfen.

Reproduzierbarkeit ist für den Computerforscher nicht nur eine methodologische Tugend, sondern die Grundlage wissenschaftlicher Glaubwürdigkeit. Die fünf Säulen geben Ihnen einen Rahmen. Die Repro-Checkliste gibt Ihnen eine Checkliste. Die Werkzeuge (Git, Conda, Zenodo) sind verfügbar. Was bleibt, ist die Entscheidung, sie zu verwenden.

Fragen und Antworten

Was ist das Fünf-Pillaren-Rahmen für Reproduzierbarkeit?

Die fünf Säulen, vorgeschlagen von Ziemann et al. (2023) sind Programmierkenntnisse, Code-Versionskontrolle, Kontrolle der Computerumgebung, persistente Datenfreigabe und Dokumentation. Sie bilden einen strukturierten Rahmen für die Dokumentation und Weitergabe reproduzierbarer Rechenworkflows.

Was ist die Repro-Checkliste?

Die Repro-Checkliste, veröffentlicht von Hornung et al. (2026) ist ein prägnantes, multidisziplinäres Instrument zur Erstellung reproduzierbarer Analysen. Es umfasst Code- und Datenstruktur, Readme-Anforderungen, Umgebungsspezifikation, Datenverfügbarkeit, deterministische Zufallszahlengenerierung und Zwischenergebnisse.

Warum scheitern Jupyter-Notebooks so oft?

Samuel & Mietchen (2024) stellten fest, dass 87,6% der Python-basierten Notebooks während der automatischen Wiederholung zu Ausnahmen führten. Die Hauptursachen sind fehlende oder widersprüchliche Abhängigkeiten (ModuleNotFoundError und ImportError), unaufgelöste Dateipfade (FileNotFoundError) und nicht-deterministische Zufallszahlengenerierung.

Wie wähle ich zwischen Conda und Docker?

Verwenden Sie Conda (oder UV) für die meisten Python-basierten Simulations-Workflows – es ist einfacher, schneller und ausreichend, um genaue Paketversionen festzulegen. Verwenden Sie Docker, wenn Sie eine vollständige Isolation zwischen Betriebssystemen benötigen oder wenn Ihr Workflow von kompilierten C++/Fortran-Solvern abhängt.

Wie kann ich meine Simulationsergebnisse reproduzierbar machen, ohne Rohdaten zu teilen?

Generieren Sie synthetische Daten, die die Rechenstruktur Ihrer realen Daten nachahmen. Die Repro-Checkliste empfiehlt die Verwendung von Paketen wie synthpop oder simdata in R oder numpy.random in Python, um synthetische Testdaten zu erstellen, die eine unabhängige Überprüfung Ihres Analysecodes ermöglichen.