Reading Time: 9 minutes

Reproduzierbare Recherche-Workflows stellen sicher, dass die Simulationsergebnisse von anderen (oder Ihrem zukünftigen Selbst) mithilfe derselben Daten-, Code- und Rechenumgebung exakt neu erstellt werden können. Docker Bietet eine vollständige Containerisierung auf Systemebene für maximale Konsistenz über Plattformen hinweg, während conda ein leichtes Paket- und Umgebungsmanagement bietet, das ideal für Python-basiertes wissenschaftliches Computing ist. Für Simulationsprojekte empfehlen wir: (1) Conda für die tägliche Entwicklung und Abhängigkeitsverwaltung, (2) Erstellen Sie Docker-Images, um Arbeitsumgebungen für die Veröffentlichung und Zusammenarbeit „einzufrieren“ und (3) immer mit Versionskontrolle und gründlicher Dokumentation zu koppeln. Vermeiden Sie den häufigen Fehler, sich ausschließlich auf ein Werkzeug zu verlassen – beides für eine robuste Reproduzierbarkeit zu kombinieren.

Einleitung: Die Reproduzierbarkeitslücke in der Simulationsforschung

Wissenschaftliche Simulationsprojekte leiden oft unter einem stillen Ausfallmodus: Der Code hat gestern funktioniert, heute jedoch unterschiedliche Ergebnisse. Die zugrunde liegende Physik hat sich nicht geändert – Ihre Rechenumgebung hat sich geändert. Fehlende Paketversionen, geänderte Bibliotheksabhängigkeiten, Betriebssystemaktualisierungen oder sogar verschiedene Python-Interpreter können die Simulationsausgaben stillschweigend ändern, manchmal auf schwer zu erkennende Weise.

Dies ist mehr als eine Unannehmlichkeit. Reproduzierbarkeit ist der Eckpfeiler der kumulativen Wissenschaft – die Fähigkeit anderer Forscher, Ansprüche zu überprüfen und auf Ihrer Arbeit aufzubauen. Wenn Simulationsergebnisse nicht zuverlässig wiederhergestellt werden können, erodiert Vertrauen, Papiere zurückgezogen werden und wertvolle Forschungszeit verschwendet wird, um Umweltprobleme zu debuggen, anstatt Wissen zu erweitern.

In diesem Handbuch werden wir untersuchen, wie reproduzierbare Forschungsworkflows für Simulationsprojekte mit docker und conda implementiert werden – zwei ergänzende Tools, die zusammen eine robuste Lösung für die Konsistenz der Umgebung, das Abhängigkeitsmanagement und die langfristige Erhaltung von bieten Berechnungsmethoden.

Was ist reproduzierbare Forschung? Definitionen und Kernkomponenten

Im Kern bedeutet Reproduzierbare Forschung, dass ein unabhängiger Forscher die veröffentlichten Ergebnisse (Tabellen, Abbildungen, quantitative Ergebnisse) nur unter Verwendung der Originaldaten, des Codes und der Dokumentation regenerieren kann. Dies erfordert, wie durch den Turing-Weg definiert und in der Computerwissenschaft weit verbreitet ist, Folgendes erforderlich:

  • Datenverfügbarkeit: Rohdaten sind zugänglich (mit angemessenen Datenschutzhinweisen)
  • Codetransparenz: Alle Analyse- und Simulationsskripte werden gemeinsam genutzt
  • Dokumentation: Vollständige Aufzeichnungen über Softwareversionen, Parameter und Umgebungskonfigurationen
  • Umgebungskontrolle: Die genaue Laufzeitumgebung wird erfasst und rekonstruierbar

Die Reproduzierbarkeit der Computer unterscheidet sich von der Replizabilität (ähnliche Schlussfolgerungen mit neuen Daten oder unabhängigen Methoden zu ziehen). Reproduzierbarkeit ist der Mindeststandard – es geht darum, dieselben Zahlen aus denselben Eingaben zu erhalten und die zugrunde liegenden wissenschaftlichen Behauptungen nicht zu validieren.

Warum es für Simulationsprojekte wichtig ist : PDE-Solver, Finite-Elemente-Methoden und andere Simulations-Frameworks umfassen häufig komplexe Abhängigkeitsketten. Eine geringfügige Versionsänderung in einer numerischen Bibliothek kann das Diskretisierungsverhalten, die Konvergenzkriterien oder das Runden verändern und messbar unterschiedliche Ergebnisse erzielen. Reproduzierbare Workflows beseitigen diese Quelle der Unsicherheit.

Docker für reproduzierbare wissenschaftliche Simulationen

Was Docker bietet

Docker ist eine Containerisierungsplattform, die eine Anwendung und ihre gesamte Laufzeitumgebung – Betriebssystem, Bibliotheken, Abhängigkeiten, Konfigurationsdateien – in ein tragbares, unveränderliches Image packt. Wenn Sie einen Docker-Container ausführen, führen Sie genau dieselbe Umgebung aus, die unabhängig vom Hostsystem erstellt und getestet wurde.

Für Simulationsprojekte liefert Docker:

  1. Umweltkonsistenz: „Es funktioniert auf meiner Maschine.“ Der Container enthält bestimmte Versionen von Compilern, MPI-Implementierungen, Python-Interpreter und numerischen Bibliotheken.
  2. Platform Portability: Ein Docker-Image, das auf einem Laptop erstellt wird, kann ohne Änderungen auf einem HPC-Cluster, einer Cloud-Instanz oder einer Workstation eines Kollegen ausgeführt werden.
  3. Isolation: Simulationsabhängigkeiten stehen nicht in Konflikt mit Systembibliotheken oder anderen Projekten.
  4. Versions-Snapshots: Jedes Docker-Image ist unveränderlich und kann für eine genaue zukünftige Wiedergabe markiert werden (z. B. my-sim:paper-v1).

Docker-Einschränkungen zu berücksichtigen

Trotz seiner Stärken hat Docker wichtige Einschränkungen für das wissenschaftliche Rechnen:

  • Keine Silberkugel: Wie in „Docker übernimmt keine Reproduzierbarkeit“ (ArXiv 2026), können Container bei unterschiedlicher Hardware (CPU-Architektur, Gleitkommaoptimierungen) oder externen Services weiterhin nicht deterministisches Verhalten aufweisen. (Datenbank, Dateisystem) variieren.
  • Kernel-Abhängigkeit: Docker-Container teilen sich den Host-Kernel. Dies bedeutet, dass das Containerverhalten immer noch durch die Version und Konfiguration des Host-Kernels beeinflusst werden kann.
  • Größe Overhead: Vollständige OS-Bilder können groß sein (Hunderte von MB zu GB), obwohl schlanke Bilder wie alpine helfen.
  • HPC-Einschränkungen: Viele HPC-Zentren lassen Docker aufgrund von Sicherheitsbedenken nicht direkt zu. Sie verwenden stattdessen Singularity oder Apptainer. Sie können jedoch Singularity-Images aus Docker-Images erstellen, wodurch Docker zu einem tragfähigen Entwicklungswerkzeug wird.

Schreiben von DockerFiles für Simulationsprojekte

Die Dockerfile definiert, wie Sie Ihren Container erstellen. Nach den „Zehn einfachen Regeln für das Schreiben von Dockerfiles für reproduzierbare Forschung“ (Nüst et al., 2020) sind die wichtigsten Praktiken:

# Start from a minimal, pinned base image
FROM ubuntu:22.04  # Pin exact version, not :latest

# Set environment variables for reproducibility
ENV LANG=C.UTF-8
ENV LC_ALL=C.UTF-8

# Install system dependencies in one layer to minimize cache issues
RUN apt-get update && apt-get install -y 
    python3 
    python3-pip 
    libopenblas-dev 
    && rm -rf /var/lib/apt/lists/*

# Create and set working directory
WORKDIR /simulation

# Copy dependency specifications first (for better caching)
COPY requirements.txt environment.yml ./

# Install Python packages with pinned versions
RUN pip install --no-cache-dir -r requirements.txt

# Copy simulation code
COPY src/ ./src/
COPY scripts/ ./scripts/
COPY data/ ./data/

# Define entry point or command
ENTRYPOINT ["python3", "scripts/run_simulation.py"]

Schlüsselregel: Alle Versionen explizit anheften – Basis-Image, OS-Pakete, Python-Pakete und sogar PIP-Version. Verwenden Sie requirements.txt oder environment.yml mit exakten Versionen (package==1.2.3, nicht package>=1.0).

Conda für Umweltmanagement in der Forschung

Was Conda bietet

conda ist ein plattformübergreifender Paket- und Umgebungsmanager, der nicht nur Python-Pakete, sondern auch Abhängigkeiten von Nicht-Python (C/C++-Bibliotheken, Compiler, MPI) behandelt. Dies macht es besonders gut für wissenschaftliche Simulationen geeignet, wenn Sie möglicherweise bestimmte Versionen von OpenMPI, FFTW oder HDF5 benötigen.

Conda liefert:

  1. Sprachagnostic: Installieren Sie Python, R, C/C++ Bibliotheken und Systemtools in einer Umgebung.
  2. Binäre Abhängigkeiten: Vorkompilierte Pakete vermeiden die Kompilierung der Hölle auf verschiedenen Systemen.
  3. Isolated Environments: Jedes Projekt erhält seine eigene Umgebung ohne Kreuzkontamination.
  4. Export/Import: conda env export > environment.yml Erfasst die gesamte Umgebung für eine exakte Wiedergabe.

Best Practices von Conda

Basierend auf der MSI University of Minnesota und Anaconda Anleitung:

  • Niemals installieren in base: Erstellen Sie für jedes Projekt eine neue Umgebung: 
    conda create --name my-simulation python=3.11
conda activate my-simulation
  • Community-Kanäle verwenden: Bevorzugen Sie conda-forge gegenüber Standardeinstellungen für aktuellere wissenschaftliche Pakete: 
    conda config --add channels conda-forge
conda config --set channel_priority strict
  • Alle Pakete auf einmal installieren: Dadurch werden Abhängigkeitskonflikte vermieden: 
    conda install numpy scipy matplotlib fipy
  • Bestehende Umgebungen nicht ändern: Wenn Sie neue Pakete benötigen, aktualisieren Sie entweder die Umgebungsspezifikation oder erstellen Sie eine neue Umgebung aus der aktualisierten YAML-Datei.
  • Clean exportieren: Entfernen Sie beim Freigeben plattformspezifische Pakete und PIP-installierte Elemente, die nicht unbedingt erforderlich sind: 
    conda env export --no-builds | grep -v "prefix:" > environment.yml

Docker vs Conda: Wann wählen Sie welche

Die Frage lautet nicht „Docker oder Conda?“ – Sie lösen verschiedene Probleme und sind Ergänzung .

Aspekt Docking Konda
Scope Gesamte Betriebssystem + Laufzeit Paket & Umgebungsmanager
Isolierung Systemebene (Kernel-Namespace) User-Space-Umgebung
Größe Groß (100 MB–1 GB+) Klein (MBS)
Geschwindigkeit langsamer zu bauen / zu übertragen Sofortige Aktivierung
HPC-Unterstützung Begrenzt (Singularität funktioniert) Ausgezeichnet (Native)
Anwendungsfall Veröffentlichung, Freigabe, Bereitstellung Tägliche Entwicklung, Erkundung

Praktische Empfehlung

  • CONDA für die Entwicklung verwenden: Erstellen Sie schnell isolierte Umgebungen, testen Sie Abhängigkeiten und iterieren Sie den Code. Es ist leicht und schnell.
  • Docker für die Erhaltung verwenden: Sobald Ihre Simulation funktioniert, erstellen Sie ein Docker-Image, um die genaue Umgebung zu „einfrieren“. Teilen Sie dieses Bild mit Mitarbeitern, hängen Sie es an Publikationen an oder verwenden Sie es für CI/CD.
  • Kombinieren Sie beide: Entwickeln Sie in Conda und erstellen Sie dann eine Dockerdatei, die entweder:
    • die Conda-Umgebung in das Bild kopiert, oder
    • die Umgebung mit den exportierten environment.yml

      • neu erstellt.

Dieser geschichtete Ansatz gibt Ihnen Entwicklungsagilität und Publikations-Robustheit.

Integration von Docker und Conda in wissenschaftliche Workflows

Strategie 1: Conda im Docker

Die häufigste Integration ist die Installation und Verwendung von Conda in einem Docker-Container. Dies gibt Ihnen die feinkörnige Paketverwaltung in Dockers Systemisolation.

FROM ubuntu:22.04

# Install Miniconda
RUN wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh 
    && bash Miniconda3-latest-Linux-x86_64.sh -b -p /opt/conda 
    && rm Miniconda3-latest-Linux-x86_64.sh
ENV PATH=/opt/conda/bin:$PATH

# Create and use a conda environment
COPY environment.yml .
RUN conda env create -f environment.yml
ENV PATH=/opt/conda/envs/my-sim/bin:$PATH

Pros: Nutzt das umfangreiche wissenschaftliche Paket-Ökosystem von Conda; Konsistent mit lokalen Entwicklungs-Workflows.
cons: Größere Bildgröße; Conda-Aktivierungsnuancen in Docker.

Strategie 2: Docker zur Umgebungserfassung

Entwickeln Sie lokal mit Conda, exportieren Sie die Umgebung und backen Sie sie in ein Docker-Image, ohne Conda zur Laufzeit auszuführen:

FROM python:3.11-slim

# Copy pre-built packages or use pip from a frozen requirements.txt
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

Dies ist einfacher, verliert jedoch die Behandlung von Conda-Abhängigkeitsfällen.

Strategie 3: Mehrstufige Builds für HPC

Erstellen Sie bei HPC-Clustern lokal das Docker-Image und konvertieren Sie es in Singularity:

docker build -t my-sim:latest .
singularity build my-sim.sif docker://my-sim:latest

Mit diesem Workflow können Sie sich mit Docker (Easy Testing) entwickeln und auf HPC (Singularity) bereitstellen.

Häufige Fallstricke und wie man sie vermeidet

Basierend auf der Analyse der Reproduzierbarkeitsherausforderungen in der Simulationsforschung sind hier kritische Fehler zu vermeiden:

1. Fehlende oder unvollständige Dokumentation

Problem: Sie haben ein funktionierendes Docker-Image, aber keine Aufzeichnung darüber, wie es verwendet wird, welche Eingaben es erwartet oder wie Sie Ausgaben interpretieren.

Lösung: Fügen Sie README.md in den Behälter (oder neben dem Bild) ein mit:

  • So führen Sie die Simulation aus (Befehlszeilenargumente)
  • Erwartete Eingabedateiformate
  • Beschreibungen der Ausgabedatei
  • Hardwareanforderungen (CPU, Speicher, GPU)
  • Bekannte Einschränkungen

2. Unpinnende Abhängigkeiten

Problem: Verwenden von numpy>=1.0 oder python=3.x Ermöglicht automatische Updates, die das Verhalten ändern können.

Lösung: Pin exakte Versionen in environment.yml und requirements.txt:

dependencies:
  - python=3.11.8
  - numpy=1.26.4
  - scipy=1.11.4
  - pip:
    - my-package==0.3.2

3. Nicht-deterministische Simulationen

Problem: Selbst bei identischen Umgebungen führen Simulationen aufgrund von Gleitkomma-Nicht-Assoziativität, parallelen Rassenbedingungen oder nicht initialisiertem Gedächtnis zu leicht unterschiedlichen Ergebnissen.

Lösung:

  • Setzen Sie deterministische Flags, sofern verfügbar (z. B. OpenMP OMP_NUM_THREADS=1, BLAS-Gewinde
  • Verwenden Sie feste zufällige Samen und dokumentieren Sie sie
  • Testen Sie die Reproduzierbarkeit, indem Sie den Container mehrmals auf demselben Host ausführen

4. Große Daten in Containern

Problem: Das Backen großer Simulationsdatensätze in Docker-Images bläht sie auf und verlangsamt die Verteilung.

Lösung: Halten Sie die Daten extern. Verwenden Sie Docker-Volumes oder Bindungs-Mounts, um Daten zur Laufzeit anzuhängen:

docker run -v /path/to/data:/data my-sim:latest

Datenerwartungen klar dokumentieren.

5. HPC-Einschränkungen ignorieren

Problem: Docker-Images, die auf einem Laptop funktionieren, scheitern in einem HPC-Cluster aufgrund fehlender MPI-Implementierungen, inkompatibler Treiber oder Sicherheitsbeschränkungen.

Lösung:

  • Testen Sie frühzeitig in einer Cluster-ähnlichen Umgebung
  • Verwenden Sie die Singularitätskompatibilität, wenn Sie auf HPC abzielen
  • Vermeiden Sie Docker-in-Docking-Muster. Bauen Sie auf einem Basis-Image auf, das dem Cluster-OS entspricht (z. B. CentOS / Rocky, wenn Cluster diese verwendet).

6. Keine Versionskontrolle für Dockerfiles und Umgebungsdateien

Problem: Sie haben ein Arbeitsbild, aber keine Änderungen an der Dockerfile oder environment.yml.

Lösung: Behandeln Sie Dockerfile- und Umgebungsspezifikationen als Code. Speichern Sie sie in Git neben Ihrem Simulationscode. Tag-Releases (z. B. git tag -a v1.0 -m "Paper submission").

7. Überblickende externe Dienste

Problem: Ihre Simulation zieht Daten aus einer Datenbank oder API, die sich im Laufe der Zeit ändern und die Reproduzierbarkeit beeinträchtigen.

Lösung:

  • Snapshot externe Daten und fügen Sie sie in Ihr Repository oder Container ein oder
  • Verwenden Sie versionierte API-Endpunkte und dokumentieren Sie die genaue Version / Datum, auf das zugegriffen wird

Überlegungen zu HPC und Cluster

Hochleistungs-Computing-Umgebungen stellen zusätzliche Reproduzierbarkeitsprobleme vor:

Singularity / Apptainer statt Docker

Die meisten HPC-Zentren verbieten Docker aus Sicherheitsgründen. Stattdessen bieten sie Singularity (oder ihre Fork Apptainer). Singularity-Container werden aus Docker-Images erstellt:

# On your local machine with Docker
docker pull ubuntu:22.04
docker tag ubuntu:22.04 my-sim:base

# Build your image as usual
docker build -t my-sim:latest .

# Transfer image to HPC and convert
singularity build my-sim.sif docker://my-sim:latest

Schlüsselunterschied: Singularity führt Container als aufrufende Benutzer (kein Root) aus, daher unterscheiden sich die Paketinstallationspfade. Testen Sie Ihr Dockerfile mit Singularität, um Probleme frühzeitig zu erkennen.

Modulsysteme

Viele HPC-Cluster verwenden Umgebungsmodule (LMOD), um Softwareversionen zu verwalten. Sie können entweder:

  • Laden Sie die erforderlichen Module, bevor Sie Ihren Container ausführen (wenn Singularity darauf zugreifen kann), oder
  • Erstellen Sie Ihren Container auf einem Basis-Image, das bereits benötigte Bibliotheken enthält

Parallele I/O und MPI

Wenn Ihre Simulation MPI (Message Passing Interface) verwendet, stellen Sie sicher, dass Ihr Container eine kompatible MPI-Implementierung enthält. Für die Singularität können Sie die MPI-Bibliotheken des Hosts Bind-Mount:

singularity run --nv -B /usr/lib/x86_64-linux-gnu/openmpi:/usr/lib/x86_64-linux-gnu/openmpi my-sim.sif

Installieren Sie alternativ Mpich oder OpenMPI im Container und stellen Sie sicher, dass die Netzwerkstruktur des Hosts (InfiniBand usw.) verwendet wird.

GPU-Unterstützung

Für GPU-beschleunigte Simulationen erfordern sowohl Docker als auch Singularity spezielle Flags:

  • Docking: --gpus all
  • Singularität: --nv

Testen Sie die GPU-Funktionalität gründlich in Ihrem Container.

Schritt-für-Schritt-Implementierungshandbuch

Hier ist ein praktischer Workflow zur Implementierung reproduzierbarer Forschungsworkflows in Ihrem Simulationsprojekt:

Phase 1: Projektaufbau

  1. Versionskontrolle initialisieren (Git): 
    git init
git add .
git commit -m "Initial project structure"
  2. CONDA-Umgebung erstellen: 
    conda create --name my-sim python=3.11
conda activate my-sim
  3. Abhängigkeiten installieren und aufzeichnen: 
    conda install numpy scipy matplotlib fipy  # Example for PDE simulations
conda env export --no-builds | grep -v "prefix:" > environment.yml
  4. Projektstruktur erstellen: 
    my-simulation/
├── src/              # Source code
├── scripts/          # Run scripts, entry points
├── data/             # Input data (git-ignored if large)
├── outputs/          # Generated results (git-ignored)
├── docs/             # Documentation
├── environment.yml   # Conda environment
├── requirements.txt  # Pip-only dependencies (if any)
├── Dockerfile        # Container definition
├── README.md         # Usage instructions
└── .gitignore        # Exclude outputs, large data

Phase 2: Entwicklung mit CONDA

  • Entwickeln und testen Sie in der Conda-Umgebung
  • Code-Änderungen häufig festlegen
  • Aktualisieren Sie environment.yml beim Hinzufügen/Entfernen von Paketen
  • Verwenden Sie .gitignore, um generierte Ausgaben und große Datendateien auszuschließen

Phase 3: Erstellen des Docker-Images

  1. Dockerfile erstellen (siehe Beispiel oben)
  2. Bild erstellen: 
    docker build -t my-sim:latest .
  3. Behälter testen: 
    docker run -v $(pwd)/data:/data my-sim:latest python scripts/run_simulation.py --input /data/input.h5
  4. Tag zur Veröffentlichung: 
    docker tag my-sim:latest my-sim:paper-v1.0
  5. Push to Registry (optional, zum Teilen): 
    docker push my-registry.example.com/my-sim:paper-v1.0

Phase 4: Verifizierung und Freigabe

  1. Testreproduzierbarkeit: Lassen Sie einen Kollegen das Bild ziehen und ausführen. Sie sollten identische Ergebnisse erhalten (bit-für-Bit identisch, wenn die Simulation deterministisch ist).
  2. Dokument: Stellen Sie sicher README.md Enthält:
    • Wie Sie das Bild erhalten (Docker Hub, Registry oder .sif Datei)
    • Wie man es ausführt (Full-Befehl)
    • Eingabedateispezifikationen
    • Erwartete Ausgabedateien und deren Formate
    • Zitatinformationen
  3. Archiv: Hinterlegen Sie das Docker-Image (oder Singularität .sif) in einem Langzeitarchiv wie Zenodo oder Figshare und fügen Sie den Link in die Methoden oder die Datenverfügbarkeitserklärung Ihrer Arbeit ein.

Phase 5: Langzeitwartung

  • Aktualisieren Sie bei Codeänderungen das Docker-Image und markieren Sie es mit einer neuen Version (z. B. v1.1)
  • Bewahren Sie alte Bilder / Tags so lange auf, wie Sie alte Ergebnisse reproduzieren müssen
  • Verwenden Sie Git-Tags, um Code-Commits mit Docker-Image-Versionen zu korrelieren

Fazit und nächste Schritte

Die Implementierung von reproduzierbaren Forschungsworkflows ist keine einzige Werkzeugentscheidung – es ist eine Schichte-Strategie:

  • CONDA für leichtes, schnelles Umgebungsmanagement während der Entwicklung
  • Docker für unveränderliche, tragbare Umgebungs-Snapshots, die für die Veröffentlichung und Zusammenarbeit geeignet sind
  • Git zur Versionskontrolle von Code, Dockerfiles und Umgebungsspezifikationen
  • Dokumentation, um den Workflow für andere verständlich und nutzbar zu machen

Für Simulationsprojekte, bei denen Korrektheit und Überprüfbarkeit von größter Bedeutung sind, bietet diese Kombination eine robuste Grundlage. Beginnen Sie mit Conda für Ihr nächstes Projekt, und sobald die Simulation funktioniert, investieren Sie die Zeit, um ein Docker-Image zu erstellen. Die Vorabkosten zahlen sich aus, wenn Sie (oder andere) die Simulation Monate oder Jahre später mit Zuversicht erneut ausführen müssen.

Nächste Schritte, die Sie heute unternehmen können:

  1. Prüfen Sie Ihre aktuellen Simulationsprojekte: Sind Umgebungen dokumentiert? Sind Abhängigkeiten angeheftet?
  2. Konvertieren Sie ein vorhandenes Projekt in Conda-Umgebungen mit environment.yml
  3. Erstellen Sie ein Docker-Image für eine funktionierende Simulation und testen Sie es auf einer anderen Maschine
  4. Erkunden Sie die Singularitätsrichtlinien Ihres HPC Centers und konvertieren Sie ein Docker-Image in ein Singularity-Format
  5. Fügen Sie Umgebungsspezifikationen und Behälterbilder in die zusätzlichen Materialien Ihres nächsten Papiers ein

Verwandte Anleitungen

Referenzen und Weiterlesen