From 73ebae1a78448708211da07be5b520263ef2c8b7 Mon Sep 17 00:00:00 2001 From: 850ad9002e8a94b002cf8b2ee50ec6d9 <850ad9002e8a94b002cf8b2ee50ec6d9@app-learninglab.inria.fr> Date: Mon, 27 Apr 2020 16:15:33 +0000 Subject: [PATCH] Update Readme.md Module 4 --- journal/Readme.md | 111 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 111 insertions(+) diff --git a/journal/Readme.md b/journal/Readme.md index 2006607..56753c4 100644 --- a/journal/Readme.md +++ b/journal/Readme.md @@ -1,3 +1,4 @@ +:23-10-2020: # Module 1 : Cahier de notes, cahier de laboratoire ## 0. Introduction ## 1. Nous utilisons tous des cahiers de notes @@ -285,3 +286,113 @@ voir les notes du document analyse-syndrome-grippal-rstudio.Rmd ** Travail pratique évalué par les pairs ** # Module 4 : Vers une étude reproductible : la réalité du terrain +## 1. L'enfer des données +Deux "nouveaux" problèmes : lorsque nous commençons à travailler sur de "vraies" données, nous nous trouvons généralement confrontés à deux problèmes : + 1. les données sont de natures **"diverse"** + 2. les données occupent un **grand espace mémoire** + +### 1.1. Les données diverses ou non-homogènes +Les données grippales du module 3 se prêtent bien à une présentation en table (objet à 2 dimensions). +MAIS souvent la forme table doit être abandonnée car +- les colonnes n'ont pas la mm longueur +- les données peuvent être des suites chronologiques (ex données grippales ou varicelle) **et** des images, etc. + +### 1.2. Les données sont "trop grosses" + - les données numériques ne peuvent être représentées sous format texte que jusqu'à certain point + - deux considérations nous poussent à adopter un **format binaire**: + - les nombres stockés en format binaire prennent moins de place en mémoire que format texte + - les nombre en format texte doivent être de toute façon convertis en formats binaire **pour faire des calculs** + +### Ce qu'il faut garder du format texte : les **métadonnées** + - le format texte nous permet de **stocker**: + - des données i.e des nombres + - tout ce que l'on veut ... + - nous pouvons ainsi rajouter des informations sur les données: + - d'où proviennent-elles ? + - quand ont-elles été enregistrées ? + - avec quel instrument et quels paramètres ? + - etc + - Ces informations sur les données = **METADONNEES** + - elles sont **vitales** pour la mise en oeuvre de la recherche reproductible + +### Ce qu'il faut garder du format texte : le **boutisme** + - le format texte est **"universel"** (*dans l'univers de l'informatique*) + - les formats binaires tendent à changer suivant l'architecture ou le système d'exploitation + - l'entier codé sur 4 bits 1010 peut ainsi être lu comme : + - 1x1 + 0x2 + 1x4 + 0x8 = 5 --> **petit-boutisme** + - 1x8 + 0x4 + 1x2 + 0x1 = 10 --> **gros-boutisme** + - **stockage en format binaire doit spécifier le boutisme utilisé** + +--> FITS (introduit par astrophysiciens, général, HDU= en-tête + données) et HDF5 (arborisation de fichier, group=répertoire contient 1 ou +ieurs datasets) +--> stockage de métadonnées de façon pérenne + +## 2. L'enfer du logiciel +### 2.1. Passage à l'échelle : les codes complexes +Limitations et incovénients d'un document computationnel (notebook): +- lorsque le code est long, il devient difficile d'avoir une vie d'ensemble +- les interactions entre différents langages peuvent être hasardeuse car peu explicites +- il n'est pas bien adapté à des calculs longs ou impliquant de gros volumes de données +- la sauvegarde des résultats intermédiaires ou la poursuite d'un calcul après une interrupetion sont des processus généralement mannuels = source d'erreur + +**Workflow**= +- permet de mieux structurer son code et de proposer une représentation graphique de haut niveau +- il se passe d'effets de bord, ce qui diminue les risques d'erreur +- il permet d'exploiter plus facilement une machine parallèle + +Lorsque l'environnement logiciel d'un calcul n'est pas préservé, en terme de reproducibilité, +- on ne peut pas arriver à réexécuter notre calcul +- mes collègues non plus +- le résultat des calculs peut changer + +### 2.2. Passage à l'échelle : les environnements complexes +interdépendances entre librairie et package +Il faut contrôle l'environnement dans lequel on travail : +- Conserver le bazar = capture automatique de l'environnement (CDE, ReproZip, CARE) +- Faire le ménage = partir d'un environnement vierge, installer le nécessaire et l'expliciter (Docker/Singularity, Guix/Nix) + +Il sera donc très facile de figer un environnement et de le partager avec un tierce. + +### 2.3. L'épreuve du temps +Compatibilité ascendante des logiciels (évolution des versions) --> outils à développement **rapides** mais **fragiles** et **peu pérennes**! + +Il est possible de préserver l'environnement logiciel d'un calcul effectué à l'aide du langage pyhton ou R +- en utilisant un outil qui **capture automatiquement** l'ensemble des fichiers et de bibliothèques utilisées lors du calcul +- en travaillant dans un **conteneur* docker du début à la fin + +Mettre à disposition l'environnement logiciel (ss forme binaire avec une image docker par ex) d'un calcul permet à un tierce de **réexécuter ce calcul**. + +**HAL** ou **ArXiv** permet d'archiver et mettre à disposition **un article de recherche**. + +**Figshare** ou **Zenodo** permet d'archiver et de mettre à disposition des **données**. + +**Github** ou **Gitlab** et **Software Heritage** permet d'archiver ou mettre à disposition du **code**. + +## 3. L'enfer du calcul +### L'arrondi et l'ordre des opérations ... +Pour un calcul reproductible (deaux approches) : +- insister sur le respect de l'ordre des opérations, si le langage le permet +- rendre la compilation reproductible: + - noter la version précise du compilateur + - noter TOUTES les options de compilation + +### Un autre problème est posée par le **calcul parallèle** +L'objectif du calcul parallèle est de proposer une exécution **plus rapide** en +- minimisant la communication entre processeurs +- adaptant la répartition des données +- et donc adapter l'ordre des opérations qui ainsi peut varier d'une exécution à l'autre + +ALORS **le résultat dépend du nombre de processeurs**. + +### Les nombres pseudo_aléatoires += suite de nombres **en apparence** aléatoires mais générées par une algorithme déterministe. +**graine** (nombre entier) > état 1 --> nombre aléatoire 1 > état 2 --> nombre aléatoire 2 > ... > état n --> nombre aléatoire n + +DONC, la reproductibilité = mm graine + mm algorithme = mm suite + +*graine est choisie comme fonction de l'heure* à définir dans le code d'application + +Quelles précautions augmentent la reproductibilité des nombres pseudo-aléatoires: +- définir la graine dans le code d'application +- noter le numéro de version du générateur + +## 4. Conclusion : que faut-il retenir de ce MOOC ? -- 2.18.1