Reading Time: 20 minutes

Versiones y procedencias de datos de Python: DVC, DVC y flujos de trabajo científicos

El control de versiones de datos en la simulación científica no se trata de rastrear los cambios de código: Git ya lo maneja perfectamente bien. Se trata de rastrear qué combinación específica de archivo de datos, confirmación de código y archivo de parámetros produjo un resultado particular. Esa distinción es lo que separa un frágil flujo de trabajo experimental de una canalización de simulación reproducible.

La herramienta más ampliamente adoptada para esto es DVC (Data Version Control), que amplía el modelo de versiones de Git para manejar grandes conjuntos de datos y etapas de canalización. Este artículo cubre la implementación práctica de DVC para flujos de trabajo científicos: construcción de tuberías con dvc.yaml, aislamiento de parámetros con params.yaml, integración HPC/SLURM y seguimiento de procedencia de W3C Prov-JSON, para que pueda crear campañas de simulación deterministas que sobreviven a la rotación de equipos, la migración de hardware y los ciclos de vida de los proyectos durante años.

Comida clave

  • Valor central de DVC: Los archivos de canalización (dvc.yaml) hacen que las simulaciones sean conscientes de la dependencia, por lo que dvc repro vuelve a ejecutar solo lo que cambió
  • Reproductibilidad versionada: DVC vincula las instantáneas de datos (.dvc archivos), confirmaciones de código (git) y archivos de parámetros (params.yaml) en unidades de experimento reproducibles
  • Integración de HPC: la programación de lotes de SLURM envuelve el DVC para la ejecución de la canalización nativa del clúster sin intervención manual
  • Estándares de procedencia: W3C Prov-JSON (YPROV4ML) surge como un formato interoperable complementario al empaque RO-Crate
  • DVC vs Datalad: elija DVC para experimentos orientados a canalizaciones; Elija Datalad para la curación de datos a largo plazo y conjuntos de datos distribuidos

Por qué falla el control de versiones estándar para los flujos de trabajo de simulación

Git es excelente para el seguimiento de los cambios de código. Es terrible para el seguimiento de los cambios de datos.

Cuando ejecuta un cálculo de relajación DFT, Git no puede almacenar el archivo de estructura de cristales resultante .xyz (a menudo decenas de MB). Puede copiarlo a una unidad compartida, o agregar su hash SHA-256 a un archivo de texto, o depender de la memoria. Los tres enfoques se rompen cuando cambia la fuente de datos, cuando necesita compartir con colaboradores que no tienen acceso a la unidad compartida, o cuando regresa seis meses después y olvida qué conjunto de parámetros produjo la estructura de menor energía.

Las herramientas de versionado de datos resuelven esto desacoplando seguimiento de datos desde Seguimiento de código. Almacenan archivos reales en almacenamiento remoto (Google Drive, S3, un NAS compartido o incluso otro repositorio de Git) y registran archivos de puntero ligeros en el repositorio de Git. Los archivos de puntero (normalmente pequeños archivos .dvc o las referencias de enlaces simbólicos de Git-Annex contienen metadatos (sunción de comprobación, ubicación remota, etiqueta de versión) sin duplicar los datos reales.

Esta separación es importante para los flujos de trabajo de simulación porque el volumen de datos se escala independientemente del volumen de código. Una sola campaña de simulación puede producir miles de archivos de trayectoria, mientras que los scripts de Python que los generan permanecen en unos pocos cientos de líneas.

La brecha de la tubería

La mayoría de los investigadores comienzan con el seguimiento de datos ad-hoc: un script bash que ejecuta cálculos en secuencia, con los resultados copiados en un directorio results/ y los números finales pegados en una hoja de Google. Esto funciona para pequeños proyectos. Se descompone cuando:

  1. Re-Ejecución con diferentes parámetros — Debe recordar qué archivo params.yaml se utilizó y volver a ejecutar sólo las etapas modificadas
  2. Errores de depuración: debe saber si el error proviene de daños de datos, cambios de código o desajuste de parámetros
  3. Pasa de equipo — Un nuevo estudiante no puede reconstruir la canalización a partir de un script bash y una carpeta de archivos huérfanos

El archivo de definición de canalización de DVC (dvc.yaml) aborda esta brecha al declarar etapas con dependencias y salidas explícitas. Cada etapa se vuelve a ejecutar solo cuando cambian sus dependencias (dvc repro <stage>), lo que hace que las campañas de simulación sean más eficientes al volver a ejecutar cálculos con diferentes parámetros.

Construcción de tuberías de DVC para flujos de trabajo científicos

Un archivo de canalización de DVC es un documento YAML declarativo que mapea cómo sus pasos de simulación dependen unos de otros. Aquí hay un ejemplo concreto para un flujo de trabajo de ciencia de materiales computacionales:

# dvc.yaml — DFT relaxation and energy calculation pipeline

stages:
  relax:
    cmd: python src/relax.py
    deps:
    - data/raw_crystal_structure.xyz
    - src/relax.py
    params:
    - params.yaml
    outs:
    - results/relaxed_structure.xyz

  energy:
    cmd: python src/energy.py
    deps:
    - results/relaxed_structure.xyz
    - src/energy.py
    params:
    - params.yaml
    outs:
    - results/energies.txt
    metrics:
    - results/energies.txt

  visualize:
    cmd: python src/plot.py
    deps:
    - results/energies.txt
    - src/plot.py
    outs:
    - figures/energy_plot.png

Cada etapa declara:

  • cmd: El comando que genera las salidas de esta etapa
  • deps: archivos que, si se cambia, activan la repetición de esta etapa
  • params: Archivos de parámetros que, si se cambia, activan la repetición de esta etapa.
  • outs: archivos producidos por esta etapa (seguido como versiones de datos)
  • metrics: archivos que DVC rastrea numéricamente para la comparación de experimentos

Por qué params.yaml importa

El archivo params.yaml aísla los parámetros de simulación de los scripts de ejecución. Esto es fundamental para los flujos de trabajo de Ciencias de Materiales donde el mismo código de simulación se ejecuta cientos de veces con diferentes parámetros:

# params.yaml
simulator:
  cutoff_energy: 500  # eV
  kpoints: [8, 8, 8]
  tolerance: 1e-6
  
optimization:
  max_steps: 200
  algorithm: ionic

Cuando cambia tolerance de 1e-6 a 1e-8 y ejecuta dvc repro, DVC detecta el cambio de params.yaml y vuelve a ejecutar todas las etapas que dependen de él. El archivo relaxed_structure.xyz resultante obtiene una nueva etiqueta de versión. La versión anterior permanece disponible en la memoria caché: no pierdes carreras históricas.

Para los barridos de parámetros, puede usar --set-param para anular los valores sin modificar el archivo:

dvc exp run --set-param sim.tolerance=1e-8 --set-param sim.cutoff_energy=450

Esto crea una nueva rama de experimento, que conserva tanto las ejecuciones originales como las modificadas en su historial de canalizaciones.

Reproducibilidad versionada: contribución conceptual del DVC

El blog de DVC (diciembre de 2021) introdujo la «reproducibilidad en versiones» como la capacidad de recrear no solo un resultado, sino el estado experimental exacto que lo produjo. Esto distingue el DVC de la versión genérica:

  • Versionado estándar Realiza un seguimiento de los cambios en los archivos a lo largo del tiempo (propósito de Git)
  • Reproducibilidad versionada Realiza un seguimiento de qué versión de datos, confirmación de código y combinación de archivos de parámetros específicos produjo un resultado determinado (propósito de DVC)

DVC logra esto al vincular tres artefactos versionados independientemente:

Artefacto Sistema de versiones lo que rastrea
.dvc Archivos de puntero dvc Versión del archivo de datos + ubicación remota + suma de verificación
GIT comete descifrador Versión de código + mensaje de confirmación + diferencial
params.yaml descifrador Versión del archivo de parámetros + cambios en el nivel del campo

La combinación de estos tres crea una unidad reproducible: un «experimento versionado» que se puede reconstruir de forma aislada. Esto importa para la simulación porque los experimentos se refinan iterativamente. Los investigadores necesitan saber «qué funcionó» y poder reproducirlo sin volver a ejecutar cada paso intermedio.

Implicaciones prácticas

Cuando un revisor solicita los datos detrás de una figura publicada, puede proporcionar:

  1. El hash de confirmación de Git (versión de código)
  2. La referencia del archivo de puntero .dvc (versión de datos)
  3. El archivo params.yaml en ese compromiso (versión de parámetro)

Combinados, estos tres artefactos son suficientes para reproducir el resultado en cualquier máquina. Este es el estándar de oro para la reproducibilidad de la simulación: mucho más allá de los contenedores (que congelan los entornos de código) o los repositorios de Git desnudos (que no pueden manejar datos de gran tamaño).

Colas de experimentos y gestión

La gestión de experimentos de DVC (dvc exp) extiende el modelo de canalización para admitir experimentos concurrentes y en cola:

# Run a single experiment with custom parameters
dvc exp run -S sim.tolerance=1e-8

# Queue multiple experiments
dvc exp run --queue -S sim.tolerance=1e-8
dvc exp run --queue -S sim.tolerance=1e-6
dvc exp run --queue -S sim.tolerance=1e-5

# Execute queued experiments
dvc exp run

El indicador --queue difiere la ejecución, lo que le permite preparar múltiples experimentos y ejecutarlos por lotes de forma secuencial. Esto es valioso para los experimentos computacionales que se ejecutan durante horas o días; puede poner en cola un barrido de parámetros durante la noche sin iniciar manualmente cada ejecución.

Para la comparación de experimentos, DVClive proporciona seguimiento de métricas en tiempo real:

# src/metrics.py — DVCLive integration
from dvclive import Live

with Live() as live:
    for step in range(n_iterations):
        result = run_step(step)
        live.step = step
        live.log("energy", result["total_energy"])
        live.log("forces", result["max_force"])

Esto produce un panel de comparación interactivo donde puede ver cómo evolucionan la energía y las fuerzas a través de los barridos de parámetros.

Ejecución de canalizaciones de DVC en clústeres de HPC

La mayoría de los científicos computacionales no ejecutan tuberías en computadoras portátiles. Los ejecutan en clústeres con SLURM, PBS o programadores LSF. DVC se integra con SLURM a través de la envoltura srun, permitiendo la ejecución de canalización nativa de clúster:

# Run a single pipeline stage with SLURM resource allocation
srun dvc repro -n relax --job slurm-job.sh

# Run all pipeline stages on the cluster
srun dvc repro

El indicador --job le dice a DVC que ejecute cada etapa a través del programador de trabajo de SLURM, manejando automáticamente:

  • Asignación de recursos específicos del clúster (memoria, CPU, nodos GPU)
  • Ejecución en modo por lotes sin intervención manual
  • Cola de trabajo automática para etapas de tubería
  • Integración con sistemas de archivos y almacenamiento específicos de clúster (lustre, GPFS, BEEGFS)

ARXIV 2505.06558v2 (septiembre de 2025) demuestra esta integración para los flujos de trabajo de materiales-ciencia que ejecutan cálculos DFT en clústeres HPC. La ventaja clave es que dvc repro se vuelve consciente del clúster: si una etapa falla o sus dependencias cambian, SLURM maneja la asignación de recursos para volver a ejecutar solo las etapas necesarias.

Consideraciones de almacenamiento en clúster

El almacenamiento remoto de DVC funciona bien con sistemas de archivos de clúster. Puede configurar DVC para utilizar el sistema de archivos GPFS Lustre o GPFS como un DVC Remote:

# Configure a cluster storage remote
dvc remote modify cluster_storage token_url "https://cluster-storage.example.com"

Esto evita la sobrecarga de copiar datos hacia/desde el almacenamiento en la nube externo y mantiene la canalización autocontenida dentro de la jerarquía de almacenamiento del clúster.

Seguimiento de procedencia W3C Prov-JSON

Si bien DVC rastrea las etapas de la canalización y las versiones de datos, no produce de forma nativa un gráfico de procedencia accionable por máquina. Para eso, necesita un estándar de procedencia, y el formato emergente es W3C Prov-JSON.

YPROV4ML (ARXIV julio de 2025) implementa la procedencia W3C Prov-JSON con modificaciones mínimas de código. captura:

  • Quién ejecutó el experimento (identidad de usuario)
  • Qué se utilizaron los datos y el código (origen de origen)
  • cómo corrió el experimento (procedencia de ejecución)
  • Por qué (motivación opcional, vinculada a los objetivos de la investigación)

La salida es un gráfico Prov-JSON: un gráfico dirigido donde los nodos representan entidades (archivos, parámetros, confirmaciones de código) y los bordes representan relaciones (derivado, producido por, usado por). Este formato permite:

  • Interoperabilidad entre sistemas de procedencia: Prov-JSON es legible por máquina y se puede consultar con bases de datos SPARQL o Graph
  • Cumplimiento de datos justos: los gráficos Prov-JSON cumplen los principios justos al documentar las condiciones de linaje y reutilización de datos
  • Colaboración interinstitucional: Prov-JSON es un estándar W3C, por lo que los gráficos de procedencia de diferentes instituciones son compatibles

Prov-JSON vs Ro-Crate

Es útil distinguir Prov-JSON de RO-Crate, ya que ambos aparecen en discusiones de reproducibilidad:

Aspecto caja de cambio Promoción
Propósito Formato de paquete para metadatos enriquecidos Formato de datos para gráficos de procedencia
Alcance Conjunto de datos completo + recursos asociados Ejecución de linaje y dependencias
Formato JSON-LD JSON (estándar PROV)
interoperabilidad Paquete autónomo Basado en gráficos, consultable
Relación Complementaria, no compitiendo

Abordan diferentes capas de reproducibilidad. RO-Crate empaqueta su conjunto de datos con metadatos. Prov-JSON rastrea el linaje computacional de cómo se produjo ese conjunto de datos. El uso de ambos proporciona una reproducibilidad completa: «Aquí están los datos» (ro-Crate) más «Así es como se produjo» (Prov-JSON).

Cuándo usar DVC vs Datalad vs Bibliotecas compatibles con Prov

Elegir entre DVC, Datalad y bibliotecas compatibles con Prov depende de sus patrones de flujo de trabajo:

Criterio dvc drogadicto Bibliotecas de PRO
Caso de uso principal Experimentos orientados a tuberías Curación de datos a largo plazo procedencia accionable a máquina
Tamaño de los datos Archivos grandes (modelos, simulaciones) Grandes conjuntos de datos distribuidos N/A (enfocado en metadatos)
Modelo de ejecución Pipeline basado en etapas (dvc repro) Basado en comandos (datalad run) Basado en decorador
Integración HPC srun dvc repro Git-anexo nativo + SSH configurable
Salida de procedencia .dvc Archivos + Historial de Git Enlaces simbólicos de Git-Anex + registro de Git Gráfico Provincia JSON
mejor para Materiales-Ciencias de Ciencias, Barridos de Parámetros Curación de repositorios a largo plazo, cumplimiento de ofertas Datos justos, procedencia interinstitucional

DVC es adecuado para usted si:

  • Su flujo de trabajo tiene varias etapas dependientes (relajación → cálculo de propiedades → visualización)
  • Necesita barridos de parámetros con repetición automática
  • Desea realizar un seguimiento de qué combinación de parámetros produjo el resultado de energía más baja

Datalad es adecuado para usted si:

  • Estás curando un repositorio de conjunto de datos a largo plazo
  • Necesita enlaces simbólicos de Git-Anex para un manejo eficiente de archivos grandes
  • Estás trabajando con conjuntos de datos distribuidos en todas las instituciones
  • Necesitas Cumplimiento de Ofertas (Común en Neuroimagen)

Las bibliotecas que cumplen con Prov son adecuadas para usted si:

  • Necesita procedencia accionable a máquina para un cumplimiento justo
  • Desea un gráfico de procedencia consultable para el linaje de datos
  • Estás colaborando entre instituciones con diferentes sistemas de procedencia
  • Estás publicando en un repositorio de datos justo

Poniéndolo en común, un flujo de trabajo práctico

Aquí hay un patrón de flujo de trabajo práctico que combina todos los conceptos anteriores:

# 1. Initialize the repository
git init
dvc init

# 2. Add the data
dvc add data/raw_crystal_structure.xyz

# 3. Run the pipeline
dvc repro

# 4. Check the results
dvc metrics show results/energies.txt

# 5. Run experiments with different parameters
dvc exp run -S sim.tolerance=1e-8 --set-param sim.cutoff_energy=550

# 6. Push data and experiments to remote
dvc push
dvc exp push
git push origin main

# 7. (Optional) Generate PROV-JSON provenance
python src/provenance.py --output provenance.json

Este patrón garantiza que cada resultado de la simulación se pueda rastrear hasta su versión de datos exacta, confirmación de código y archivo de parámetros. La salida Prov-JSON (paso 7) agrega una capa de procedencia accionable por máquina en la parte superior de la tubería de DVC.

Errores comunes: qué evitar

Error 1: Versiones de todo — No ejecute dvc add en cada archivo de salida. Solo realice un seguimiento de los archivos que son entradas a etapas posteriores o que representan los resultados finales. Los archivos intermedios (como los arreglos de fuerza sin procesar) deben permanecer en Git o ser excluidos por completo. La adición excesiva crea ruido de tubería.

Error 2: Rutas de codificación dura — No utilice rutas absolutas en dvc.yaml. Utilice rutas relativas para que la canalización funcione en diferentes máquinas y configuraciones de clúster.

Error 3: Mezcla de tipos de datos — No coloque los parámetros de simulación y los puntos de control del modelo en el mismo archivo .dvc. Mantenga los tipos de datos separados para evitar conflictos de caché.

Error 4: Ignorar la procedencia — Los archivos DVC por sí solos no son suficientes para el cumplimiento justo. Si su institución requiere gráficos de procedencia, empareje DVC con salida Prov-JSON (YPROV4ML) o RO-Crate Package.

Error 5: Olvidar params.yaml — Si los parámetros de código rígido en sus scripts en lugar de aislarlos en params.yaml, el seguimiento de parámetros de DVC se vuelve inútil. Utilice siempre params.yaml para los parámetros de simulación.

Resumen

DVC transforma los flujos de trabajo científicos de procesos frágiles y dependientes de la memoria en canalizaciones deterministas y conscientes de la dependencia. La información clave es que dvc.yaml archivos de canalización y params.yaml aislamiento de parámetros crean «reproducibilidad en versión»: la capacidad de reconstruir no solo un resultado, sino el estado experimental exacto (versión de datos + code commit + archivo de parámetros) que lo produjo. Esto va más allá de los contenedores (que congelan los entornos de código) y más allá de Git (que no pueden manejar grandes conjuntos de datos).

Para la integración de HPC, el envoltorio srun de SLURM permite la ejecución de canalización nativa del clúster sin intervención manual. Para la procedencia, W3C Prov-JSON (YPROPR4ML) surge como un formato interoperable complementario al empaque de RO-Crate, lo que permite un linaje de datos accionable por máquina que satisface los requisitos de cumplimiento justo.

La elección entre DVC, Datalad y bibliotecas compatibles con ProV depende de sus patrones de flujo de trabajo: DVC para experimentos orientados a canalizaciones, Datalad para curación de datos a largo plazo y bibliotecas PROP para gráficos de procedencia accionables por máquina. La mayoría de los equipos de simulación se benefician del uso de DVC para la ejecución de la canalización y Prov-JSON para el seguimiento de procedencias: las dos herramientas son complementarias, no compiten.

Guías relacionadas

<tool_call>
<function=fs_write_file>
<parámetro=contenido>

Versiones y procedencias de datos de Python: DVC, DVC y flujos de trabajo científicos

El control de versiones de datos en la simulación científica no se trata de rastrear los cambios de código: Git ya lo maneja perfectamente bien. Se trata de rastrear qué combinación específica de archivo de datos, confirmación de código y archivo de parámetros produjo un resultado particular. Esa distinción es lo que separa un frágil flujo de trabajo experimental de una canalización de simulación reproducible.

La herramienta más ampliamente adoptada para esto es DVC (Data Version Control), que amplía el modelo de versiones de Git para manejar grandes conjuntos de datos y etapas de canalización. Este artículo cubre la implementación práctica de DVC para flujos de trabajo científicos: construcción de tuberías con dvc.yaml, aislamiento de parámetros con params.yaml, integración HPC/SLURM y seguimiento de procedencia de W3C Prov-JSON, para que pueda crear campañas de simulación deterministas que sobreviven a la rotación de equipos, la migración de hardware y los ciclos de vida de los proyectos durante años.

Comida clave

  • Valor central de DVC: Los archivos de canalización (dvc.yaml) hacen que las simulaciones sean conscientes de la dependencia, por lo que dvc repro vuelve a ejecutar solo lo que cambió
  • Reproductibilidad versionada: DVC vincula las instantáneas de datos (.dvc archivos), confirmaciones de código (git) y archivos de parámetros (params.yaml) en unidades de experimento reproducibles
  • Integración de HPC: la programación de lotes de SLURM envuelve el DVC para la ejecución de la canalización nativa del clúster sin intervención manual
  • Estándares de procedencia: W3C Prov-JSON (YPROV4ML) surge como un formato interoperable complementario al empaque RO-Crate
  • DVC vs Datalad: elija DVC para experimentos orientados a canalizaciones; Elija Datalad para la curación de datos a largo plazo y conjuntos de datos distribuidos

Por qué falla el control de versiones estándar para los flujos de trabajo de simulación

Git es excelente para el seguimiento de los cambios de código. Es terrible para el seguimiento de los cambios de datos.

Cuando ejecuta un cálculo de relajación DFT, Git no puede almacenar el archivo de estructura de cristales resultante .xyz (a menudo decenas de MB). Puede copiarlo a una unidad compartida, o agregar su hash SHA-256 a un archivo de texto, o depender de la memoria. Los tres enfoques se rompen cuando cambia la fuente de datos, cuando necesita compartir con colaboradores que no tienen acceso a la unidad compartida, o cuando regresa seis meses después y olvida qué conjunto de parámetros produjo la estructura de menor energía.

Las herramientas de versionado de datos resuelven esto desacoplando seguimiento de datos desde Seguimiento de código. Almacenan archivos reales en almacenamiento remoto (Google Drive, S3, un NAS compartido o incluso otro repositorio de Git) y registran archivos de puntero ligeros en el repositorio de Git. Los archivos de puntero (normalmente pequeños archivos .dvc o las referencias de enlaces simbólicos de Git-Annex contienen metadatos (sunción de comprobación, ubicación remota, etiqueta de versión) sin duplicar los datos reales.

Esta separación es importante para los flujos de trabajo de simulación porque el volumen de datos se escala independientemente del volumen de código. Una sola campaña de simulación puede producir miles de archivos de trayectoria, mientras que los scripts de Python que los generan permanecen en unos pocos cientos de líneas.

La brecha de la tubería

La mayoría de los investigadores comienzan con el seguimiento de datos ad-hoc: un script bash que ejecuta cálculos en secuencia, con los resultados copiados en un directorio results/ y los números finales pegados en una hoja de Google. Esto funciona para pequeños proyectos. Se descompone cuando:

  1. Re-Ejecución con diferentes parámetros — Debe recordar qué archivo params.yaml se utilizó y volver a ejecutar sólo las etapas modificadas
  2. Errores de depuración: debe saber si el error proviene de daños de datos, cambios de código o desajuste de parámetros
  3. Pasa de equipo — Un nuevo estudiante no puede reconstruir la canalización a partir de un script bash y una carpeta de archivos huérfanos

El archivo de definición de canalización de DVC (dvc.yaml) aborda esta brecha al declarar etapas con dependencias y salidas explícitas. Cada etapa se vuelve a ejecutar solo cuando cambian sus dependencias (dvc repro <stage>), lo que hace que las campañas de simulación sean más eficientes al volver a ejecutar cálculos con diferentes parámetros.

Construcción de tuberías de DVC para flujos de trabajo científicos

Un archivo de canalización de DVC es un documento YAML declarativo que mapea cómo sus pasos de simulación dependen unos de otros. Aquí hay un ejemplo concreto para un flujo de trabajo de ciencia de materiales computacionales:

# dvc.yaml — DFT relaxation and energy calculation pipeline

stages:
  relax:
    cmd: python src/relax.py
    deps:
    - data/raw_crystal_structure.xyz
    - src/relax.py
    params:
    - params.yaml
    outs:
    - results/relaxed_structure.xyz

  energy:
    cmd: python src/energy.py
    deps:
    - results/relaxed_structure.xyz
    - src/energy.py
    params:
    - params.yaml
    outs:
    - results/energies.txt
    metrics:
    - results/energies.txt

  visualize:
    cmd: python src/plot.py
    deps:
    - results/energies.txt
    - src/plot.py
    outs:
    - figures/energy_plot.png

Cada etapa declara:

  • cmd: El comando que genera las salidas de esta etapa
  • deps: archivos que, si se cambia, activan la repetición de esta etapa
  • params: Archivos de parámetros que, si se cambia, activan la repetición de esta etapa.
  • outs: archivos producidos por esta etapa (seguido como versiones de datos)
  • metrics: archivos que DVC rastrea numéricamente para la comparación de experimentos

Por qué params.yaml importa

El archivo params.yaml aísla los parámetros de simulación de los scripts de ejecución. Esto es fundamental para los flujos de trabajo de Ciencias de Materiales donde el mismo código de simulación se ejecuta cientos de veces con diferentes parámetros:

# params.yaml
simulator:
  cutoff_energy: 500  # eV
  kpoints: [8, 8, 8]
  tolerance: 1e-6
  
optimization:
  max_steps: 200
  algorithm: ionic

Cuando cambia tolerance de 1e-6 a 1e-8 y ejecuta dvc repro, DVC detecta el cambio de params.yaml y vuelve a ejecutar todas las etapas que dependen de él. El archivo relaxed_structure.xyz resultante obtiene una nueva etiqueta de versión. La versión anterior permanece disponible en la memoria caché: no pierdes carreras históricas.

Para los barridos de parámetros, puede usar --set-param para anular los valores sin modificar el archivo:

dvc exp run --set-param sim.tolerance=1e-8 --set-param sim.cutoff_energy=450

Esto crea una nueva rama de experimento, que conserva tanto las ejecuciones originales como las modificadas en su historial de canalizaciones.

Reproducibilidad versionada: contribución conceptual del DVC

El blog de DVC (diciembre de 2021) introdujo la «reproducibilidad en versiones» como la capacidad de recrear no solo un resultado, sino el estado experimental exacto que lo produjo. Esto distingue el DVC de la versión genérica:

  • Versionado estándar Realiza un seguimiento de los cambios en los archivos a lo largo del tiempo (propósito de Git)
  • Reproducibilidad versionada Realiza un seguimiento de qué versión de datos, confirmación de código y combinación de archivos de parámetros específicos produjo un resultado determinado (propósito de DVC)

DVC logra esto al vincular tres artefactos versionados independientemente:

Artefacto Sistema de versiones lo que rastrea
.dvc Archivos de puntero dvc Versión del archivo de datos + ubicación remota + suma de verificación
GIT comete descifrador Versión de código + mensaje de confirmación + diferencial
params.yaml descifrador Versión del archivo de parámetros + cambios en el nivel del campo

La combinación de estos tres crea una unidad reproducible: un «experimento versionado» que se puede reconstruir de forma aislada. Esto importa para la simulación porque los experimentos se refinan iterativamente. Los investigadores necesitan saber «qué funcionó» y poder reproducirlo sin volver a ejecutar cada paso intermedio.

Implicaciones prácticas

Cuando un revisor solicita los datos detrás de una figura publicada, puede proporcionar:

  1. El hash de confirmación de Git (versión de código)
  2. La referencia del archivo de puntero .dvc (versión de datos)
  3. El archivo params.yaml en ese compromiso (versión de parámetro)

Combinados, estos tres artefactos son suficientes para reproducir el resultado en cualquier máquina. Este es el estándar de oro para la reproducibilidad de la simulación: mucho más allá de los contenedores (que congelan los entornos de código) o los repositorios de Git desnudos (que no pueden manejar datos de gran tamaño).

Colas de experimentos y gestión

La gestión de experimentos de DVC (dvc exp) extiende el modelo de canalización para admitir experimentos concurrentes y en cola:

# Run a single experiment with custom parameters
dvc exp run -S sim.tolerance=1e-8

# Queue multiple experiments
dvc exp run --queue -S sim.tolerance=1e-8
dvc exp run --queue -S sim.tolerance=1e-6
dvc exp run --queue -S sim.tolerance=1e-5

# Execute queued experiments
dvc exp run

El indicador --queue difiere la ejecución, lo que le permite preparar múltiples experimentos y ejecutarlos por lotes de forma secuencial. Esto es valioso para los experimentos computacionales que se ejecutan durante horas o días; puede poner en cola un barrido de parámetros durante la noche sin iniciar manualmente cada ejecución.

Para la comparación de experimentos, DVClive proporciona seguimiento de métricas en tiempo real:

# src/metrics.py — DVCLive integration
from dvclive import Live

with Live() as live:
    for step in range(n_iterations):
        result = run_step(step)
        live.step = step
        live.log("energy", result["total_energy"])
        live.log("forces", result["max_force"])

Esto produce un panel de comparación interactivo donde puede ver cómo evolucionan la energía y las fuerzas a través de los barridos de parámetros.

Ejecución de canalizaciones de DVC en clústeres de HPC

La mayoría de los científicos computacionales no ejecutan tuberías en computadoras portátiles. Los ejecutan en clústeres con SLURM, PBS o programadores LSF. DVC se integra con SLURM a través de la envoltura srun, permitiendo la ejecución de canalización nativa de clúster:

# Run a single pipeline stage with SLURM resource allocation
srun dvc repro -n relax --job slurm-job.sh

# Run all pipeline stages on the cluster
srun dvc repro

El indicador --job le dice a DVC que ejecute cada etapa a través del programador de trabajo de SLURM, manejando automáticamente:

  • Asignación de recursos específicos del clúster (memoria, CPU, nodos GPU)
  • Ejecución en modo por lotes sin intervención manual
  • Cola de trabajo automática para etapas de tubería
  • Integración con sistemas de archivos y almacenamiento específicos de clúster (lustre, GPFS, BEEGFS)

ARXIV 2505.06558v2 (septiembre de 2025) demuestra esta integración para los flujos de trabajo de materiales-ciencia que ejecutan cálculos DFT en clústeres HPC. La ventaja clave es que dvc repro se vuelve consciente del clúster: si una etapa falla o sus dependencias cambian, SLURM maneja la asignación de recursos para volver a ejecutar solo las etapas necesarias.

Consideraciones de almacenamiento en clúster

El almacenamiento remoto de DVC funciona bien con sistemas de archivos de clúster. Puede configurar DVC para utilizar el sistema de archivos GPFS Lustre o GPFS como un DVC Remote:

# Configure a cluster storage remote
dvc remote modify cluster_storage token_url "https://cluster-storage.example.com"

Esto evita la sobrecarga de copiar datos hacia/desde el almacenamiento en la nube externo y mantiene la canalización autocontenida dentro de la jerarquía de almacenamiento del clúster.

Seguimiento de procedencia W3C Prov-JSON

Si bien DVC rastrea las etapas de la canalización y las versiones de datos, no produce de forma nativa un gráfico de procedencia accionable por máquina. Para eso, necesita un estándar de procedencia, y el formato emergente es W3C Prov-JSON.

YPROV4ML (ARXIV julio de 2025) implementa la procedencia W3C Prov-JSON con modificaciones mínimas de código. captura:

  • Quién ejecutó el experimento (identidad de usuario)
  • Qué se utilizaron los datos y el código (origen de origen)
  • cómo corrió el experimento (procedencia de ejecución)
  • Por qué (motivación opcional, vinculada a los objetivos de la investigación)

La salida es un gráfico Prov-JSON: un gráfico dirigido donde los nodos representan entidades (archivos, parámetros, confirmaciones de código) y los bordes representan relaciones (derivado, producido por, usado por). Este formato permite:

  • Interoperabilidad entre sistemas de procedencia: Prov-JSON es legible por máquina y se puede consultar con bases de datos SPARQL o Graph
  • Cumplimiento de datos justos: los gráficos Prov-JSON cumplen los principios justos al documentar las condiciones de linaje y reutilización de datos
  • Colaboración interinstitucional: Prov-JSON es un estándar W3C, por lo que los gráficos de procedencia de diferentes instituciones son compatibles

Prov-JSON vs Ro-Crate

Es útil distinguir Prov-JSON de RO-Crate, ya que ambos aparecen en discusiones de reproducibilidad:

Aspecto caja de cambio Promoción
Propósito Formato de paquete para metadatos enriquecidos Formato de datos para gráficos de procedencia
Alcance Conjunto de datos completo + recursos asociados Ejecución de linaje y dependencias
Formato JSON-LD JSON (estándar PROV)
interoperabilidad Paquete autónomo Basado en gráficos, consultable
Relación Complementaria, no compitiendo

Abordan diferentes capas de reproducibilidad. RO-Crate empaqueta su conjunto de datos con metadatos. Prov-JSON rastrea el linaje computacional de cómo se produjo ese conjunto de datos. El uso de ambos proporciona una reproducibilidad completa: «Aquí están los datos» (ro-Crate) más «Así es como se produjo» (Prov-JSON).

Cuándo usar DVC vs Datalad vs Bibliotecas compatibles con Prov

Elegir entre DVC, Datalad y bibliotecas compatibles con Prov depende de sus patrones de flujo de trabajo:

Criterio dvc drogadicto Bibliotecas de PRO
Caso de uso principal Experimentos orientados a tuberías Curación de datos a largo plazo procedencia accionable a máquina
Tamaño de los datos Archivos grandes (modelos, simulaciones) Grandes conjuntos de datos distribuidos N/A (enfocado en metadatos)
Modelo de ejecución Pipeline basado en etapas (dvc repro) Basado en comandos (datalad run) Basado en decorador
Integración HPC srun dvc repro Git-anexo nativo + SSH configurable
Salida de procedencia .dvc Archivos + Historial de Git Enlaces simbólicos de Git-Anex + registro de Git Gráfico Provincia JSON
mejor para Materiales-Ciencias de Ciencias, Barridos de Parámetros Curación de repositorios a largo plazo, cumplimiento de ofertas Datos justos, procedencia interinstitucional

DVC es adecuado para usted si:

  • Su flujo de trabajo tiene varias etapas dependientes (relajación → cálculo de propiedades → visualización)
  • Necesita barridos de parámetros con repetición automática
  • Desea realizar un seguimiento de qué combinación de parámetros produjo el resultado de energía más baja

Datalad es adecuado para usted si:

  • Estás curando un repositorio de conjunto de datos a largo plazo
  • Necesita enlaces simbólicos de Git-Anex para un manejo eficiente de archivos grandes
  • Estás trabajando con conjuntos de datos distribuidos en todas las instituciones
  • Necesitas Cumplimiento de Ofertas (Común en Neuroimagen)

Las bibliotecas que cumplen con Prov son adecuadas para usted si:

  • Necesita procedencia accionable a máquina para un cumplimiento justo
  • Desea un gráfico de procedencia consultable para el linaje de datos
  • Estás colaborando entre instituciones con diferentes sistemas de procedencia
  • Estás publicando en un repositorio de datos justo

Poniéndolo en común, un flujo de trabajo práctico

Aquí hay un patrón de flujo de trabajo práctico que combina todos los conceptos anteriores:

# 1. Initialize the repository
git init
dvc init

# 2. Add the data
dvc add data/raw_crystal_structure.xyz

# 3. Run the pipeline
dvc repro

# 4. Check the results
dvc metrics show results/energies.txt

# 5. Run experiments with different parameters
dvc exp run -S sim.tolerance=1e-8 --set-param sim.cutoff_energy=550

# 6. Push data and experiments to remote
dvc push
dvc exp push
git push origin main

# 7. (Optional) Generate PROV-JSON provenance
python src/provenance.py --output provenance.json

Este patrón garantiza que cada resultado de la simulación se pueda rastrear hasta su versión de datos exacta, confirmación de código y archivo de parámetros. La salida Prov-JSON (paso 7) agrega una capa de procedencia accionable por máquina en la parte superior de la tubería de DVC.

Errores comunes: qué evitar

Error 1: Versiones de todo — No ejecute dvc add en cada archivo de salida. Solo realice un seguimiento de los archivos que son entradas a etapas posteriores o que representan los resultados finales. Los archivos intermedios (como los arreglos de fuerza sin procesar) deben permanecer en Git o ser excluidos por completo. La adición excesiva crea ruido de tubería.

Error 2: Rutas de codificación dura — No utilice rutas absolutas en dvc.yaml. Utilice rutas relativas para que la canalización funcione en diferentes máquinas y configuraciones de clúster.

Error 3: Mezcla de tipos de datos — No coloque los parámetros de simulación y los puntos de control del modelo en el mismo archivo .dvc. Mantenga los tipos de datos separados para evitar conflictos de caché.

Error 4: Ignorar la procedencia — Los archivos DVC por sí solos no son suficientes para el cumplimiento justo. Si su institución requiere gráficos de procedencia, empareje DVC con salida Prov-JSON (YPROV4ML) o RO-Crate Package.

Error 5: Olvidar params.yaml — Si los parámetros de código rígido en sus scripts en lugar de aislarlos en params.yaml, el seguimiento de parámetros de DVC se vuelve inútil. Utilice siempre params.yaml para los parámetros de simulación.

Resumen

DVC transforma los flujos de trabajo científicos de procesos frágiles y dependientes de la memoria en canalizaciones deterministas y conscientes de la dependencia. La información clave es que dvc.yaml archivos de canalización y params.yaml aislamiento de parámetros crean «reproducibilidad en versión»: la capacidad de reconstruir no solo un resultado, sino el estado experimental exacto (versión de datos + code commit + archivo de parámetros) que lo produjo. Esto va más allá de los contenedores (que congelan los entornos de código) y más allá de Git (que no pueden manejar grandes conjuntos de datos).

Para la integración de HPC, el envoltorio srun de SLURM permite la ejecución de canalización nativa del clúster sin intervención manual. Para la procedencia, W3C Prov-JSON (YPROPR4ML) surge como un formato interoperable complementario al empaque de RO-Crate, lo que permite un linaje de datos accionable por máquina que satisface los requisitos de cumplimiento justo.

La elección entre DVC, Datalad y bibliotecas compatibles con ProV depende de sus patrones de flujo de trabajo: DVC para experimentos orientados a canalizaciones, Datalad para curación de datos a largo plazo y bibliotecas PROP para gráficos de procedencia accionables por máquina. La mayoría de los equipos de simulación se benefician del uso de DVC para la ejecución de la canalización y Prov-JSON para el seguimiento de procedencias: las dos herramientas son complementarias, no compiten.

Guías relacionadas