Je ne m'étendrais pas dans cet ouvrage sur les nombreuses subtilitées d'implémentation, sur les perles rares, grains de sables improbables mais pas impossibles, qui conduisent à une division par zéro, à une racine de nombre négatif, bref à une aberration numérique qu'il faut anticiper avant le moment crucial. Ni sur les plus communes erreurs d'indexage, résumées par le fameux message erreur de segmentation, alors que le programme laisse tout en plan, dans un fichier core.4321.
Un mot tout de même sur la routine du développeur :
Au tout début est la page blanche, comme pour les artistes.
Par la suite, le recyclage des codes rodés et l'abstraction fonctionnelle sont
salvateurs.
Une fois lancé, inspiré, le développeur assemble bout par bout son
ouvrage, en vérifiant qu'il soit compilable, puis exécutable,
sans plantage. Sa syntaxe est alors exacte.
Il vérifie ensuite le bon comportement du programme : qu'il exécute bien
ce pour quoi il a été conçu.
Les erreurs non plus de syntaxe, mais bien de sens, sont ainsi traquées
(jusqu'à n'être plus décelables, et déclarées disparues).
Bien souvent, le développeur s'exerce sur un exemple de son problème (une observation de supernova dans mon cas). L'interêt de son travail est que son programme fonctionne dans la majorité, sinon l'unaminité, des cas. Suit donc une période de test en grandeur nature du programme, confronté au maximum de cas imaginables.
Me concernant, les cas imaginables sont évidemment l'ensemble des images fournies par l'ESO, bornant notre univers VLT. Ainsi, le test ultime est réalisé en même temps que la réduction en bloc des données. Toutes les inhomogénéités présentes dans ces données, pourtant remarquablement homogènes, risquent de surprendre mes algorithmes, conçus dans une hypothèse d'ergodisme. Plus précisément, ce sont les valeurs de certains en-têtes, comparées pour valider l'uniformité des images utilisées, qui sont parfois tronquées, mises à zéro, ou erronées.
Une fois ces hoquets traqués et les algorithmes modifiés en conséquence, les programmes supportent l'intégralité de notre base de données FORS1, et l'on veut croire qu'il en sera de même pour les données à venir.
La course de la cascade de calibration a permis de réduire significativement la dimensionnalité du problème : les nombreuses images de calibration et de science sont intégrées en un unique spectrogramme combiné, annoté et habillé.
Les produits dérivés sont résumés, grâce à des routines Python, dans des pages HTML consultables par les membres du SNLS. Elles permettent de s'assurer du bon comportement des programmes sur l'ensemble des observations, et de consulter rapidement le contenu de l'observation d'une supernova donnée.
Au terme de ma seconde année à Santiago, à l'heure de réintégrer mon
laboratoire d'accueil à Paris, je partais avec ma librairie de programmes sur
un CD, et la première version en ligne de mes épreuves :
Des spectrogrammes combinés en estimant le ciel directement dans la fenêtre
de sortie de 200 pixel, en 5 secondes.
La fonction de dispersion et la réponse instrumentale étaient encore
empruntées aux produits MIDAS.
Les spectres des points sources étaient extraits comme cela vient d'être
présenté.
Le mode MOS n'était pas du tout considéré.