Contribution à la mission SVOM

L’Observatoire de Strasbourg fait partie du Consortium scientifique français (FSC, 10 laboratoires dirigés par le CEA) qui est chargé de fournir et d’exploiter le logiciel au sol pour les instruments français. Nous sommes responsables de la conception, du développement et du support du logiciel de traitement des données du MXT. Celui-ci fournit des données calibrées et des produits scientifiques pour tous les modes de fonctionnement et les programmes scientifiques de SVOM, c’est-à-dire pour la science des GRB et des non-GRB, y compris pour les contreparties des sources multi-messagers (ondes gravitationnelles et neutrinos).

La Caméra MXT

En réponse à l’alerte transmise par ECLAIRs, le MXT (Microchannel X-ray Telescope) observera le sursaut gamma dans le domaine des rayons X mous (énergie comprise entre 0,2 et 10 keV), en particulier au tout début de la rémanence. Il est développé en France par le CNES et le CEA-Irfu, en étroite collaboration avec l’Université de Leicester au Royaume-Uni et le Max-Planck Institut für Extraterrestische Physik de Garching en Allemagne.

Le MXT possède une optique en œil de homard (galettes de verre à micro-canaux en verre) à l’entrée du télescope d’un diamètre de 24 cm et d’un poids de 2 kg. La structure, d’une longueur focale de 1,15 m, est en fibre de carbone avec la caméra au foyer. L’ensemble a une masse de 35Kg

Le Pipeline de Traitement

Les pipelines que nous avons développés pour le MXT (voir l’organigramme ci-dessous) exécutent des séquences de tâches indépendantes, téléchargeant d’abord les fichiers d’entrée nécessaires à partir de la base de données scientifique (SDB) et les fichiers de configuration et de calibration des instruments (CALDB). Les données d’entrée sont ensuite calibrées et utilisées pour produire un ensemble de produits scientifiques liés aux observations (par exemple, des images) et aux sources détectées dans le champ de vue, tels que des spectres d’énergie et des courbes de lumière. Tous les produits créés sont stockés dans le SDB et éventuellement envoyés directement aux observateurs.

La Banc de Simulations

Afin de guider le développement des tâches de notre pipeline, de les valider et d’identifier les cas problématiques avant la phase d’exploitation, nous avons également conçu une chaine de simulation, produisant des données réalistes tenant compte des caractéristiques du télescope et du détecteur.

Le banc de simulation vise à tester notre workflow ainsi que les fonctionnalités des pipelines que nous développons. Des milliers de simulations (méthode Monte-Carlo) mélangeant à la fois les caractéristiques du pointage (position, temps d’exposition,…) et celles des objets étudiés (nombre et position des sources dans le champ de vue, flux, caractéristiques spectrales, variabilité,…) sont générées puis injectées dans le pipeline. Les valeurs calculées par des algorithmes sophistiqués sont alors automatiquement comparées aux valeurs d’entrée, permettant ainsi de qualifier la qualité du pipeline, la pertinence des valeurs retournées mais aussi d’isoler facilement les cas problématiques qui pourraient être rencontrés lors de la phase opérationnelle et d’apporter les corrections nécessaires.

Pendant la phase de développement, le banc de simulation tourne 24/24 sur une grande variété de sources en entrée afin de détecter autant que possible les configurations qui font échouer le pipeline.

La Gestion de l’interopérabilité

L’Observatoire de Strasbourg dirige également la conception et le développement des mécanismes (schémas et outils) assurant un bon niveau d’interopérabilité pour les différents modules de l’infrastructure du segment sol. A cet effet, nous avons fourni au consortium un workflow complet pour la gestion du modèle de données des produits scientifiques. Nous avons également défini un vocabulaire commun pour tous les messages échangés par les différentes parties prenantes et nous avons enfin conçu une interface de contrôle commune utilisée par la plupart des pipelines de traitement. Enfin, tous nos produits sont livrés avec une interface conforme à l’Observatoire Virtuel.

Un schéma pour tous les messages

L’infrastructure française du segment sol couvre un large éventail d’activités, de la décommutation des données à l’analyse scientifique. Elle comprend également le traitement de toutes les données liées aux instruments. Tous ces modules, qui tournent dans un cluster Kubernetes hébergé par le CCIN2P3, ont été développés par différentes équipes. La base de cette infrastructure distribuée est que tout module peut à la fois écrire et écouter le flux de messagerie (NATS) et peut être contrôlé par des API REST. Un module peut en surveiller un autre en écoutant le NATS. Il peut déclencher des actions sur cet autre module en invoquant certains points d’accès REST ou obtenir, par exemple, un rapport ou un état de traitement en invoquant d’autres points d’accès. Un module peut également décider de son propre chef d’effectuer une action après avoir lu un message spécifique sur NATS.

Bien que de nombreuses règles de programmation aient été énoncées pour le projet, les composants de cette architecture distribuée présentent un certain niveau d’hétérogénéité. Dans ce contexte, il était crucial d’effectuer un travail important sur les définitions d’interfaces pour faire fonctionner tous ces modules ensemble. Ce sujet a été soulevé puis géré par l’équipe de Strasbourg. La solution (voir la présentation ADASS) que nous avons développée est basée sur des schémas JSON qui contraignent le vocabulaire, la structure des messages et la description des endpoints REST (OpenAPI) de la plupart des modules de traitement. Ces schémas sont gérés sur un dépôt GIT qui est utilisé comme référence commune.

Le Format des Données

Un autre problème majeur est de gérer les formats des produits (liste de mots-clés, vocabulaire autorisé…) de telle sorte que tout produit individuel puisse être récupéré, retraité et comparé avec d’autres instances. Cela suppose une description très fine de tous les produits tout au long de la mission. Toute modification d’un fichier scientifique doit être notifiée à tous les modules qui l’utilisent (producteur, consommateur, stockage).

Pour ce faire, on utilise des descripteurs de produits JSON. Ces descripteurs sont utilisés par la base de données (SDB) pour valider (accepter ou rejeter) l’ingestion du produit ; ils peuvent être utilisés par les pipelines pour vérifier si les fichiers générés sont conformes ou non. Ces descripteurs sont gérés sur un dépôt GIT qui propose également une suite complète de validation. Toute modification doit être validée par un comité dont le rôle est d’éviter les effets de bord dus à des modifications non contrôlée.

L’interfaçage avec l’Observatoire Virtuel

L’observatoire virtuel (VO) est une vision selon laquelle les ensembles de données astronomiques et autres ressources pourraient fonctionner comme un tout homogène. De nombreux projets et centres de données dans le monde entier travaillent à cet objectif. L’Alliance internationale de l’Observatoire virtuel est une organisation qui débat et définit les normes techniques nécessaires à la réalisation de l’OV. Elle sert également de point de convergence pour tous les contributeurs à l’OV, de cadre pour discuter et partager les idées et la technologie, et d’organe de promotion et de publication des standards (avec l’aimable autorisation de l’IVOA).

Les produits scientifiques MXT comprennent chacun une extension qui facilitera leur publication dans des ressources se conformant aux standards de l’OV ainsi que leur interopérabilité avec les produits d’autres missions. Ces extensions VO sont de deux types : 1) un ensemble de mots-clés Obscore qui décrivent la couverture le long des axes spatiaux, temporels et énergétiques et 2) une sérialisation JSON de la provenance du produit qui permet de reconstruire la chaîne de traitement à l’origine du produit.

Aladin Aladin Lite CDS Euclid fetedelascience gaia Journées du Patrimoine prix vidéo xmm