Dans cette étude, nous vous proposons de revenir sur <ahref="https://fr.wikipedia.org/wiki/Accident_de_la_navette_spatiale_Challenger">l'accident de la
navette spatiale Challenger</a>. Le 28 Janvier 1986, 73 secondes après son
lancement, la navette Challenger se désintègre (voir Figure <ahref="#org22bba0b">1</a>)
et entraîne avec elle, les sept astronautes à son bord. Cette
explosion est due à la défaillance des deux joints toriques
assurant l'étanchéité entre les parties hautes et basses des
propulseurs (voir Figure <ahref="#orgc01ded2">2</a>). Ces joints ont perdu de leur
efficacité en raison du froid particulier qui régnait au moment du
lancement. En effet, la température ce matin là était juste en dessous
de 0°C alors que l'ensemble des vols précédents avaient été effectués
<p><spanclass="figure-number">Figure 1 : </span>Photos de la catastrophe de Challenger.</p>
</div>
<divid="orgc01ded2"class="figure">
<p><imgsrc="o-ring.png"alt="o-ring.png"/>
</p>
<p><spanclass="figure-number">Figure 2 : </span>Schéma des propulseurs de la navette challenger. Les joints toriques (un joint principale et un joint secondaire) en caoutchouc de plus de 11 mètres de circonférence assurent l'étanchéité entre la partie haute et la partie basse du propulseur.</p>
</div>
<p>
Le plus étonnant est que la cause précise de cet accident avait été
débattue intensément plusieurs jours auparavant et était encore
discutée la veille même du décollage, pendant trois heures de
télé-conférence entre les ingénieurs de la Morton Thiokol
(constructeur des moteurs) et de la NASA. Si la cause immédiate de
l'accident (la défaillance des joints toriques) a rapidement été
identifiée, les raisons plus profondes qui ont conduit à ce désastre
servent régulièrement de cas d'étude, que ce soit dans des cours de
management (organisation du travail, décision technique malgré des
pressions politiques, problèmes de communication), de statistiques
(évaluation du risque, modélisation, visualisation de données), ou de
sociologie (symptôme d'un historique, de la bureaucratie et du
conformisme à des normes organisationnelles).
</p>
<p>
Dans l'étude que nous vous proposons, nous nous intéressons
principalement à l'aspect statistique mais ce n'est donc qu'une
facette (extrêmement limitée) du problème et nous vous invitons à lire
par vous même les documents donnés en référence dans le
préambule. L'étude qui suit reprend donc une partie des analyses
effectuées cette nuit là et dont l'objectif était d'évaluer
l'influence potentielle de la température et de la pression à laquelle
sont soumis les joints toriques sur leur probabilité de
dysfonctionnement. Pour cela, nous disposons des résultats des
expériences réalisées par les ingénieurs de la NASA durant les 6
années précédant le lancement de la navette Challenger.
</p>
<p>
Dans le répertoire <code>module2/exo5/</code> de votre espace <code>gitlab</code>, vous
trouverez les données d'origine ainsi qu'une analyse pour chacun des
différents parcours proposés. Cette analyse comporte quatre étapes :
</p>
<olclass="org-ol">
<li>Chargement des données</li>
<li>Inspection graphique des données</li>
<li>Estimation de l'influence de la température</li>
<li>Estimation de la probabilité de dysfonctionnement des joints
toriques</li>
</ol>
<p>
Les deux premières étapes ne supposent que des compétences de base en
R ou en Python. La troisième étape suppose une familiarité avec la
régression logistique (généralement abordée en L3 ou M1 de stats,
économétrie, bio-statistique…) et la quatrième étape des bases de
probabilités (niveau lycée). Nous vous présentons donc dans la
prochaine section une introduction à la régression logistique qui ne
s'attarde pas sur les détails du calcul, mais juste sur le sens donné
@licstart The following is the entire license notice for the
JavaScript code in this tag.
Copyright (C) 2012-2019 Free Software Foundation, Inc.
The JavaScript code in this tag is free software: you can
redistribute it and/or modify it under the terms of the GNU
General Public License (GNU GPL) as published by the Free Software
Foundation, either version 3 of the License, or (at your option)
any later version. The code is distributed WITHOUT ANY WARRANTY;
without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE. See the GNU GPL for more details.
As additional permission under GNU GPL version 3 section 7, you
may distribute non-source (e.g., minimized or compacted) forms of
that code without the copy of the GNU GPL normally required by
section 4, provided you include this license notice and a URL
through which recipients can access the Corresponding Source.
@licend The above is the entire license notice
for the JavaScript code in this tag.
*/
<!--/*--><![CDATA[/*><!--*/
functionCodeHighlightOn(elem,id)
{
vartarget=document.getElementById(id);
if(null!=target){
elem.cacheClassElem=elem.className;
elem.cacheClassTarget=target.className;
target.className="code-highlighted";
elem.className="code-highlighted";
}
}
functionCodeHighlightOff(elem,id)
{
vartarget=document.getElementById(id);
if(elem.cacheClassElem)
elem.className=elem.cacheClassElem;
if(elem.cacheClassTarget)
target.className=elem.cacheClassTarget;
}
/*]]>*///-->
</script>
</head>
<body>
<divid="content">
<h1class="title">Org document examples</h1>
<p>
In the MOOC video, I quickly demo how org-mode can be used in various
contexts. Here are the (sometimes trimmed) corresponding
org-files. These documents depend on many other external data files
and are not meant to lead to reproducible documents but it will give
you an idea of how it can be organized:
</p>
<olclass="org-ol">
<li><ahref="journal.html">journal.org</a>: an excerpt (I've only left a few code samples and links
to some resources on R, Stats, …) from my own journal. This is a
personal document where everything (meeting notes, hacking, random
thoughts, …) goes by default. Entries are created with the <code>C-c c</code>
shortcut.</li>
<li><ahref="labbook_single.html">labbook<sub>single.org</sub></a>: this is an excerpt from the laboratory notebook
<ahref="https://cornebize.net/">Tom Cornebize</a> wrote during his Master thesis internship under my
supervision. This a personal labbook. I consider this notebook to be
excellent and was the ideal level of details for us to communicate
without any ambiguity and for him to move forward with confidence.</li>
<li><ahref="paper.html">paper.org</a>: this is an ongoing paper based on the previous labbook of
Tom Cornebize. As such it is not reproducible as there are hardcoded
paths and uncleaned dependencies but writing it from the labbook was
super easy as we just had to cut and paste the parts we
needed. What may be interesting is the organization and the org
tricks to export to the right LaTeX style. As you may notice, in
the end of the document, there is a commented section with emacs
commands that are automatically executed when opening the file. It
is an effective way to depend less on the <code>.emacs/init.el</code> which is
generally customized by everyone.</li>
<li><ahref="labbook_several.html">labbook<sub>several.org</sub></a>: this is a labbook for a specific project shared
by several persons. As a consequence it starts with information
about installation, common scripts, has section with notes about all
our meetings, a section with information about experiments and an
other one about analysis. Entries could have been labeled by who
wrote them but there were only a few of us and this information was
available in git so we did not bother. In such labbook, it is common
to find annotations indicating that such experiment was <code>:FLAWED:</code> as
it had some issues.</li>
<li><ahref="technical_report.html">technical<sub>report.org</sub></a>: this is a short technical document I wrote
after a colleague sent me a PDF describing an experiment he was
conducting and asked me about how reproducible I felt it was. It
turned out I had to cut and paste the C code from the PDF, then
remove all the line numbers and fix syntax, etc. Obviously I got
quite different performance results but writing everything in
org-mode made it very easy to generate both HTML and PDF and to
explicitly explain how the measurements were done.</li>
</ol>
<p>
Here are a few links to other kind of examples:
</p>
<ulclass="org-ul">
<li>Slides: all my slides for a series of lectures is available here:
<ahref="https://github.com/alegrand/SMPE">https://github.com/alegrand/SMPE</a>. Here is a <ahref="https://raw.githubusercontent.com/alegrand/SMPE/master/lectures/lecture_central_limit_theorem.org">typical source</a> and the
<h2id="org5865c53"><spanclass="section-number-2">2</span> LaTeX IEEE title and authors   <spanclass="tag"><spanclass="ignore">ignore</span></span></h2>
In Section\ref{sec:relwork} we explained that SMPI relies on the <i>online</i> simulation approach.
Since SimGrid is a sequential simulator, SMPI maps every MPI process of the application onto a
lightweight simulation thread. These threads are then run one at a
time, \ie in mutual exclusion.
Every time a thread enters an MPI call,
SMPI takes control and the time that was spent
computing (isolated from the other threads) since the previous
MPI call can be injected into the simulator as a virtual delay.
</p>
<p>
Mapping MPI processes to threads of a single
process effectively folds them into the same address space.
Consequently, global variables in the MPI application are shared
between threads unless these variables are <i>privatized</i> and the
simulated MPI ranks thus isolated from each other. Several
technical solutions are possible to handle this issue\cite{smpi}. The
default strategy in SMPI consists of making a copy of the <code>data</code>
segment (containing all global variables) per MPI rank at startup and,
when context switching to another rank, to remap the <code>data</code> segment via <code>mmap</code> to the private copy of that rank.
SMPI also implements another mechanism relying on the <code>dlopen</code>
function that saves calls to <code>mmap</code> when context switching.
</p>
<p>
This causes online simulation to be expensive in terms of both simulation time and memory
since the whole parallel application is executed on a single node.
To deal with this, SMPI provides two simple annotation mechanisms:
</p>
<ulclass="org-ul">
<li><b>Kernel sampling</b>: Control flow is in many cases
independent of the computation results. This allows
computation-intensive kernels (\eg BLAS kernels for HPL)
to be skipped during the simulation. For this purpose, SMPI
supports annotation of regular kernels through several macros
such as <code>SMPI_SAMPLE_LOCAL</code> and <code>SMPI_SAMPLE_GLOBAL</code>. The regularity allows SMPI to execute these
kernels a few times, estimate their cost and skip the kernel in
the future by deriving its cost from these samples, hence cutting
simulation time significantly. Skipping kernels renders the
content of some variables invalid but in simulation, only the
behavior of the application and not the correctness of computation
results are of concern.</li>
<li><b>Memory folding</b>: SMPI provides the <code>SMPI_SHARED_MALLOC</code> (<code>SMPI_SHARED_FREE</code>) macro to
replace calls to <code>malloc</code> (<code>free</code>). They indicate that some data structures can safely be
shared between processes and that the data they contain is not
critical for the execution (\eg an input matrix) and that it may
even be overwritten.
<code>SMPI_SHARED_MALLOC</code> works as follows (see Figure\ref{fig:global_shared_malloc}) : a single block of physical memory (of default size \SI{1}{\mega\byte}) for the whole
execution is allocated and shared by all MPI processes.
A range of virtual addresses corresponding to a specified size is reserved and cyclically mapped onto the previously obtained
physical address.
This mechanism allows applications to obtain a nearly constant memory
footprint, regardless of the size of the actual allocations.</li>
Experiments presented in this paper were carried out using the Grid'5000 testbed, supported by a scientific interest group hosted by Inria and including CNRS, RENATER and several Universities as well as other organizations (see <ahref="https://www.grid5000.fr">https://www.grid5000.fr</a>).
We warmly thank our TACC colleagues for their support in this study and
providing us with as much information as they could.
Vous y trouverez notre réplication des calculs de Dallal <i>et al.</i> (en
R), une mise en œuvre en Python et une en R (très similaires à ce que
vous avez pu utiliser dans le module 2). Cet exercice peut donc se
faire à deux niveaux :
</p>
<olclass="org-ol">
<li>un niveau facile pour ceux qui repartiront du code dans le langage
qu'ils n'auront initialement pas utilisé et se contenteront de le
ré-exécuter. Pour cela, nul besoin de maîtriser la régression
logistique, il suffit de bien inspecter les sorties produites et de
vérifier qu'elles correspondent bien aux valeurs attendues. Pour
ceux qui ré-exécuteraient le notebook Python dans l'environnement
Jupyter du MOOC, n'hésitez pas à consulter <ahref="https://www.fun-mooc.fr/courses/course-v1:inria+41016+session01bis/jump_to_id/4ab5bb42ca1e45c8b0f349751b96d405">les ressources de la
section 4A du module 2</a> qui expliquent comment y importer un
notebook.</li>
<li>un niveau plus difficile pour ceux qui souhaiteront le réécrire
complètement (éventuellement dans un autre langage que R ou Python,
l'expérience peut être d'autant plus intéressante que nous n'avons
pas testé ces variations). Là, si les fonctions de calcul d'une
régression logistique ne sont pas présentes, il y a par contre
intérêt à en savoir un minimum pour pouvoir les
implémenter. L'exercice en est d'autant plus instructif.</li>
</ol>
<p>
Vous pourrez alors discuter sur le forum des succès et des échecs que
vous aurez pu rencontrer. Pour cela :
</p>
<ulclass="org-ul">
<li><b>Vous publierez auparavant dans votre dépôt les différents notebooks</b>
en prenant bien soin d'enrichir votre document des informations
(numéros de version, etc.) sur votre système et sur les
bibliothèques installées.</li>
<li>Vous indiquerez votre résultat (que ça soit un succès ou échec à
obtenir les mêmes résultats) en <b>remplissant ce <ahref="https://app-learninglab.inria.fr/gitlab/moocrr-session1/moocrr-reproducibility-study/blob/master/results.md">tableau</a></b> (vous avez
les droits d'édition donc il vous suffit d'éditer les fichiers via
l'interface GitLab). Vous vérifierez les valeurs obtenues pour :
<olclass="org-ol">
<li>les coefficients de la pente et de l'intercept</li>
<li>les estimations d'erreur de ces coefficients</li>
<li>le goodness of fit</li>
<li>la figure</li>
<li>la zone de confiance</li>
</ol></li>
<li><p>
Pour chacun vous indiquerez si le résultat est :
</p>
<ulclass="org-ul">
<li>identique</li>
<li>proche à moins de trois décimales</li>
<li>très différent</li>
<li>non fonctionnel (pas de résultat obtenu)</li>
</ul>
<p>
Vous indiquerez également dans ce tableau :
</p>
<ulclass="org-ul">
<li>un lien vers votre espace gitlab contenant les différents notebooks</li>
<li>le nom du système d'exploitation utilisé</li>
<li>le langage utilisé et son numéro de version</li>
<li>les numéros des principales bibliothèques utilisées
Ne vous inquiétez pas si ces consignes vous semblent peu claires sur l'instant,
elles sont rappelées en haut du <ahref="https://app-learninglab.inria.fr/gitlab/moocrr-session1/moocrr-reproducibility-study/blob/master/results.md">tableau</a> et vous vous rendrez vite
compte s'il vous manque quelque chose quand vous essaierez de remplir
ce tableau.
</p>
<p>
Nous effectuerons une synthèse illustrant les principales divergences
observées et nous vous l'enverrons à la fin du MOOC.
You will find there our replications of the computations by Dallal <i>et
al.</i> (in R), one in Python and one in R (very similar to what you have
used in module 2). This exercise can be done at two levels:
</p>
<olclass="org-ol">
<listyle="color: #b62567;">an easy level at which you start from the code in the language that you did not use initially, and content yourself with re-executin it. This doesn't require mastering logistic regression, it is sufficien to inspect the outputs produced and check that they correspond to the expected values. For those who want to re-execute the Python notebook in our MOOC's Jupyter environment, check <ahref="https://www.fun-mooc.fr/courses/course-v1:inria+41016+session01bis/jump_to_id/4ab5bb42ca1e45c8b0f349751b96d405">the resources for sequence 4A of module 2</a> that explain how to import a notebook.</li>
<listyle="color: #b62567;">a more difficult level at which you rewrite the analysis completely, possibly in a different language than Python or R, which makes the exercise more interesting because we have not tested such variants. If logistic regression is not already implemented for your language, you will need a good understanding of it in order to write the code yourself, which of course makes the exercise even more instructive.</li>
</ol>
<pstyle="color: #b62567;">
You can discuss your successes or failures on the forum, after following these instructions:
</p>
<ulclass="org-ul">
<listyle="color: #b62567;"><b>First, publish your notebooks in your repository</b>, taking care to enrich your document with information about your system and your libraries (version numbers etc.).</li>
<listyle="color: #b62567;">Indicate your result by adding to this <ahref="https://app-learninglab.inria.fr/gitlab/moocrr-session1/moocrr-reproducibility-study/blob/master/results.md">table</a> (you have write permissions, so you can simply edit it via the GitLab interface). Check the values obtained for:
<olclass="org-ol">
<listyle="color: #b62567;">the slope and intercept coefficients</li>
<listyle="color: #b62567;">the error estimates for these coefficients</li>
<listyle="color: #b62567;">the goodness of fit</li>
<listyle="color: #b62567;">R: BLAS, ggplot, dplyr if used</li>
</ul></li>
</ul></li>
</ul>
<pstyle="color: #b62567;">
Don't worry if these instructions seem confusing, they are reproduced above the <ahref="https://app-learninglab.inria.fr/gitlab/moocrr-session1/moocrr-reproducibility-study/blob/master/results.md">table</a> and you will quickly notice if something is missing when you try to add your data.
</p>
<pstyle="color: #b62567;">
We will compile a synthesis of the principal divergences observes and make it available at the end of the MOOC.
<h2id="org1f802ba">Exercice 2 : L'importance de l'environnement</h2>
<divclass="outline-text-2"id="text-org1f802ba">
<p>
Dans cet exercice, nous vous proposons de reprendre l'exercice
précédent mais en mettant à jour l'environnement de calcul. En effet,
nous avons rencontré des surprises en préparant ce MOOC puisqu'il nous
est arrivé d'avoir des résultats différents entre nos machines et
l'environnement Jupyter que nous avions mis en place pour le MOOC. Ça
sera peut-être également votre cas !
</p>
<olclass="org-ol">
<li>Pour ceux qui ont suivi le parcours Jupyter, recréez
l'environnement du MOOC sur votre propre machine en suivant les
instructions données
<ahref="https://www.fun-mooc.fr/courses/course-v1:inria+41016+session01bis/jump_to_id/4ab5bb42ca1e45c8b0f349751b96d405">dans les ressources de la section 4A du module 2</a>.</li>
<li>Vérifiez si vous obtenez bien les mêmes résultats que ceux
attendus.</li>
<li>Mettez à jour (vers le haut ou vers la bas) cet environnement et
vérifiez si vous obtenez les mêmes résultats.</li>
</ol>
<p>
Comme précédemment, vous mettrez à jour le <ahref="https://app-learninglab.inria.fr/gitlab/moocrr-session1/moocrr-reproducibility-study/blob/master/results.md">tableau</a> et vous discuterez
sur le forum des succès et des échecs que vous aurez rencontrés.
<h2id="org1a24dbb"><spanstyle="color: #b62567;">The importance of the environment</span></h2>
<divclass="outline-text-2"id="text-org1a24dbb">
<pstyle="color: #b62567;">
In this exercise, we ask you to redo the preceding exercise after
updating the computational environment. When preparing this MOOC, we
had a few surprises due to different results on our own computers and
on the Jupyter environment that we had installed for the MOOC. Maybe
that will happen to you as well!
</p>
<olclass="org-ol">
<listyle="color: #b62567;">For those you followed the Jupyter path, re-create the MOOC's Jupyter environment on your own computer by following the instructions given
<ahref="https://www.fun-mooc.fr/courses/course-v1:inria+41016+session01bis/jump_to_id/4ab5bb42ca1e45c8b0f349751b96d405">in the resource section of sequence 4A of module 2</a>.</li>
<listyle="color: #b62567;">Check if you get the same results as in the MOOC environment.</li>
<listyle="color: #b62567;">Update this environment, increasing or decreasing some package's version numbers, and check if the results are still the same.</li>
</ol>
<pstyle="color: #b62567;">
As before, you can add your observations to the <ahref="https://app-learninglab.inria.fr/gitlab/moocrr-session1/moocrr-reproducibility-study/blob/master/results.md">table</a> and discuss your successes and failures on the forum.
