Skip to content

M
mooc-rr
Commit ba761a3a authored by Martin DAVY's avatar Martin DAVY
Browse files
Options

fin note module 4

parent b2cba564
Hide whitespace changes
Inline Side-by-side
Showing with 292 additions and 1 deletion
journal/module_4.html
View file @ ba761a3a
......@@ -254,6 +254,203 @@ pre code {
</ul>
</div>
</div>
<div id="lenfer-du-logiciel" class="section level2">
<h2>2. <strong>L’enfer du logiciel</strong></h2>
<div id="passage-à-léchelle-les-codes-complexes" class="section level3">
<h3>Passage à l’échelle : les codes complexes</h3>
<p>Notebook long devient vraiment difficile à lire</p>
<ul>
<li>un vrai plat de spaghettis
<ul>
<li>pas de vision d’ensemble</li>
<li>interaction entre plusieurs langages = <strong>danger</strong></li>
</ul></li>
</ul>
<p>Utilisation d’un workflow pour bien comprendre l’ensemble du code, avec représentation en graphe</p>
<p><strong>Workflow</strong></p>
<ul>
<li>vue de haut niveau plus claire</li>
<li>composition de codes et mouvements de données explicites</li>
<li>partage, réutilisation, et exécution plus sûre</li>
<li>le notebook en est une forme à la fois appauvrie et plus riche</li>
<li>pas de façon simple de passer d’un notebook à un workflow</li>
</ul>
<p>exemples:</p>
<ul>
<li>galaxy, kepler, taverna, pegasus, collective knowledge, vistrails</li>
<li><strong>légers</strong>: dask, frake, swift, snakemake, makefile…</li>
<li><strong>hybrides</strong>: SOS-notebook, …</li>
</ul>
<p><strong>L’usine à gaz des calculs coûteux</strong> Calcul interminable qui peuvent rendre le notebook inutilisable</p>
<ul>
<li>jupyter et les supercalculateurs : en dev</li>
<li>checkpoint et cache</li>
<li>workflow permet de passer à l’échelle (checkpoint naturel)</li>
</ul>
</div>
<div id="passage-à-léchelle-les-environnements-complexes" class="section level3">
<h3>Passage à l’échelle: les environnements complexes</h3>
<p>l’horreur des dépendance</p>
<p>Pas de standard pour la gestion des éco-systèmes</p>
<p>gestionnaire de paquet:</p>
<ul>
<li>linux: apt, rpm, yum</li>
<li>macOS X: brew, McPorts, Fink</li>
<li>Windows : Chocolatey, scoop</li>
</ul>
<p>Il faut controler l’environement dans lequel on travaille</p>
<p>sur VM ou conteneur</p>
<p><strong>Conserver le bazar</strong>: capture automatique de l’environnement, CDE, ReproZip</p>
<p><strong>Faire le ménage</strong>: partir d’un environnment vierge, installer que le nécessaire et l’expliciter, docker/singularity, guix/nix</p>
<p>conteneur: aucune bibliothéque de la machine sera utilisée</p>
</div>
<div id="lépreuve-du-temps" class="section level3">
<h3>l’épreuve du temps</h3>
<p>Probleme de repro FreeSurfer -&gt; resultat different entre windows/linux/!= os mac</p>
<p>orgmode aussi</p>
<p>outil à dev rapide</p>
<ul>
<li>évolution rapide et peu poser problème
<ul>
<li>besoin de vérifier la reconstructibilité et la fonctionnalité de ces environnements (intégration continue et test de non régression)</li>
</ul></li>
</ul>
<p>ce restreindre a ce qui est maitrisable (c / cpp)</p>
<p>L’archivage</p>
<ul>
<li>git (hub, lab) stable mais pérenne ? code space fin a cause de pirate</li>
<li>software heritage</li>
<li>hal</li>
</ul>
<p>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 ?</p>
<p>Concerver le plus d’info possible en automatisant - logiciel, version, procédures d’installation</p>
</div>
</div>
<div id="lenfer-du-calcul" class="section level2">
<h2>3. <strong>L’enfer du calcul</strong></h2>
<div id="larithmétique-à-virgule-flottante" class="section level3">
<h3>L’arithmétique à virgule flottante</h3>
<ul>
<li>Il a un arrondi implicite</li>
<li><code>a+b</code> -&gt; <code>arrondi(a+b)</code></li>
<li>mais <code>arrondi(arrondi(a+b)+c) != arrondi(a + arrondi(b+c))</code></li>
<li><strong>l’ordre des opérations</strong> est donc important (pour un calcul reproductible)</li>
</ul>
</div>
<div id="problème-avec-le-compilateur" class="section level3">
<h3>Problème avec le compilateur</h3>
<ul>
<li>pour les accélérations les compilateurs changent l’ordre</li>
<li>pour un calcul reproductible:
<ul>
<li>insister sur l’odre des opération si possible
<ul>
<li>le module ieee_arithmetic en Fortran 2003</li>
</ul></li>
<li>rendre la compilation reproductible
<ul>
<li>version du compilateur</li>
<li>et les options utilisées</li>
</ul></li>
</ul></li>
</ul>
</div>
<div id="calcul-parallèle" class="section level3">
<h3>Calcul parallèle</h3>
<ul>
<li>But : calcul plus rapide
<ul>
<li>-&gt;minimiser la communication entre processeurs</li>
<li>-&gt; adapter la répartition des données …</li>
<li>-&gt; et donc l’ordre des opérations</li>
</ul></li>
<li>Conséquence: le résultat dépend du nombre de processeurs !</li>
<li><strong>minimiser cet impact du parallélisme reste un sujet de recherche</strong></li>
</ul>
<blockquote>
<p>exemple avec la simulation d’une goutte d’eau avec un ou quatre processeur</p>
</blockquote>
</div>
<div id="plateformes-de-calcul" class="section level3">
<h3>Plateformes de calcul</h3>
<ul>
<li>Plateformes de calcul = matériel + infrastructure logicielle</li>
<li>Calcul = platforme + logiciel + données</li>
<li>la platforme définit l’interprétation du logiciel (c, cpp, python, fortran, …)</li>
<li>Platforme et logiciel définissent l’interprétation des données</li>
<li>Autres aspects définis par la platforme:
<ul>
<li>la réprésentation des entiers (16,32,64 bits) en c/cpp entre autre</li>
<li>la gestion des erreurs (division par 0 par exemple)</li>
</ul></li>
</ul>
</div>
<div id="les-nombre-aléatoires" class="section level3">
<h3>Les nombre aléatoires</h3>
<ul>
<li>utilisés pour la simulation stochastiques</li>
<li>en réalité : nombre <strong>pseudo</strong>-aléatoire en <strong>apparence</strong> aléatoire</li>
<li>mais générés par des algorithme déterministe</li>
</ul>
<p>Génération de nomnbre aléatoire:</p>
<pre><code>graine -&gt; état 1 -&gt; nbr 1
-&gt; état 2 -&gt; nbr 2
-&gt; ...</code></pre>
<p>La reproductibilité:</p>
<ul>
<li>principe : même graine + même algo = même nombres</li>
<li>les graines sont choisies en fonction de l’heure mais pas reproductible car jamais identique</li>
<li>il faut définir la graine dans le code de l’application</li>
<li>même suite ?
<ul>
<li>pas évident pour des nombres flottants</li>
<li>vérifier en testant quelques valeurs du début de la suites</li>
</ul></li>
</ul>
<p>En python:</p>
<pre class="python"><code>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</code></pre>
</div>
<div id="les-points-clés-à-retenir" class="section level3">
<h3>Les points clés à retenir</h3>
<ul>
<li>Les résultats d’un calcul dépendent
<ul>
<li>du logiciel</li>
<li>des données d’entrée</li>
<li>de la plateforme de calcul : matériel, compilateurs, …</li>
</ul></li>
<li>L’influence de la plateforme est importante pour l’arithmétique à virgule flottante</li>
<li>Noter les paramètres dont peuvent dépendre les résultats:
<ul>
<li>version du compilateur, et les options utilisées</li>
<li>matériel (type de processeur, GPU, …)</li>
<li>nombre de processeurs</li>
</ul></li>
<li>En utilisant un générateur de nombre aléatoire, définir la graine et vérifier les première valeurs</li>
</ul>
</div>
</div>
<div id="conclusion-que-faut-il-retenir-de-ce-mooc" class="section level2">
<h2>4. Conclusion: que faut-il retenir de ce mooc ?</h2>
<ol style="list-style-type: decimal">
<li>La recherche reproductible est un <strong>enjeu</strong> pour la <strong>méthodologie</strong> scientifique et pour l’<strong>inspectabilité</strong> la <strong>réutilisation</strong> de nos travaux</li>
<li>Des outils existes pour répondre à cette problématique:
<ul>
<li>les documents computationels (codebook: jupyter, RStudio, OrgMode)</li>
<li>les workflows (nextflow)</li>
<li>les gestionnaires de suivi de version (git)</li>
<li>les archives (hal)</li>
<li>les environnments logiciels (VM, conteneurs)</li>
<li>l’intégration continue</li>
</ul></li>
<li>Il faut mettre en pratique, prendre des note rigoureusement, <strong>rendre l’information exploitable et accessible facilement</strong></li>
</ol>
</div>
</div>
......
journal/module_4.md
View file @ ba761a3a
......@@ -86,7 +86,7 @@ les vraies données:
- archivage pour stockage pérenne et accessible
## L'enfer du logiciel
## 2. **L'enfer du logiciel**
### Passage à l'échelle : les codes complexes
......@@ -166,3 +166,97 @@ Gestion de l'environnement
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**
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment