curso-reproducibilidad-team4 / zonificacion-climatica-cte

Zonificación climática localidades españolas según severidades del Código Técnico de la Edificación
MIT License
0 stars 2 forks source link

otros consejos adicionales #20

Open jmoldon opened 2 years ago

jmoldon commented 2 years ago
  1. Os recomiendo que modifiquéis la estructura de archivos. Por ejemplo no tiene mucho sentido que en data convivan información de entrada en ign con productos de la pipeline en output. Esta estructura de archivos es genial, y realmente es útil para organizar el workflow de una manera práctica y efectiva: https://snakemake.readthedocs.io/en/stable/snakefiles/deployment.html?highlight=reproducible#distribution-and-reproducibility
├── .gitignore
├── README.md
├── LICENSE.md
├── workflow
│   ├── rules
|   │   ├── module1.smk
|   │   └── module2.smk
│   ├── envs
|   │   ├── tool1.yaml
|   │   └── tool2.yaml
│   ├── scripts
|   │   ├── script1.py
|   │   └── script2.R
│   ├── notebooks
|   │   ├── notebook1.py.ipynb
|   │   └── notebook2.r.ipynb
│   ├── report
|   │   ├── plot1.rst
|   │   └── plot2.rst
|   └── Snakefile
├── config
│   ├── config.yaml
│   └── some-sheet.tsv
├── results
└── resources

principalmente separa el workflow (en scripts, notebooks, rules (aunque pueden ir todas dentro de Snakefile), y environments) de lo que son resultados. Por ejemplo los datos que se descargan pueden ir en resources. Lo normal es guardar en Github únicamente el workflow, y los resultados solo sin son pequeños y de interés. Esto también permite borrar todos los resultados facilmente y reiniciar el workflow desde el principio.

  1. Os recomiendo tener un archivo de config.yml para gestionar archivos que actualmente están hard-coded en los scripts, principalmente el nombre del archivo data/output/Municipios.csv. Lo mismo para otras variables que puedan ser globales. Eso facilita que si en algún momento queréis usar otro archivo de input, se puede hacer fácilmente sin modificar los scripts.

  2. No recuerdo si os lo he puesto antes, pero con estos comandos podéis generar el DAG y otros diagramas, que además de ser muy chulos, sobretodo si tenéis paralización, es bueno ponerlos en el readme para que la gente vea la lógica del workflow y la secuencia de ejecuciones. Esto lo tenéis que ejecutar fuera del workflow:

    snakemake --rulegraph --forceall | dot -Tpng > rulegraph.png
    snakemake --dag --forceall | dot -Tpng > dag.png
    snakemake --filegraph --forceall | dot -Tpng > filegraph.png
  3. No es imprescindible, pero es muy útil: snakemake tiene la opción de crear logs del output que produce cada rule. Por ejemplo si ponéis prints en las funciones, etc. Cada log se guarda en un archivo independiente, así son fáciles de encontrar. Basta con añadir esto: https://snakemake.readthedocs.io/en/stable/tutorial/advanced.html?highlight=logging#step-5-logging

pachi commented 2 years ago

Está muy bien esa estructura y si, ademas, es relativamente convencional, me parece interesante migrar a algo así en el proyecto.