Avant de lancer =org-babel-tangle=, il faut créer tous les répertoires qui vont accueillir les fichiers:
Avant de lancer =org-babel-tangle=, il faut créer tous les répertoires qui vont accueillir les fichiers, après en avoir supprimé des versions anciennes:
#+begin_src sh :results output :exports both
for directory in incidence_syndrome_grippal incidence_syndrome_grippal_par_region incidence_syndrome_grippal_par_region_v2
L'exécution du fichier bloque à chaque fichier de type Snakefile, malgré le fait qu'ils ont tous =:eval no=. Alors définissions une fonction qui exécute un Snakefile... sans rien faire!
#+begin_src emacs-lisp
(defun org-babel-execute:snakefile (body params)
)
#+end_src
#+RESULTS:
: org-babel-execute:snakefile
Enfin, il vaut mieux supprimer les buffers éventuellement restés d'une exécution antérieur:
#+begin_src emacs-lisp
(when (get-buffer "*snakemake1*")
(kill-buffer "*snakemake1*"))
(when (get-buffer "*snakemake2*")
(kill-buffer "*snakemake2*"))
(when (get-buffer "*snakemake3*")
(kill-buffer "*snakemake3*"))
#+end_src
#+RESULTS:
* Installer snakemake
** Linux
par les distributions
...
...
@@ -47,7 +68,7 @@ Il y a beaucoup de liberté dans la décomposition d'un calcul en tâches d'un w
Pour faire les calculs, je vais recycler le code du module 3, sans les commenter de nouveau ici.
** Préparation
Un workflow finit par utiliser beaucoup de fichiers, il est donc prudent de les regrouper dans un répertoire, avec des sous-répertoires pour les scripts et les données:
#+begin_src sh :session *snakemake* :results output :exports both
#+begin_src sh :session *snakemake1* :results output :exports both
# déjà fait: mkdir incidence_syndrome_grippal
cd incidence_syndrome_grippal
# déjà fait: mkdir data
...
...
@@ -58,30 +79,30 @@ cd incidence_syndrome_grippal
** 1ère tâche: le téléchargement des données
Pour télécharger un fichier, inutile d'écrire du code: l'utilitaire =wget= fait ce qu'il faut. La ligne de commande
#+begin_src sh :session *snakemake* :results output :exports both
#+begin_src sh :session *snakemake1* :results output :exports both
fait ce qu'il faut, et dépose les données dans le fichier =data/weekly-incidence.csv=. Je le supprime parce que je veux faire le téléchargement dans mon workflow!
#+begin_src sh :session *snakemake* ::results output :exports both
#+begin_src sh :session *snakemake1* ::results output :exports both
rm data/weekly-incidence.csv
#+end_src
#+RESULTS:
Je vais commencer la rédaction du =Snakefile=, le fichier qui déinit mon workflow:
#+begin_src :exports both :tangle incidence_syndrome_grippal/Snakefile
#+begin_src snakefile :exports code :tangle incidence_syndrome_grippal/Snakefile :mkdirp yes :eval no
rule download:
output:
"data/weekly-incidence.csv"
...
...
@@ -91,40 +112,45 @@ rule download:
Un =Snakefile= consiste de /règles/ qui définissent les tâches. Chaque règle a un nom, ici j'ai choisi /download/. Une règle liste aussi les fichiers d'entrée (aucun dans ce cas) et de sortie (notre fichier de données). Enfin, il faut dire ce qui est à faire pour exécuter la tâche, ce qui est ici la commande =wget=.
Pour exécuter cette tâche, il y a deux façons de faire: on peut demander à =snakemake= d'exécuter la règle =download=:
#+begin_src sh :session *snakemake* ::results output :exports both
#+begin_src sh :session *snakemake1* ::results output :exports both
En regardant bien ce que =snakemake= dit au deuxième tour, il s'est rendu compte qu'il n'y a rien à faire, parce que le fichier souhaité existe déjà. Voici un premier avantage important d'un workflow: une tâche n'est exécutée que s'il est nécessaire. Quand une tâche met deux heures à exécuter, c'est appréciable.
...
...
@@ -132,7 +158,7 @@ En regardant bien ce que =snakemake= dit au deuxième tour, il s'est rendu compt
La deuxième tâche est le pré-traitement: en partant du fichier téléchargé du Réseau Sentinelle, il faut extraire juste les éléments nécessaires, et il faut vérifier s'il y a des données manquantes ou des erreurs. Dans un document computationnel, j'avais procédé pas par pas, en inspectant les résultats à chaque étape. Dans mon workflow, le pré-traitement devient une seule tâche, exécutée en bloc.
Il faut donc bien réfléchir à ce qu'on attend comme résultat. En fait, il faut deux fichiers de sortie: un qui contient les données qui seront analysées par la suite, et un autre qui contient les éventuels messages d'erreur. Avec ça, la deuxième règle s'écrit assez vite:
#+begin_src :exports both :tangle incidence_syndrome_grippal/Snakefile
#+begin_src :exports code :tangle incidence_syndrome_grippal/Snakefile :mkdirp yes :eval no
rule preprocess:
input:
"data/weekly-incidence.csv"
...
...
@@ -145,7 +171,7 @@ rule preprocess:
Il y a donc un fichier d'entrée, qui est le résultat de la tâche /download/. Et il y a les deux fichiers de sortie, un pour les résultats et un pour les messages d'erreur. Enfin, pour faire le travail, j'ai opté pour un script Python cette fois. =snakemake= reconnaît le langage par l'extension =.py=.
Le contenu de ce script est presque un copier-coller d'un document computationnel du module 3, plus précisément du document que j'ai montré dans le parcours Emacs/Org-Mode:
#+begin_src python :exports both :tangle incidence_syndrome_grippal/scripts/preprocess.py
#+begin_src python :exports code :tangle incidence_syndrome_grippal/scripts/preprocess.py :mkdirp yes :eval no
# Libraries used by this script:
import datetime # for date conversion
import csv # for writing output to a CSV file
...
...
@@ -222,7 +248,7 @@ Ce qui saute aux yeux d'abord, c'est =snakemake.input[0]= comme nom de fichier.
Sinon, il y a deux modifications par rapport au code du module 3. Premièrement, les messages d'erreurs sont écrits dans un fichier. Deuxièmement, les données finales sont écrites également dans un fichier, en utilisant le format CSV.
Pour appliquer le pré-traitement, demandons à =snakemake=:
#+begin_src sh :session *snakemake* :results output :exports both
#+begin_src sh :session *snakemake1* :results output :exports both
@@ -518,17 +544,17 @@ J'ai déjà évoqué un avantage du workflow: les tâches ne sont exécutées qu
2. Un des deux fichiers =data/weekly-incidence-plot.png= et =data/weekly-incidence-plot-last-years.png= a une date de modification antérieure à la date de modification du fichier d'entrée, =data/preprocessed-weekly-incidence.csv=.
Vérifions cela, en demandant en plus à =snakemake= d'expliquer son raisonnement avec l'option =-r=:
#+begin_src sh :session *snakemake* :results output :exports both
#+begin_src sh :session *snakemake1* :results output :exports both
Attention, =snakemake= ne regarde que les fichiers listés sous "input", pas les fichiers listés sous "scripts". Autrement dit, la modification d'un script n'entraîne pas sa ré-exécution !
#+begin_src sh :session *snakemake* :results output :exports both
#+begin_src sh :session *snakemake1* :results output :exports both
Je considère ceci un défaut de =snakemake=, car le script est une donnée d'entrée du calcul tout comme la séquence de chiffres à plotter. Un petit astuce permet de corriger ce défaut (à condition d'y penser chaque fois qu'on écrit une règle !): on peut rajouter le fichier script à la liste "input":
#+begin_src :exports both
#+begin_src :exports code :eval no
rule plot:
input:
"data/preprocessed-weekly-incidence.csv",
...
...
@@ -596,7 +622,7 @@ rule plot:
#+end_src
On peut aussi demander à =snakemake= de lancer une tâche même si ceci ne lui semble pas nécessaire, avec l'option =-f= (force):
#+begin_src sh :session *snakemake* :results output :exports both
#+begin_src sh :session *snakemake1* :results output :exports both
Le plus souvent, ce qu'on veut, c'est une mise à jour de tous les résultats suite à une modification. La bonne façon d'y arriver est de rajouter une nouvelle règle, par convention appellée =all=, qui ne fait rien mais demande à l'entrée tous les fichiers créés par toutes les autres tâches :
#+begin_src :exports both :tangle incidence_syndrome_grippal/Snakefile
#+begin_src :exports code :tangle incidence_syndrome_grippal/Snakefile :mkdirp yes :eval no
rule all:
input:
"data/weekly-incidence.csv",
...
...
@@ -648,7 +674,7 @@ rule all:
#+end_src
La mise à jour complète se fait alors avec
#+begin_src sh :session *snakemake* :results output :exports both
#+begin_src sh :session *snakemake1* :results output :exports both
snakemake all
#+end_src
...
...
@@ -665,7 +691,7 @@ Job counts:
1 histogram
3
[Tue Sep 24 15:04:52 2019]
[Tue Sep 24 16:47:07 2019]
rule annual_incidence:
input: data/preprocessed-weekly-incidence.csv
output: data/annual-incidence.csv
...
...
@@ -679,11 +705,11 @@ During startup - Warning messages:
Les plus paresseux mettent la règle =all= au début du =Snakefile=, parce qu'en absence de tâche (ou fichier) nommé sur la ligne de commande, =snakemake= utilise la première régle qu'il trouve, et pour la mise à jour total, il suffit de taper =snakemake=.
Pour rédémarrer de zéro, donc exécuter toutes les tâches, on fait:
#+begin_src sh :session *snakemake* :results output :exports both
#+begin_src sh :session *snakemake1* :results output :exports both
Comme =snakemake= gère bien toutes les dépendances entre les données, il peut même nous en faire un dessin, ce qui est fort utile quand les workflows augmentent en taille:
#+begin_src sh :session *snakemake* :results output :exports both
#+begin_src sh :session *snakemake1* :results output :exports both
snakemake --forceall --dag all | dot -Tpng > graph.png
#+end_src
...
...
@@ -845,7 +871,7 @@ Pour comprendre cette ligne de commande, il faut savoir que =snakemake= produit
En regardant bien ce dessin, vous remarquez peut-être qu'il y a deux branches indépendantes. Une fois qu'on a fait "preprocess", on peut attaquer ou "plot" ou "annual_incidence" suivi de "histogram". Mais ça veut dire aussi qu'on peut exécuter ces deux branches en parallèle et gagner du temps, pourvu qu'on a un ordinateur avec au moins deux processeurs. En fait, =snakemake= s'en charge automatiquement si on lui indique combien de processeurs utiliser:
#+begin_src sh :session *snakemake* :results output :exports both
#+begin_src sh :session *snakemake1* :results output :exports both
Le workflow que je viens de montrer produit 7 fichiers. Ce n'est pas beaucoup. On peut les nommer à la main, un par un, sans difficulté. Dans la vraie vie, par exemple en bioinformatique, un workflow peut facilement gérer des centaines ou milliers de fichiers, par exemple un fichier par séquence d'acides aminés dans une étude de protéomique. Dans une telle situation, il faut définir un schéma pour nommer les fichiers de façon systématique, et introduire des boucles dans le workflow dont les itérations seront idéalement exécutées en parallèle. Je vais illustrer ceci avec une variante de l'analyse de l'incidence du syndrome grippal. Elle utilise une forme plus détaillée des données brutes dans laquelle les incidence sont repertoriées par région plutôt que pour la France entière. Il faut donc répéter le calcul de l'incidence annuelle 13 fois, une fois pour chaque région. Pour simplifier un peu, le résultat principal de ce nouveau workflow sera un fichier qui contient, pour chaque région, l'année dans laquelle l'incidence était la plus élevée. Il n'y a donc pas d'histogramme.
Et puis je vais vous montrer le =Snakefile=, tout de suite en entier, que je vais commenter après.
#+begin_src :exports both :tangle incidence_syndrome_grippal_par_region/Snakefile
#+begin_src snakefile :exports code :tangle incidence_syndrome_grippal_par_region/Snakefile :mkdirp :eval no yes
rule all:
input:
"data/peak-year-all-regions.txt"
...
...
@@ -1047,12 +1075,14 @@ rule peak_years:
"scripts/peak-years.py"
#+end_src
#+RESULTS:
Commençons en haut: j'ai mis la règle =all= au début pour pouvoir être paresseux à l'exécution: la simple commande =snakemake= déclenchera l'ensemble des calculs. Et =all=, c'est simplement le fichier qui résume les années du pic maximal pour chaque région.
Dans la règle =download=, seul le nom du fichier de données a changé par rapport à avant. J'ai trouvé le nom du fichier "par région" sur le site Web du Réseau Sentinelles. C'est après qu'il y a le plus grand changement: la définition d'une variable =REGIONS=, qui est une liste des 13 régions administratives, dont les noms sont écrits exactement comme dans le fichier des données. On devrait récupérer cette liste du fichier de façon automatique, et je montrerai plus tard comment faire. Pour l'instant, je préfère copier la liste manuellement dans le =Snakefile= afin de ne pas introduire trop de nouveautés d'aun seul coup. La variable =REGIONS= est utilisée immédiatement après, pour définir les fichiers de sortie de la règle =split_by_region=. La fonction =expand= produit une liste des noms de fichier en insérant le nom de la région au bon endroit dans le modèle.
Le rôle de la règle =split_by_region= est de découper les données téléchargées en un fichier par région, afin de pouvoir traiter les régions en parallèle et avec les même scripts que nous avons déjà. Le script appliqué par la règle est assez simple:
#+begin_src python :exports both :tangle incidence_syndrome_grippal_par_region/scripts/split-by-region.py
#+begin_src python :exports code :tangle incidence_syndrome_grippal_par_region/scripts/split-by-region.py :mkdirp yes :eval no
Snakemake nous dit d'ailleurs explicitement quelle règle a été appliquée (=annual_incidence=), avec quel fichier d'entrée (=data/preprocessed-weekly-incidence-CORSE.csv=), et avec quel fichier de sortie (=data/annual-incidence-CORSE.csv=).
A la fin du workflow, il y a une nouvelle règle, =peak_years=, qui extrait l'année du pic maximal de chaque fichier d'incience annuelle, et produit un fichier résumant ces années par région. Sa seule particularité est la spécification des fichiers d'entrée, qui utilise la fonction =expand= exactement comme on l'a vu pour les fichiers résultats de la règle =split_by_region=. Le script Python associé est assez simple:
#+begin_src python :exports both :tangle incidence_syndrome_grippal_par_region/scripts/peak-years.py
#+begin_src python :exports code :tangle incidence_syndrome_grippal_par_region/scripts/peak-years.py :mkdirp yes :eval no
Le =Snakefile= commence avec deux règles non modifiées:
#+begin_src :exports both :tangle incidence_syndrome_grippal_par_region_v2/Snakefile
#+begin_src snakefile :exports code :tangle incidence_syndrome_grippal_par_region_v2/Snakefile :eval no :mkdirp yes
rule all:
input:
"data/peak-year-all-regions.txt"
...
...
@@ -3020,7 +3051,7 @@ rule download:
#+end_src
La règle =split_by_region= devient un "checkpoint", ce qui veut dire que Snakemake reconstruit son graphe de tâches /après/ son exécution:
#+begin_src :exports both :tangle incidence_syndrome_grippal_par_region_v2/Snakefile
#+begin_src snakefile :exports code :tangle incidence_syndrome_grippal_par_region_v2/Snakefile :eval no :mkdirp yes
checkpoint split_by_region:
input:
"data/weekly-incidence-all-regions.csv"
...
...
@@ -3030,7 +3061,7 @@ checkpoint split_by_region:
"scripts/split-by-region.py"
#+end_src
La particularité d'un checkpoint est que ses fichiers de sortie ne sont pas connus d'avance. On donne donc seulement le nom d'un répertoire. C'est le répertoire entier qui est consideré le résultat de la tâche. C'est donc le script qui doit le créer:
#+begin_src python :exports both :tangle incidence_syndrome_grippal_par_region_v2/scripts/split-by-region.py
#+begin_src python :exports code :tangle incidence_syndrome_grippal_par_region_v2/scripts/split-by-region.py :mkdirp yes :eval no
import os
# Read the CSV file into memory
...
...
@@ -3072,7 +3103,7 @@ for region in regions:
#+end_src
Cette réorganisation des fichiers nécessite une petite modification des entrées de la règle =preprocess=:
#+begin_src :exports both :tangle incidence_syndrome_grippal_par_region_v2/Snakefile
#+begin_src snakefile :exports code :tangle incidence_syndrome_grippal_par_region_v2/Snakefile :eval no :mkdirp yes
rule preprocess:
input:
"data/weekly-incidence-by-region/{region}.csv"
...
...
@@ -3084,7 +3115,7 @@ rule preprocess:
#+end_src
Mais rien ne change pour les deux règles suivantes:
#+begin_src :exports both :tangle incidence_syndrome_grippal_par_region_v2/Snakefile
#+begin_src snakefile :exports code :tangle incidence_syndrome_grippal_par_region_v2/Snakefile :eval no :mkdirp yes
rule plot:
input:
"data/preprocessed-weekly-incidence-{region}.csv"
...
...
@@ -3104,7 +3135,7 @@ rule annual_incidence:
#+end_src
Enfin, c'est la règle =peak_years= qui doit changer parce qu'elle doit construire la liste des fichiers d'entrées à partir des sorties du checkpoint =split_by_regions=. Ceci nécessite du code, mais snakemake permet de définir des fonctions Python dans le =Snakefile=:
#+begin_src :exports both :tangle incidence_syndrome_grippal_par_region_v2/Snakefile
#+begin_src snakefile :exports code :tangle incidence_syndrome_grippal_par_region_v2/Snakefile :eval no :mkdirp yes
