# 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


## 2. **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

## 3. **L'enfer du calcul**
### L'arithmétique à virgule flottante

- Il a un arrondi implicite
- `a+b` -> `arrondi(a+b)`
- mais `arrondi(arrondi(a+b)+c) != arrondi(a + arrondi(b+c))`
- **l'ordre des opérations** est donc important (pour un calcul reproductible)

### Problème avec le compilateur
- pour les accélérations les compilateurs changent l'ordre
- pour un calcul reproductible:
  - insister sur l'odre des opération si possible
    - le module ieee_arithmetic en Fortran 2003
  - rendre la compilation reproductible
    - version du compilateur
    - et les options utilisées
    
### Calcul parallèle
- But : calcul plus rapide
  - ->minimiser la communication entre processeurs
  - -> adapter la répartition des données ...
  - -> et donc l'ordre des opérations

- Conséquence: le résultat dépend du nombre de processeurs !
- **minimiser cet impact du parallélisme reste un sujet de recherche**

> exemple avec la simulation d'une goutte d'eau avec un ou quatre processeur

### Plateformes de calcul
- Plateformes de calcul = matériel + infrastructure logicielle
- Calcul = platforme + logiciel + données
- la platforme définit l'interprétation du logiciel (c, cpp, python, fortran, ...)
- Platforme et logiciel définissent l'interprétation des données
- Autres aspects définis par la platforme:
  - la réprésentation des entiers (16,32,64 bits) en c/cpp entre autre
  - la gestion des erreurs (division par 0 par exemple)
  
### Les nombre aléatoires
- utilisés pour la simulation stochastiques
- en réalité : nombre **pseudo**-aléatoire en **apparence** aléatoire
- mais générés par des algorithme déterministe

Génération de nomnbre aléatoire:

```
graine -> état 1 -> nbr 1
       -> état 2 -> nbr 2
       -> ...
```

La reproductibilité:

- principe : même graine + même algo = même nombres
- les graines sont choisies en fonction de l'heure mais pas reproductible car 
jamais identique
- il faut définir la graine dans le code de l'application
- même suite ? 
  - pas évident pour des nombres flottants
  - vérifier en testant quelques valeurs du début de la suites 

En python:
```python
import random

random.seed(123)
assert random.random() == valeur aléatoire 1
assert random.random() == valeur aléatoire 2
assert random.random() == valeur aléatoire 3
```

### Les points clés à retenir
- Les résultats d'un calcul dépendent
  - du logiciel
  - des données d'entrée
  - de la plateforme de calcul : matériel, compilateurs, ...
- L'influence de la plateforme est importante pour l'arithmétique à virgule flottante
- Noter les paramètres dont peuvent dépendre les résultats:
  - version du compilateur, et les options utilisées
  - matériel (type de processeur, GPU, ...)
  - nombre de processeurs
- En utilisant un générateur de nombre aléatoire, définir la graine et vérifier
les première valeurs


## 4. Conclusion: que faut-il retenir de ce mooc ?
1. La recherche reproductible est un **enjeu** pour la **méthodologie** scientifique et pour l'**inspectabilité** la **réutilisation** de nos travaux
2. Des outils existes pour répondre à cette problématique:
    - les documents computationels (codebook: jupyter, RStudio, OrgMode)
    - les workflows (nextflow)
    - les gestionnaires de suivi de version (git)
    - les archives (hal)
    - les environnments logiciels (VM, conteneurs)
    - l'intégration continue
3. Il faut mettre en pratique, prendre des note rigoureusement, **rendre l'information exploitable et accessible facilement**


## 5. exercice
### exercice 4 partie 1: ré-exécuter n'est pas répliquer
voir l'[article](https://arxiv.org/pdf/1708.08205.pdf) qui en parle

refaire l'analyse du notebook dans le langage que l'on a pas utilisé pour le mooc (c-à-d python/jupyter)

### exercice 4 partie 2: L'importance de l'environnement



### exercice 4 Partie 3
**ReScience**: garantie qu'au moins deux chercheurs indépendants ont réussi à suivre les indications, à ré-exécuter le code et à ré-obtenir les résultats que ceux décrits par les auteurs.

**RunMyCode**: site complémentaire aux articles scientifiques pour y déposer le code et les données pour permettre au lecteur de reproduire les résultats. Il n'y a cependant aucune garantie que les résultats puissent être reproduits