# 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