#+title: Reproducible Research Notes/Journal
#+startup: inlineimages indent overview

* Module 2 
** 0. Introduction 
** 1. Exemples récents d'études assez discutées 
   - En 2010, suite à la crise des subprimes, les économistes Reinhart et Rogoff étudient les relations entre la dette et la croissance. Ils concluent que quand la dette d'un pays dépasse 90% du PIB les conséquences sont catastrophiques. Beaucoup de périodistes et politiciens jusitifient leurs décision d'austérité économique en s'appuyant sur leurs travaux.
     
*** IRM fonctionnelle 
    - Bennett et al. mettent un saumon mort dans un IRM et ils obtiennent des signaux. Ils font ça pour mettre en évindence à quel point les données brutes sont bruités dans les IRM et le grand besoin de bien calibrer la machine et d'être rigoureux dans le traitement de données.
    - Eklund, Nichols and Knutsson trouvent un bug dans le soft pour traiter les images qui pourrait remettre en cause 15 annnées de recherche sur le cerveau (3600 articles seraient concernées).  

** 2. Pourquoi est-ce difficile ? 

*** Difficultés à reproduire les résultats 
    1. Non disponibilité des données : données brutes, choix utilisés pour l'acquisition, traitement. 
    2. Erreurs dûs à l'utilisation des ordinateurs.
    3. Manque de rigueur et d'organisation.
    4. Dimensions culturelles : 
       - Un article est beaucoup trop succint comme format. 

*** Tout rendre public ? 
    - Les papier les plus cités sont ceux qui donnent des contributions méthodologiques ou qui développent un logiciel qui devient indispensable, donc il est intéressant de donner à la communauté ce qu'on a développé.
    - Données sensisbles : stratégies cryptographiques, limiter l'accès.

** 3. Le document computationnel : principe 
   - Objectifs : 
     1. Inspecter,jsutifier et comrpendre la démarche effectuée afin d'aboutir au résultat final.
     2. Être capable de refaire facilement ce qu'on a produit. 

** 4. Prise en main de l'outil 
   - org-babel-execute-buffer : éxecuter tout le buffer, ce qui permet d'éviter des problèmes dûs à l'utilisation de sessions. 

*** Template pour le code python 
**** Simple template  
    #+BEGIN_SRC python :results output :exports both 
    print("Hello World")
    #+END_SRC

    #+RESULTS:
    : Hello World
**** Session template 
    #+BEGIN_SRC python :results output :session :exports both 
    print("Hello World")
    #+END_SRC

    #+RESULTS:
    : Hello World

**** Image template 
     #+BEGIN_SRC python :results output file :session :var matplot_lib_filename="./tutu.png" :exports both
     import matplotlib.pyplot as plt
     import numpy
     x=numpy.linspace(-15,15)
     plt.figure(figsize=(10,5))
     plt.plot(x,numpy.cos(x)/x)
     plt.tight_layout()
     plt.savefig(matplot_lib_filename)
     print(matplot_lib_filename)
     #+END_SRC

     #+RESULTS:
     [[file:./tutu.png]]

*** Article reproductible avec org mode 
- Il faut compiler l'article en utilisant le makefile.
- Il faut installer R et les packages pour l'utiliser avec emacs : j'ai installé le package r-base directement des dépôts ubuntu.
- Si l'on décommente la ligne : # #+PROPERTY: header-args :eval never-export, cela permet d'éviter l'éxécution de tout le code lors de l'exportation. 

*** TODO Explorer l'ensemble des ressources données dans cette partie du cours. 
*** Configuration git 
- Pour obtenir les identifiants et mdp : M2-S7 en bas de la vidéo il y a un onglet afin d'obtenir les indentifiants. 

** 5. Travailler avec les autres  
- Produire un document computationel demande du travail et un système bien configuré.
- Pour travailler avec d'autres il faut assurer la compatibilité des outils sous différents environnements (Mac, Windows, Linux).
- Dans le cas d'une approche où les co-auteurs refusent d'utiliser des nouveaux outils : 
  1. Avoir un document computationel séparé qui produit tous les résultats et toutes les figures.
  2. Un docuemnt classique qui inclut les figures générées. Ainsi tout est conservé, documenté et recalculable dans le docuement computationel.
- Site compagnons: HAL, Figshare / zenodo des outils d'archivage qui permet de mettre un PDF et des documents annexes. 

** 6. Analyse comparée des outils 
- Pour un cours où un TD le jupyter notebook est une solution agréable.
- Pour un journal, il utilise les mécanisme des tags : on peut trouver des notes biblio, des bout de codes, notes de réunion.
- Un cahier de laboratoire : différents scripts utiles, une section avec des expérieces et analyses ordonnées chronologiquement (avec des liens sur les expériences sur les expériences dans la partie analyse). Ce document présente aussi des conventions qui doivent être explicitée au début du document.
- Article reproductible : les tags :noexport: permettent dans les sections/soussections d'éviter qu'elles soient prise en compte dans l'export. 
*** Tenir un journal 
- Présentation de la méthodologie :  https://people.irisa.fr/Martin.Quinson/Research/Students/Methodo/
- Différents exemples de cahiers de laboratoire et de journaux.
- Pour le reporting vaut mieux le faire le vendredi 1-2 heures avant de partir, de même dans le cas quotidien.
- Organisation d'un compte rendu d'activité : 
  1. Résultats : vide au début, puis elle prendra du volume au fur et à mesure que vous trouverez des choses.
  2. Développement : Cette partie présente les aspect techniques de votre travail.
  3. Journal : Description du travail le jour le jour : description chronologique.
  4. Conclusion : section écrite la dernière semaine du stage. C'est la lettre à la prochaine personne expliquant l'état actuel du travail.
- Trouvez un bon équilibre pour la partie journal : pas trop long -> perte de temps, pas trop court -> il faut que ça puisse être utile/réutilisable dans le futur.
- Exemple de compte rendu d'activité. 

* Module 3 : La main à la pâte, une analyse réplicable
** 1. Une analyse réplicable, c'est quoi ? 
- Dans le cas d'une analyse traditionnelle, on se focalise sur les
  résultats obtenus. On présente brièvement la méthodologie adoptée
  qui a permis d'obtenir les résultats. Puis l'on fini avec une
  discussion sur les résultats.
- En constraste, une analyse de donnés répblicable remplace la
  présentation de la méthodologie par la totatlité du code qui a
  permis d'obtenir ces résultats, accompagnée d'une explication sur
  les différents choix effectuées.
- Pourquoi faire une analyse répblicable : facile à refaire si les
  données changent, facile à modifier, facile à inspecter et vérifier.
  
** 2. Étude de cas : l'incidence de syndromes grippaux 
- Utilisation du site Sentinelles afin d'utiliser des données
  médicales.
- Année et semaine en format ISO : la première semaine c'est la
  semaine qui contient le 4 janvier.
- Aucune modification des données brutes à la main, cela rend
  l'analyse non replicable. Toutes les modification doivent se faire
  dans du code.
- Format des dates ISO 8601, il y a deux façons différentes de
  représenter une date, considérons le 8 août 2018 :
  1. 2018-08-08 : année, mois, jour du mois
  2. 2018-W32-3 : année, semaine et jour de la semaine (mercredi =
     3ème jour). La première semaine de l'année est celle qui contient
     le premier jeudi de l'année.

** 3. Importer les données avec OrgMode / Python+R
- Il faut spécifier l'url de téléchargement dans le document
  computationel. Avec la "commande" =#+NAME:= on peut attribuer un nom
  à l'url et la passer dans le code par la suite.
- Présentation d'un petit script qui permet de télécharger les données
  en utilisant l'url.
- Lorsqu'on utilise l'option =results value= org mode permet d'avoir
  un affichage agréable sur les résultats du code.
- Les données doivent être directement traitées depuis la source sans
  intervention manuelle.
** 4. Vérification et inspection avec org-mode  
- Le langage python (à partir de 3.6) elle gère les dates en format ISO.
- Conversion des date + tri chronologique + vérification des données.
- Passage des données entre python et R. Cependant ils utilisent comme
  intérmédiaire org-mode. C'est org-mode qui gère le passage
  d'information entre les deux langages.
- Autre méthode c'est passer par un fichier texte pour gérer
  l'intermédiaire entre python et R.
- Faire des vérifications : analyse visuelle + des codes de vérification. 
** 5. Questions et réponses 
- Dans quelle année il y a eu l'épidémie la plus forte, puis leurs
  fréquences ?
- Conversions des années hebdomadaires en années annuelles.
- Expliquer les détails techniques car c'est là que l'on fait les
  erreurs !
* Module 4 : Vers une étude reproductible : la réalité du terrain
** 1. L'enfer des données 
- Deux problèmes reliés aux données :
  1. Les données peuvent être non homogènes : images, tables, données
     chronologiques... 
  2. Les données peuvent prendre beaucoup d'espace mémoire.
     - Préférez le format binaire car il prend moins de place et de ça
       évite de convertir des données en format texte au format
       binaire pour le traitement dans le programme d'analyse.
     - Cepdant le format texte permet de garder des métadonnées.
     - Le format texte est "universel", ce n'est pas le cas avec des
       format binaires. Ili faut spécifier le boutisme si l'on utilise
       un format binaire (bit de poids faible).

*** Format binaires        
- Format binaires qui permettent de fixer le boutisme, et ajouter des
  métadonnée :
  - FITS. 
  - HDF5.
- Anatomie des fichiers FITS : 
  - Un ou plusieurs headers HDU (Header/Data units)
  - HDU : 
    1. Une en-tête (Header Unit).
    2. Des données (Data Unit).
  - Dans l'en-tête on peut mettre des mots clés/valeur ce qui permet
    d'avoir des métadonnées.
- Bibliothèques C fournies par les développeurs pour traiter des
  fichier FITS en C. En Python PyFITS.
- HD5 
  - Plus récent.
  - Organisation interne comme celle d'une arborésence de fichiers : 
    - Groups : répértoires
    - datasets : jeux de données.
  - Pas de structure imposée !
  - Bibliothèque C plus complexe (format plus souple).
  - Python : h5py.
 
*** Archivage 
- Git n'est pas la meilleure solution pour l'archivage des données.
- zenodo : serveur du CERN
- figshare : entreprise privée. 

** 2. L'enfer du logiciel 
*** A. Passage à l'échelle : les codes complexes
- Même si on a des bons cahier de laboratoire il est difficile d'avoir
  une vue d'ensemble du projet.
- Pour cela on peut utiliser un workflow : encapsulation des bouts de
  code en fonction qu'ensuite on relie ensemble. Il permet de générer
  un graph qui représente la structure du projet.
- Il permet d'éviter l'exécution de bouts de code de façon
  désorganisée comme dans une notebook.
- Néanmoins il y a moin d'information utile pour des parties
  spécifiques par rapport à un noteboook. Dans un workflow on délégue
  l'exécution puis on récupère les résultas.
- Un makefile est une sorte de workflow.
- Hybride : SOS-notebook.
- Commencer avec un notebook puis passer à l'échelle éventuellement
  avec un workflow.
*** B. Passage à l'échelle : les environnements complexes. 
- La complexité derrière le package matplotlib est énorme !
- Il faut contrôler l'environnement dans lequel on travail : machine
  virtuelle, docker...
- Guix/Nix : distributions linux qui permet de créer des environnment
  vierges sans effet de bord. Et avoir une description reproductible
  de l'environnement.
*** C. L'épreuve du temps. 
- Exemple de différences enter python2 et python3.
- Archivage : 
  - HAL : on peut mettre du code. 
  - Software Heritage : objectif d'archiver l'ensemble des logiciels
    produits par l'humanité.
- Gestion des environnements : 
  - Dockerhun.
  - nix.
  - code ocean.
  - Pérennité ?
- Conserver les plus d'informations possibles en automatisant :
  logiciels, versions, procédure d'installation.
** 3. L'enfer du calcul

*** Arithmétique flottante  
- a+b est en rélalité arrondi(a+b).
- L'ordre des opération est important !
- Le problème c'est que les compilateurs peuvent changer l'ordre des
  opérations pour optimiser le code !
- Deux optiions 
  1. Soit on force le compilateur à garder l'ordre des opérations.
  2. Soit on rend réproductible la compilation : version précise +
     paramètre de compilation.
- Calcul parallèle : le résultat dépend du nombre de processeur :  
  - Minimiser la communication entre processeur -> adapter la
    répartition des données -> changer l'ordre des opération.

*** Plateformes de calcul 
- matériel + infrastructure logicielle
- Calcul : plateforme + logiciel + données.
- Ces éléments doivent être spécifiés dans une démarche de recherche
  reproductible.

*** Les nombres aléatoires 
- Les nombres aléatoires sont en réalité des nombres pseudo-alétoires
  générées par des algorithme déterministes.
- La graine est la base de la génération de nombres aléatoires. Elle
  est choisie en fonction de l'heure le plus souvent. Mais l'on peut
  toujours spécifier explicitement dans l'algorithme il suffit d'y
  penser.
  
*** Pints clés à retenir 
Les résultats d'un calcul dépendent : 
1. du logiciel.
2. des données d'entrée.
3. de la plateforme de calcul : matériel, compilateurs.


- En utilisant un générateur de nombres alétoires, définir la graine
  et vérifiez les premiers éléments de la suite.

** 4. Conclusion : que faut-il retenir 
- 

* Travaux Pratiques