Prácticas de publicación reproducibles para los resultados de la simulación: El marco de los cinco pilares

• Los cuadernos de Jupyter se ejecutan con éxito solo ~12,4% del tiempo cuando se declaran las dependencias: la gestión de entornos explícitas cierra esta brecha
• El marco de los cinco pilares de Ziemann et al. (2023) proporciona una línea de base estructurada para documentación, control de versiones, gestión del entorno, intercambio de datos y cumplimiento justo
• La lista de verificación de REPRO (Hornung et al., 2026) ofrece una práctica herramienta de autoauditoría que cubre la estructura de carpetas, la especificación del entorno, la disponibilidad de datos y la ejecución determinista
• Las trampas comunes como rutas absolutas, dependencias inespecíficas y readmes faltantes son las principales causas de fallas de reproducibilidad en la investigación computacional
• Un flujo de trabajo paso a paso desde el diseño de simulación a través de la documentación del cuaderno, el archivo de código y el envío de diarios proporciona una canalización de producción repetible

La brecha de reproducibilidad en la investigación computacional

Cuando envía un documento basado en simulación, los revisores verifican su metodología, las condiciones de los límites, los estudios de convergencia y la comparación con los puntos de referencia analíticos. Pero rara vez vuelven a ejecutar su código. Los resultados presentados en sus figuras y tablas se convierten en el registro publicado, y si esos resultados fueron generados por un flujo de trabajo que no se puede reproducir, la publicación descansa sobre una base no verificada.

Este no es un problema teórico. Samuel & Mietchen (2024) analizó 15.817 Jupyter cuadernos basados en Python de publicaciones biomédicas indexadas en PubMed Central. De los cuadernos donde todas las dependencias declaradas pudieron instalarse con éxito, 87.6% resultó en excepciones durante la repetición automática. Solo 1203 portátiles se completaron sin errores, y de ellos, 324 produjeron resultados que diferían de los resultados informados originalmente. Los 879 portátiles restantes produjeron resultados idénticos. Esta tasa de éxito del 5,56% para la reproducción idéntica fue en realidad una mejora con respecto a la ejecución inicial de 2021 (5,88%), lo que indica que los cuadernos recientes tienden a ser marginalmente mejores, pero la brecha sigue siendo enorme.

¿Qué hace que la reproducibilidad sea más difícil para los científicos computacionales? Trabaja con solucionadores numéricos, refinamientos de malla, esquemas de integración de tiempo y estrategias de acoplamiento que producen resultados a través de cadenas de operaciones de punto flotante. Un solo golpe de versión de Python, un parámetro predeterminado modificado en numpy o scipy, o una ruta relativa que no se resuelva en otra máquina puede invalidar todas las figuras y tablas de su papel. El problema se agrava cuando su flujo de trabajo implica el refinamiento de malla adaptable, términos de origen personalizados o condiciones de contorno no triviales, el tipo de patrones avanzados documentados en recursos fipy en este sitio.

Cinco pilares de investigación computacional reproducible

Ziemann et al. (2023) formalizaron los cinco pilares de la reproducibilidad computacional como marco para documentar y compartir flujos de trabajo reproducibles. Si bien se desarrollaron originalmente en el contexto de la bioinformática, estos pilares se aplican por igual a las simulaciones de ciencia de materiales, la dinámica de fluidos computacional y los solucionadores de PDE basados en volúmenes finitos.

1. Programación alfabetizada

La programación alfabetizada significa documentar su flujo de trabajo computacional como una narrativa que intercala explicación y código ejecutable. En las ciencias computacionales, esto generalmente se manifiesta como cuadernos de Jupyter, documentos de Markdown o scripts de Python con extensos docStrings y comentarios en línea.

El objetivo no es simplemente producir un archivo reproducible, sino crear un documento que un lector que no esté familiarizado con su análisis pueda seguir, comprender y volver a ejecutar. Samuel & Mietchen (2024) encontró una clara correlación entre la relación reducción a celda de código y una reproducción exitosa: los cuadernos con mayor esfuerzo de documentación (más celdas de Markdown en relación con las celdas de código) tenían significativamente más probabilidades de reproducirse de manera idéntica a la salida original.

Para una simulación de campo de fase en fipy—una introducción a su arquitectura central—o un modelo de difusión utilizando el método de volumen finito, la programación alfabetizada podría verse así:

# 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)

Cuando escribe esta celda de cuaderno, está documentando simultáneamente la resolución de la malla, la PDE y las condiciones de los límites, y ejecutando la simulación que produjo la figura publicada.

Recomendación: Si su cuaderno tiene menos celdas de rebajas que las celdas de código, está subdocumentado. Apunta a al menos una proporción de 1:1, e idealmente más. El Samuel & El estudio de Mietchen encontró que el grupo de reproducción idéntica tenía una relación de reducción a código de 0,73, mientras que el grupo de reproducción diferente tenía solo 0,49.

2. Control de versiones de código y uso compartido

El control de versiones no es opcional para el trabajo de publicación. Git proporciona un historial permanente y consultable de cada cambio de código, y GitHub, GitLab o Zenodo archiva su repositorio como un objeto citable con un DOI.

El propósito del control de versiones es doble:

• Reproducibilidad: Un hash de confirmación específico (abc1234) emparejado con una fecha de confirmación específica le dice a cualquiera exactamente qué código produjo sus resultados publicados.
• Responsabilidad: Cada cambio de parámetro, cada modificación de término fuente, se registra cada edición de condición de límite. Cuando un revisor pregunta «¿por qué usó este coeficiente de difusión?» Puede señalar el compromiso exacto donde se estableció.

Al publicar, archive su repositorio en zenodo (o github con la integración de Zenodo habilitada) e incluya el DOI en la disponibilidad de datos de su manuscrito Declaración. Esto convierte su código de simulación en un artefacto permanente y citable. Muchas revistas ahora recomiendan depositar el código en los repositorios con la asignación de DOI: consulte el Joss Simulation Science Directrices para las expectativas de las revistas sobre publicaciones basadas en simulación.

Regla de decisión: ¿Github vs. Zenodo? Usar GitHub para el desarrollo activo y la colaboración. Usa zenodo para archivo. Zenodo asigna automáticamente un DOI a los repositorios de GitHub cuando se vincula, por lo que es la opción preferida para la publicación. Puede mantener un repositorio de GitHub en vivo y archivar la confirmación final en Zenodo para su envío.

3. Control de entorno de cálculo

El control del medio ambiente es la intervención técnica más importante que puede realizar. Cuando un revisor intenta reproducir sus resultados en una máquina nueva, necesita conocer la pila de software exacta: versión de Python, versión de Numpy, versión de Fipy, bibliotecas de Solver. Sin esta información, el revisor está adivinando, y adivinando produce ModuleNotFoundError, ImportError y FileNotFoundError (las tres excepciones más comunes identificadas por Samuel & Mietchen, responsables del 41,65% de toda ejecución fracasos).

Cómo capturar tu entorno:

# 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

Regla de decisión: ¿Conda vs. PIP vs. Docker? Para la mayoría de los flujos de trabajo de ciencia computacional en Python, Conda es el mejor equilibrio de practicidad e integridad. Maneja tanto los paquetes de Python como las dependencias que no son de Python (como bibliotecas HDF5 o MPI Runtimes). Docker proporciona aislamiento total a costa de la complejidad; Use Docker cuando necesite compartir un flujo de trabajo con investigadores en diferentes sistemas operativos que no puedan instalar Conda o cuando su flujo de trabajo depende de bibliotecas a nivel de sistema.

La lista de verificación REPRO (Hornung et al., 2026) recomienda explícitamente especificar versiones de software en el archivo Léame y proporcionar un archivo de especificación de entorno. Ellos señalan: «Para la reproducibilidad a largo plazo, el entorno del software también debe estar claramente documentado, incluidas las versiones de todos los paquetes adicionales utilizados».

4. Intercambio de datos persistente

El intercambio de datos va de la mano con el uso compartido de código. Sus salidas de simulación (configuraciones de malla, matrices de campo, series de tiempo de variables) deben depositarse en un repositorio que asigna un identificador persistente (DOI).

Para los datos de simulación, esto normalmente significa:

• Salidas de simulación RAW (matrices de campo, archivos de malla, series temporales) depositadas junto con el código
• Resultados intermedios para simulaciones computacionalmente intensivas (consulte la recomendación de Repro Checklist sobre resultados intermedios)
• Datos de prueba sintético Si sus datos reales no pueden compartirse públicamente debido a la privacidad o restricciones legales

Los Principios de la Feria (Wilkinson et al., 2016) proporcionan un marco para la gestión de datos, consulte La guía GO FAIR SOBRE EL Principios para la orientación oficial sobre la capacidad de búsqueda, accesibilidad, interoperabilidad y reutilización.

• Findable: Asigne identificadores persistentes (DOI) e incluya metadatos enriquecidos
• Accesible: Almacene datos en repositorios con protocolos abiertos (Zenodo, FigShare, Facilidad de datos de materiales)
• Interoperable: Use formatos estándar (HDF5, netCDF, JSON) y vocabularios formales
• Reutilizable: Documente la procedencia, la concesión de licencias y las tarjetas de datos

Para la ciencia de los materiales y la física computacional, plataformas como cloud de materiales y la nomad repository Proporciona una infraestructura compatible con los datos de simulación, completa con esquemas de metadatos y acceso a la API.

5. Documentación

La lista de verificación de repro pone un gran énfasis en la documentación, no como una ocurrencia tardía, sino como un componente estructural del trabajo reproducible. Un archivo Léame debe:

• Enumere todos los archivos del repositorio y su propósito
• Especifique el orden de ejecución exacto (qué scripts producen qué figuras o tablas)
• Proporcionar tiempos de ejecución aproximados y requisitos de hardware
• Refiera los números de figura y tabla correspondientes de la publicación

Para los flujos de trabajo de simulación, la documentación también significa documentar sus métodos numéricos. Cuando escribes un solucionador personalizado o un script FIPy con la división del operador, strang Esquemas de división y IMEX para los solucionadores de PDE, debe documentar:

• El esquema de discretización
• El método de integración del tiempo
• Las tolerancias del solucionador
• Los criterios de convergencia

Si otro investigador no puede entender el método numérico detrás de sus resultados, no puede evaluar si los resultados son válidos o reproducirlos en un solucionador diferente.

La lista de verificación de reproducción como una herramienta de autoauditoría

La Repro Checklist (Hornung et al., 2026), publicada en Royal Society Open Science (full paper), fue desarrollada por un consorcio internacional de editores de reproducibilidad de revistas para proporcionar un Marco procesable para la investigación reproducible. Si bien se aplica ampliamente en todas las disciplinas, varios elementos son particularmente relevantes para el trabajo de simulación computacional.

A continuación se explica cómo utilizar la lista de verificación de Repro como una autoauditoría previa a la presentación:

A. Estructura y Léame

Check: ¿Tiene un directorio data/, code/ y results/ (o output/)? ¿Su archivo Léame enumera todos los archivos, especifica el orden de ejecución y hace referencia a las figuras correspondientes de cada script?

Falla común: Los investigadores organizan su código de simulación en una sola carpeta sin estructura. Un archivo Léame a menudo se omite por completo. Sin un readme, un revisor no tiene forma de saber qué script produce qué figura, y puede ejecutar los scripts en el orden incorrecto, produciendo resultados completamente diferentes.

B. Especificación del medio ambiente

Check: ¿Se incluye su environment.yml o requirements.txt en el archivo? ¿Se especifican explícitamente las versiones de Python y Package?

Falla común: La razón más común de los cuadernos fallan son las dependencias o en conflicto. Samuel & Mietchen descubrió que el 34,32% de los portátiles fallaron en el paso de instalación de dependencias, aunque ninguno de los archivos estaba mal formado. La causa raíz a menudo son las versiones de paquetes no especificadas o desactualizadas.

C. Disponibilidad de datos

Comprobar: ¿Puede un revisor ejecutar su código desde cero usando los datos proporcionados? Si no puede compartir datos reales, ¿ha incluido datos sintéticos que imitan la estructura computacional?

Falla común: Cuando los datos reales no se pueden compartir (debido a restricciones legales, éticas o institucionales), el código aún debe ser ejecutable con datos sintéticos. La lista de comprobación de Repro recomienda generar datos sintéticos usando paquetes como synthpop o simdata en R, o numpy.random en Python.

D. Ejecución determinista

Comprobar: ¿Se establecen explícitamente las semillas del generador de números aleatorios? Para simulaciones en paralelo, ¿se utilizan flujos de números aleatorios reproducibles?

Falla común: Esta es una de las causas más comunes y sutiles de irreproducibilidad. Una simulación que usa numpy.random.randn() sin establecer una semilla producirá resultados diferentes en cada ejecución, e incluso con una semilla, los trabajadores paralelos pueden generar flujos aleatorios superpuestos. La lista de verificación de Repro recomienda usar la generación basada en SeedSequence basada en Numpy para flujos aleatorios deterministas y seguros en paralelo.

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

Para simulaciones en paralelo, use numpy.random.SeedSequence para generar flujos independientes y reproducibles:

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

E. Resultados intermedios

Comprobar: Para simulaciones computacionalmente intensivas (p. ej., barridos de parámetros, estudios de Monte Carlo), ¿se guardan los resultados intermedios para que los revisores puedan reproducir cifras específicas sin volver a ejecutar el análisis completo?

Falla común: Cuando una simulación tarda horas o días en ejecutarse, los revisores no pueden volver a ejecutarla desde cero. La lista de verificación de Repro recomienda guardar resultados intermedios (salida sin procesar antes de la generación de cifras finales) para que los revisores puedan verificar rápidamente los resultados específicos. Esto es especialmente importante para los estudios de simulación con replicaciones paralelas.

Flujo de trabajo paso a paso desde el diseño de simulación hasta la presentación

Esta sección proporciona un flujo de trabajo concreto que integra los cinco pilares y la lista de verificación de Repro en una canalización de producción repetible.

Fase 1: Diseño de simulación y organización de códigos

1. Crear la estructura del proyecto:

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/

2. Control de versiones: Inicialice el repositorio y confirme la estructura.

git init
git add README.md environment.yml
git commit -m "Initial project structure"

Fase 2: Ejecución de simulación y documentación

3. Escriba la simulación en un formato alfabetizado. Use cuadernos de Jupyter o archivos de secuencias de comandos con comentarios extensos. Documente cada método numérico, cada elección de solucionador, cada condición de límite.
4. Configurar semillas deterministas. Incluya np.random.seed(42) (o una configuración de SeedSequence más sofisticada para ejecutar en paralelo) en la parte superior de cada script.
5. Capturar el entorno. Ejecutar session_info.show() o conda env export durante una ejecución exitosa e incluir la salida en el Léame.
6. Guardar resultados intermedios. Si su simulación es intensiva computacionalmente, guarde las salidas sin procesar en los puntos de control para que los revisores puedan verificar cifras específicas sin volver a ejecutar todo.

Fase 3: Validación y Verificación

7. Ejecute estudios de convergencia. Verifique que sus resultados convergen como se espera mientras refina la malla. Esto es parte de la verificación, verificando que la solución numérica se acerque a la solución exacta a medida que disminuyen los parámetros de discretización. Para obtener un marco práctico, consulte nuestra guía sobre validación y verificación de simulaciones PDE.
8. Escriba las pruebas unitarias. Pruebe las funciones individuales, las condiciones de contorno y los solucionadores. Si está utilizando Fipy, esto puede incluir probar que los valores de CellVariable se inicializan correctamente o que DiffusionTerm se discretiza correctamente. Consulte nuestro artículo sobre Patrones de prueba para código científico para obtener más detalles.

Fase 4: Archivado y Presentación

9. Archivo en Zenodo. Empuje el compromiso final a GitHub y vincúlelo a Zenodo para la asignación de DOI.
10. Ejecutar la auditoría de la lista de verificación de Repro:
    • Archivo Léame con la orden de ejecución?
    • Especificación del medio ambiente ¿Incluido?
    • Datos disponibles (reales o sintéticos)?
    • ¿Series deterministas?
    • ¿Resultados intermedios guardados?
11. Envíe con el código y los datos doi en la declaración de disponibilidad de datos de su manuscrito. Muchas revistas ahora requieren esto en la presentación o revisión.

Trampas comunes y cómo evitarlas

Escolar 1: Caminos Absolutos

El uso de rutas absolutas como /home/user/simulations/output/data.csv en su código rompe la reproducibilidad en cualquier máquina que no sea la que desarrolló el proyecto.

fix: Utilice rutas relativas de la raíz del proyecto. Si sus scripts esperan datos en un directorio data/, consulte data/input.csv independientemente de dónde se clone el proyecto.

Escoma 2: Dependencias no programadas

Un cuaderno importa scipy.stats pero no declara que se requiere scipy. Cuando otro investigador ejecuta el cuaderno, es posible que tenga una versión incompatible scipy, o la pierda por completo.

FIX: Incluya siempre un requirements.txt o environment.yml y verifíquelo eliminando el entorno local y reinstalándolo desde cero antes de archivar.

Escollo 3: Léame faltante

Sin un Léame, los revisores no pueden saber:

• ¿Qué guión produce qué figura
• Qué scripts de orden deben ejecutarse
• Qué tiempo de ejecución aproximado esperar
• Qué versión de Python o versiones de paquete se utilizaron

Fix: Escriba un archivo README que enumere todos los archivos, cada paso de ejecución y cada estimación de tiempo de ejecución. Haga referencia a los números de figura de su publicación.

Escoma 4: deriva de la versión de Python

Python 3.6 fue el atardecer en 2021; Python 3.7 se puso en la puesta del sol en junio de 2023. Muchos cuadernos en el Samuel & Mietchen Corpus usó versiones de Python obsoletas, y el desajuste entre la versión en la publicación y la versión disponible cuando los revisores intentan reproducirse provoca sutiles incompatibilidades.

Fix: Use una versión de Python recientemente compatible y especifique en su archivo de entorno. La lista de verificación de Repro recomienda documentar la versión de Python en el archivo Léame.

Escolar 5: Números aleatorios no deterministas

Una simulación que genera condiciones iniciales aleatorias sin fijar la semilla produce diferentes salidas cada vez. Incluso con una semilla, los trabajadores paralelos pueden generar corrientes superpuestas.

FIX: Establezca una semilla fija para todas las operaciones aleatorias. Use numpy.random.SeedSequence para una reproducibilidad segura en paralelo. La lista de verificación de reproducción recomienda explícitamente este patrón.

Cuándo elegir Contenedores vs. Entornos ligeros

Para la mayoría de los flujos de trabajo de simulación, es suficiente la gestión del entorno ligero (Conda, PIP, UV). Obtiene reproducibilidad especificando versiones exactas del paquete, y los revisores pueden instalar el entorno con un solo comando.

Elija Conda/UV/PIP cuando:

• Estás trabajando con solucionadores basados en Python (fipy, openpde, fenics)
• usted tiene control sobre el entorno computacional de su parte
• Desea un flujo de trabajo ligero y portátil

Elige Docker cuando:

• Debe compartir un flujo de trabajo con investigadores que no pueden instalar Conda o bibliotecas específicas a nivel de sistema
• Su flujo de trabajo depende de los solucionadores de C++/Fortran que deben compilarse
• Usted está enviando a una revista que requiere una reproducibilidad en contenedores (por ejemplo, computo)

Para la gran mayoría de los documentos de ciencia y física de materiales computacionales, Conda o UV es la mejor opción: es más simple, más rápido y suficiente para la reproducibilidad que necesitan los revisores y los lectores.

Una nota práctica sobre las expectativas de la revista

La lista de comprobación de REPRO documenta la heterogeneidad de las políticas de reproducibilidad de las revistas. Algunas revistas (como Biometric Journal o Journal of the American Statistical Association) requieren verificaciones activas de reproducibilidad de los editores dedicados. Otros (como The BMJ) requieren el envío del código pero no realizan comprobaciones de ejecución independientes.

Para el trabajo de simulación computacional, la expectativa mínima en la mayoría de las revistas es:

• Disponibilidad del código: El código de análisis debe proporcionarse como un archivo complementario o en un repositorio abierto (Github, Zenodo)
• Disponibilidad de datos: Los datos utilizados para el análisis deben estar disponibles públicamente o justificados
• Especificación del medio ambiente: Las versiones y los paquetes de software deben estar documentados

Este es el piso, no el techo. Seguir los cinco pilares y la lista de verificación de Repro coloca su trabajo sobre el piso y le indica que se toma en serio la reproducibilidad.

Siguiente pasos para su flujo de trabajo de simulación

Si es nuevo en las prácticas de simulación reproducibles, comience con los tres cambios más impactantes:

1. Agregue un archivo Léame a su proyecto con descripciones de archivos y orden de ejecución
2. Exporta tu entorno (conda env export o uv export) e inclúyelo en tu archivo
3. Establecer semillas aleatorias en cada script de simulación y usar SeedSequence para ejecuciones paralelas

Estos tres cambios por sí solos eliminarán el 80% de las fallas de reproducibilidad identificadas por Samuel & Mietén.

Si necesita ayuda para diseñar un flujo de trabajo de simulación reproducible, desde la documentación del cuaderno hasta el archivo de códigos y el envío de revistas, nuestro equipo puede proporcionar consultas sobre el diseño del flujo de trabajo, la especificación del entorno y el archivo de datos de conformidad con Fair. Contáctenos para discutir su proyecto de simulación específico. Construir una comunidad de software de investigación sostenible (cómo abordamos el desarrollo arraigado comunitario) es parte de ese proceso: la reproducibilidad mejora cuando todo el equipo comparte estándares comunes.

Conclusión

Las prácticas de publicación reproducibles para los resultados de la simulación no son un complemento opcional, son un requisito para una comunicación científica creíble. Los cinco pilares (programación alfabetizada, control de versiones, gestión del entorno, intercambio de datos, documentación) y la lista de verificación de Repro proporcionan una base estructurada y procesable para la reproducibilidad que se aplica en las disciplinas computacionales.

la escala de la brecha de reproducibilidad: 12,4% de reproducción idéntica exitosa en el Samuel & Estudio Miechen: es un llamado a la acción. Cada flujo de trabajo de simulación que incluye un archivo Léame, un archivo de entorno y Seeds deterministas cierra una porción medible de esa brecha. La inversión es modesta: horas, no meses. La devolución es la capacidad de cualquier lector, revisor o futuro investigador para verificar sus resultados de forma independiente.

Para el investigador computacional, la reproducibilidad no es meramente una virtud metodológica, es la base de la credibilidad científica. Los cinco pilares te dan un marco. La lista de comprobación de reproducción le da una lista de verificación. Las herramientas (GIT, Conda, Zenodo) están disponibles. Lo que queda es la decisión de usarlos.

PF

¿Cuál es el marco de cinco pilares para la reproducibilidad?

Los cinco pilares, propuestos por Ziemann et al. (2023) son programación alfabetizada, control de versiones de código, control de entorno de cálculo, intercambio de datos persistente y documentación. Forman un marco estructurado para documentar y compartir flujos de trabajo computacionales reproducibles.

¿Qué es la lista de verificación de la reproducción?

La Lista de Verificación de Repro, publicada por Hornung et al. (2026), es una herramienta multidisciplinaria concisa para crear análisis reproducibles. Cubre la estructura de código y datos, requisitos Léame, especificación del entorno, disponibilidad de datos, generación de números aleatorios deterministas y resultados intermedios.

¿Por qué los cuadernos de Jupyter fallan con tanta frecuencia?

Samuel y Mietchen (2024) encontraron que el 87,6% de los portátiles basados en Python resultaron en excepciones durante la repetición automática. Las causas principales son las dependencias faltantes o en conflicto (ModuleNotFoundError y ImportError), rutas de archivo no resueltas (FileNotFoundError) y generación de números aleatorios no deterministas.

¿Cómo elijo entre Conda y Docker?

Use Conda (o UV) para la mayoría de los flujos de trabajo de simulación basados en Python: es más simple, más rápido y suficiente para especificar versiones exactas de paquetes. Utilice Docker cuando necesite aislamiento completo en los sistemas operativos o cuando su flujo de trabajo dependa de los solucionadores de C++/Fortran compilados.

¿Cómo puedo hacer que los resultados de mi simulación sean reproducibles sin compartir datos sin procesar?

Genera datos sintéticos que imiten la estructura computacional de tus datos reales. La lista de verificación de repro recomienda usar paquetes como synthpop o simdata en R, o numpy.random en Python, para crear datos de prueba sintéticos que permitan una verificación independiente de su código de análisis.