From 82da80071db89b3ac231d9ff0f868448266f3a47 Mon Sep 17 00:00:00 2001 From: Martin DAVY Date: Tue, 14 Dec 2021 18:53:44 +0100 Subject: [PATCH] update journal module 3 et debut du journal module 4 --- journal/module_3.html | 76 ++++++++++- journal/module_3.md | 2 +- journal/module_4.html | 305 ++++++++++++++++++++++++++++++++++++++++++ journal/module_4.md | 168 +++++++++++++++++++++++ 4 files changed, 548 insertions(+), 3 deletions(-) create mode 100644 journal/module_4.html create mode 100644 journal/module_4.md diff --git a/journal/module_3.html b/journal/module_3.html index 94eea11..3754c89 100644 --- a/journal/module_3.html +++ b/journal/module_3.html @@ -169,8 +169,80 @@ pre code {

Module 3 : La main à la pâte, une analyse réplicable

-
-

pouet

+
+

0. Introduction

+
+

Objectifs

+
    +
  • Apprendre à réaliser une analyse de données de façon reproductible et traçable
    • +
  • Maitrîser quelques bonnes pratiques pour la préparation des documents computationnels
    • +
+
+
+
+

1. Une analyse réplicable, c’est quoi ?

+
+

Dans une analyse traditionnelle

+
    +
  1. concentre sur les résultats
    2. +
  2. montre simplement un résumé méthodologique des méthodes utilisées
    3. +
  3. discussion pour exposer entre autres les conclusion de cette analyse
    4. +
+
+
+

Dans une analyse réplicable

+
    +
  1. présentation des résultats
    2. +
  2. fournir le code qui à permit de génèrer ces résultats avec un explication détaillée du code et des choix fait
    3. +
  3. discussion (identique à l’analyse traditionnelle)
    4. +
+
+
+

Pourquoi faire réplicable alors que c’est plus d’effort ?

+
    +
  • Facile à refaire si les données changent
    • +
  • facile à modifier
    • +
  • facile à inspecter et vérifier (plus de confiance)
    • +
+
+
+
+

2. Etude de cas : l’incidence de syndromes grippaux

+

Présentation du jeu de données qui va servir comme exemple dans ce module

+

Données qui viennent du réseau sentinelles

+

Ne pas supprimer les lignes vides directement dans le fichier texte, pas de modification à la main Tout doit se faire dans le code

+

La date (en semaine) est au format ISO8601 dans le fichier:

+
+

il y a deux façons différentes de procéder : on peut donner l’année, le mois, et le jour du mois, ou on peut donner l’année, la semaine, et le jour de la semaine. Le 8 août 2018 peut donc être écrit 2018-08-08 ou 2018-W32-3, car il s’agit du troisième jour (mercredi) de la semaine 32 de l’année 2018.

+
+
+
+

3B. Importer les données avec RStudio/R

+
    +
  • lecture des données directement depuis la source (url)
    • +
  • Faire attention aux données manquantes avant l’analyse
    • +
+
+
+

4B. Vérification et inspection avec RStudio/R

+
    +
  • Pré-traitement des données +
      +
    • Adapter aux conventions des logiciels
      • +
    • Faciliter l’analyse
      • +
    • +
  • Vérifier autant que possible +
      +
    • inspection visuelle
      • +
    • code de validation
      • +
    • +
+
+
+

5B. Questions et réponses avec RStudio/R

+

Une analyse réplicable doit contenir toutes les étapes de traitement des données sous une forme exécutable.

+

Il est important d’expliquer tous les choix qui peuvent influencer les résultats.

+

Ceci nécessite d’exposer beaucoup de détail techniques, parce que c’est à ce niveau qu’on fait le plus d’erreur.

diff --git a/journal/module_3.md b/journal/module_3.md index f5bb451..5e2dcb6 100644 --- a/journal/module_3.md +++ b/journal/module_3.md @@ -58,4 +58,4 @@ Une analyse réplicable doit contenir **toutes les étapes** de traitement des d Il est important d'**expliquer** tous les choix qui peuvent influencer les résultats. -Ceci nécessite d'exposer beaucoup de **détail techniques**, parce que c'est à ce niveau qu'on fait le plus d'erreur. \ No newline at end of file +Ceci nécessite d'exposer beaucoup de **détail techniques**, parce que c'est à ce niveau qu'on fait le plus d'erreur. diff --git a/journal/module_4.html b/journal/module_4.html new file mode 100644 index 0000000..f47f5d8 --- /dev/null +++ b/journal/module_4.html @@ -0,0 +1,305 @@ + + + + + + + + + + + + + +module_4 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + + + + +
+

Module 4 : Vers une étude reproductible, la réalité du terrain

+
+

0. Introduction

+
+

Objectifs

+
    +
  • Repliquer le travail de quelqu’un d’autre
    • +
  • Comprendre les difficultés techniques qui se présentent lors du passage de l’exercice à la vraie vie
    • +
  • Etudier quelques pistes de solutions
    • +
+

Les enfers de la recherche reproductible

+
    +
  • L’enfer des données
    • +
  • L’enfer du logiciel
    • +
  • L’enfer du calcul
    • +
+
+
+
+

1. L’enfer des données

+

Elles se présentent de nature diverse (non-homogéne) - colonne pas de même longueur - les données peuvent être des suites chronologique et des images, etc

+

Elles sont trop grosse -> besoin de les stocker au format binaire

+

Garder les métadonnées au format texte ! Pour rajouter des informations plus facilement. Ces metadonnées sont vitales pour une recherche reproductible.

+

Le boustime correspond à l’ordre d’encode au format binaire. Le petit-boutisme correspond à l’ordre croissant des valeur binaire (1,2,4,8,…) tandis que le grand boutisme correspond à l’ordre décroissant (…,8,4,2,1).

+

Ce boutisme peut changer en fonction du système d’exploitation ce qui pose des problème dans la reproductibilité.

+

Un stockage binaire doit spécifier le boutisme utiliser pour une recherche reproductible

+

Format binaires pour :

+
    +
  • travailler sur de grosse données de nature différentes
    • +
  • stocker les métadonnées et les données
    • +
  • un boutisme fixé
    • +
+

Deux format repondent à ces critères: 1. FITS (1981 et toujours à jours, dev par des astrophysiciens) Format assez général pour être utilisé dans plusieurs contextes (bibliothéque vatican)

+

structure:

+
    +
  • un ou plusieurs segments: Header/Data Units (HDUs)
    • +
  • contitution HDU: +
      +
    • une en-tête (header unit)
      • +
    • données (data Unit) : optionnelles
      • +
    • +
  • en-tête = paires mots clés / valeurs -> métadonnées
    • +
  • données tableaux binaire (une à 999 dimension) ou tables (texte ou bianire)
    • +
+

manipulation:

+
    +
  • bibliothéque C
    • +
  • PyFITS pour python
    • +
  • FITSio pour R
    • +
+

2. HDF5 (dev par National Center for SuperComputing Applications, 5eme version) structure:

+
    +
  • ressemble à une arboraissance de fichier
    • +
  • élément structurant est le group (répertoire) qui contient un ou plusieurs dataset (fichier)
    • +
  • les group peuvent être imbriqués
    • +
  • pas de structure imposé pour les métadonnées
    • +
  • idem pour les données (on peut y stocker un article)
    • +
+

manipulation:

+
    +
  • bibliothéque C plus compliqué que celle pour le format FITS car le format HDF5 est plus “souple” +
      +
    • bibliothéque vient avec l’application HDFView (codé en java) pour l’exploration
      • +
    • +
  • h5py pour python
    • +
  • h5, hdf5r et rhdf5 pour R
    • +
+
+

L’archivage

+
    +
  • zenodo -> cern
    • +
  • figshare -> privé
    • +
+
+
+

conclusion

+

les vraies données:

+
    +
  • grosse et problème de structure
    • +
  • complexes et ont besoin de métadonnées
    • +
  • Format FITS et HDF5 sont des solution de formatage de ces données
    • +
  • En compléxité et fléxibilité: FITS < HDF5
    • +
  • archivage pour stockage pérenne et accessible
    • +
+
+
+
+ + + + +
+ + + + + + + + + + + + + + + diff --git a/journal/module_4.md b/journal/module_4.md new file mode 100644 index 0000000..0036f4c --- /dev/null +++ b/journal/module_4.md @@ -0,0 +1,168 @@ +# Module 4 : Vers une étude reproductible, la réalité du terrain + +## 0. Introduction + +### Objectifs + +- Repliquer le travail de quelqu'un d'autre +- Comprendre les difficultés techniques qui se présentent lors du passage de l'exercice à la vraie vie +- Etudier quelques pistes de solutions + +**Les enfers** de la recherche reproductible + +- L'enfer des données +- L'enfer du logiciel +- L'enfer du calcul + +## 1. **L'enfer des données** + +Elles se présentent de nature diverse (non-homogéne) + - colonne pas de même longueur + - les données peuvent être des suites chronologique **et** des images, etc + +Elles sont trop grosse -> besoin de les stocker au format binaire + +Garder les métadonnées au format texte ! Pour rajouter des informations plus facilement. Ces metadonnées sont vitales pour une recherche reproductible. + +Le *boustime* correspond à l'ordre d'encode au format binaire. Le *petit-boutisme* correspond à l'ordre croissant des valeur binaire (1,2,4,8,...) tandis que le *grand boutisme* correspond à l'ordre décroissant (...,8,4,2,1). + +Ce *boutisme* peut changer en fonction du système d'exploitation ce qui pose des problème dans la reproductibilité. + +Un stockage binaire doit spécifier le boutisme utiliser pour une recherche reproductible + +Format binaires pour : + +- travailler sur de grosse données de nature différentes +- stocker les métadonnées et les données +- un boutisme fixé + +Deux format repondent à ces critères: +**1. FITS (1981 et toujours à jours, dev par des astrophysiciens)** +Format assez général pour être utilisé dans plusieurs contextes (bibliothéque vatican) + +structure: + +- un ou plusieurs segments: Header/Data Units (HDUs) +- contitution HDU: + - une en-tête (header unit) + - données (data Unit) : optionnelles +- en-tête = paires mots clés / valeurs -> métadonnées +- données tableaux binaire (une à 999 dimension) ou tables (texte ou bianire) + +manipulation: + +- bibliothéque C +- PyFITS pour python +- FITSio pour R + +**2. HDF5 (dev par National Center for SuperComputing Applications, 5eme version)** +structure: + +- ressemble à une arboraissance de fichier +- élément structurant est le *group* (répertoire) qui contient un ou plusieurs *dataset* (fichier) +- les *group* peuvent être imbriqués +- pas de structure imposé pour les métadonnées +- idem pour les données (on peut y stocker un article) + +manipulation: + +- bibliothéque C plus compliqué que celle pour le format FITS car le format HDF5 est plus "souple" + - bibliothéque vient avec l'application HDFView (codé en java) pour l'exploration +- h5py pour python +- h5, hdf5r et rhdf5 pour R + + +### L'archivage +- zenodo -> cern +- figshare -> privé + +### conclusion +les vraies données: + +- grosse et problème de structure +- complexes et ont besoin de métadonnées +- Format FITS et HDF5 sont des solution de formatage de ces données +- En compléxité et fléxibilité: FITS < HDF5 +- archivage pour stockage pérenne et accessible + + +## L'enfer du logiciel + +### Passage à l'échelle : les codes complexes + +Notebook long devient vraiment difficile à lire + +- un vrai plat de spaghettis + - pas de vision d'ensemble + - interaction entre plusieurs langages = **danger** + +Utilisation d'un workflow pour bien comprendre l'ensemble du code, avec représentation en graphe + +**Workflow** + +- vue de haut niveau plus claire +- composition de codes et mouvements de données explicites +- partage, réutilisation, et exécution plus sûre +- le notebook en est une forme à la fois appauvrie et plus riche +- pas de façon simple de passer d'un notebook à un workflow + +exemples: + +- galaxy, kepler, taverna, pegasus, collective knowledge, vistrails +- **légers**: dask, frake, swift, snakemake, makefile... +- **hybrides**: SOS-notebook, ... + +**L'usine à gaz des calculs coûteux** +Calcul interminable qui peuvent rendre le notebook inutilisable + +- jupyter et les supercalculateurs : en dev +- checkpoint et cache +- workflow permet de passer à l'échelle (checkpoint naturel) + + +### Passage à l'échelle: les environnements complexes +l'horreur des dépendance + +Pas de standard pour la gestion des éco-systèmes + +gestionnaire de paquet: + +- linux: apt, rpm, yum +- macOS X: brew, McPorts, Fink +- Windows : Chocolatey, scoop + +Il faut controler l'environement dans lequel on travaille + +sur VM ou conteneur + +**Conserver le bazar**: capture automatique de l'environnement, CDE, ReproZip + +**Faire le ménage**: partir d'un environnment vierge, installer que le nécessaire et l'expliciter, docker/singularity, guix/nix + +conteneur: aucune bibliothéque de la machine sera utilisée + +### l'épreuve du temps +Probleme de repro FreeSurfer -> resultat different entre windows/linux/!= os mac + +orgmode aussi + +outil à dev rapide + +- évolution rapide et peu poser problème + - besoin de vérifier la reconstructibilité et la fonctionnalité de ces environnements (intégration continue et test de non régression) + +ce restreindre a ce qui est maitrisable (c / cpp) + +L'archivage + +- git (hub, lab) stable mais pérenne ? code space fin a cause de pirate +- software heritage +- hal + +Gestion de l'environnement +- périnité de l'accés à dockerhub, nix repo, code ocean ? +- une fois environnement gelé, quelle est la pérennité d'une VM, d'une image docker ? + +Concerver le plus d'info possible en automatisant +- logiciel, version, procédures d'installation + -- 2.18.1