From 0f846689687f898d6de32037645049b557f6a8de Mon Sep 17 00:00:00 2001 From: MigAP Date: Wed, 11 Nov 2020 17:56:28 +0100 Subject: [PATCH] notes module 4 --- journal/journal.org | 119 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 119 insertions(+) diff --git a/journal/journal.org b/journal/journal.org index 3c98757..943354a 100644 --- a/journal/journal.org +++ b/journal/journal.org @@ -149,3 +149,122 @@ - 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 +- -- 2.18.1