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:

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