• Aucun résultat trouvé

Remplacement de certaines coupures nettes par des outils plus progressifs 80

3.3 Vers une nouvelle version du pipeline pour O3

3.3.2 Remplacement de certaines coupures nettes par des outils plus progressifs 80

Plus tôt, nous avons vu que certains vétos avaient posé des problèmes durant O2. Sans les problèmes de transfert des données entre Caltech et Cascina, le gating aurait supprimé les données relatives à GW170817, ne permettant ainsi pas de détecter cet événement. L’ex-traSNR quant à lui a empêché la détection de GW170814.

De plus, dans l’optique d’envoyer des alertes publiques et automatiques, il est nécessaire de limiter au maximum le risque de fausse alarme. Or, durant O2, certains outils de réjection des bruits n’ont pas été aussi efficaces qu’escompté.

Pour O3, il a été décidé de supprimer certains vétos utilisés par le pipeline, comme l’extraSNR ou la coupure MFO, et de les remplacer par des outils plus progressifs, incluant directement les informations relatives à la qualité dutrigger dans sa statistique de classement.

De plus, le gating a dû être retravaillé afin de réduire son temps de déclenchement, tout en augmentant son efficacité à identifier les bruits. Ces nouveaux outils feront l’objet des chapitres 4, 5 et 6.

3.3.3 Recherche dans plusieurs détecteurs ayant des sensibilités hétérogènes

O2 a aussi été marqué par l’arrivée de Virgo dans le réseau de détecteurs participant à la recherche d’onde gravitationnelle. Les instruments n’étant pas les mêmes, leur courbe de sensibilité et leur range sont différents (cf chapitre 1). Ainsi, au mois d’août 2017, le range de Virgo n’était que d’environ 25 Mpc, quand les LIGO atteignaient 60 et 100 Mpc.

De plus, il a été choisi de construire les LIGO de manière à faire coïncider leurs réponses d’antennes. Cela permet de faire coïncider les angles morts, et augmentant donc la proba-bilité d’obtenir une coïncidence. Pour Virgo, la collaboration a décidé de le placer dans la configuration inverse, minimisant les recouvrement avec les réponses d’antennes des LIGO.

En plus d’explorer leurs angles morts, cela permet une meilleure mesure des polarisations F+ et F× et des différents paramètres angulaires de l’équation 1.47.

Dans le futur, deux autres interféromètres, KAGRA et LIGO INDIA, rejoindront ce ré-seau. Tous deux auront des sensibilités et des orientations propres.

Pour O3, il convient donc d’adapter le pipeline MBTA pour traiter efficacement un tel réseau d’interféromètres aux sensibilités hétérogènes.

3.3.4 Développer et tester la nouvelle version avec des données de O2

Afin de développer cette nouvelle version du pipeline, il a fallu sélectionner des données à ré-analyser dans le but de développer et tester les nouveaux outils. Aucune donnée de O3 n’étant disponible avant cette période d’observation, ces tests ont été menés sur des jeux de données de O2.

Les six événements et les six bruits transitoires précédemment détaillés ont été sélection-nés pour faire partie de ces jeux de données. Pour chacun d’entre-eux, plus de trois heures de données ont été sélectionnées avant les candidats, dans le but d’accumuler assez de bruit de fond pour estimer leur FAR dans les mêmes conditions que l’analyse en ligne faite durant O2.

Afin de tester l’efficacité de la détection et de se rapprocher au maximum de la qualité des données que l’on puisse attendre pour O3, les données relatives aux événements sont des données nettoyées et re-calibrées après O2, généralement utilisées dans les analyses hors ligne. Dans le cas des bruits, il est plus intéressant d’utiliser les données brutes telles qu’elles ont été analysées en ligne. Cela permet de tester la capacité de réjection du pipeline dans les conditions les plus dures possibles. Finalement, grâce à l’ajout des outils présentés dans la suite, au retrait d’autres outils comme l’extraSNR, et à certaines optimisations du pipeline, tous les événements sont retrouvés avec des bons paramètres et des FAR significatifs, alors que les six bruits sont eux correctement rejetés par le pipeline.

Il est parfois nécessaire d’accumuler de la statistique pour développer et tester des outils.

Pour cela, six événements ne suffisent pas, il faut réaliser une campagne d’injections. Un jeu de données similaire à ce qui est présenté en chapitre 2 a donc été créé avec 24 heures de données calmes de O2 en guise de bruit de fond, au quel ont été superposées environ 500 injections. Ces données ont permis le développement de la plupart des outils présentés dans la suite de ce manuscrit. Mais, comme nous l’avons fait remarquer plus tôt, il sera plus pertinent ici d’utiliser le jeu de données défini en chapitre 2 pour illustrer leur efficacité sur des données de O3.

Enfin, en suivant l’avis des rapporteurs réalisant la revue dupipeline MBTA, un segment contenant des données quelconques de O2, d’une durée d’un peu plus de deux heures et choisi aléatoirement, a aussi été ajouté à ces jeux de données. Celui-ci ne contient ni injection, ni candidat significatif (événement ou bruit). Il permet de s’assurer du bon comportement de

l’analyse sur des données usuelles.

3.4 Conclusion

Dans ce chapitre, nous avons présenté l’état de l’art des résultats de l’analyse MBTAOn-line après la période d’observation O2.

Durant cette période, un certain nombre d’événements ont et n’ont pas été détectés par MBTA, alors que certains bruits ont quant à eux déclenché des alertes. Nous avons fait l’inventaire des ces candidats, et des raisons pour lesquelles certains d’entre-eux ont pu poser des problèmes à l’analyse en ligne.

Ensuite, nous avons vu les différents problèmes techniques de l’analyse, aveuglant parfois cette dernière. Ces pertes de cycles utiles ont plusieurs origines, que ce soit des limitations d’espace disque, des fuites de mémoire, des problèmes de communication, ou encore certains vétos de l’analyse qui impactent parfois des temps longs. Nous avons aussi abordé la question de la latence, qui, dans le cadre d’envoi d’alertes aux observatoires partenaires pour O2, ou d’alertes automatiques et publiques pour O3, est une caractéristique importante de la chaine d’analyse à faible latence.

Enfin, nous avons introduit le projet qui a motivé cette thèse, c’est-à-dire de concevoir et développer une nouvelle version du pipeline pour O3. En plus de corriger les différents problèmes techniques et logiciels, cette version doit prendre en compte les leçons de O2. Pour ce faire, certains vétos utilisés dans l’analyse de O2, doivent être remplacés par des outils plus ciblés et plus progressifs, basés sur des tests de compatibilité, et cherchant à estimer la vraisemblance des observations sous l’hypothèse de la présence d’un signal astrophysique. Il convient aussi d’adapter lepipeline à l’utilisation d’instruments aux sensibilités hétérogènes, et dans le futur aux instruments KAGRA et LIGO INDIA, qui n’auront pas les mêmes sensi-bilités ou les mêmes réponses d’antennes que les instruments actuels. Afin de développer ces nouveaux outils, un travail de sélection parmi les données de O2 a été réalisé pour construire des jeux de données sur lesquels la nouvelle version du pipeline a pu s’entraîner avant le début de O3.

Ce chapitre est un préambule à tous les développements présentés dans la suite de ce manuscrit. Nous allons donc maintenant détailler les différents outils développés pour O3, en commençant par le gating dans le chapitre 4.

Une analyse similaire à ce qui a été mené ici sur les résultats de O2 sera menée dans le cas de O3 dans le chapitre 7.

Traitement préliminaire des données

Sommaire

4.1 Introduction au gating . . . . 84 4.1.1 L’intérêt d’un outil agressif de traitement préliminaire des données 84 4.1.2 Utiliser l’évolution durange BNS pour déclencher legating . . . . 85 4.2 L’outil utilisé pendant O2 . . . . 85 4.2.1 Le fonctionnement dugating de O2 . . . 85 4.2.2 L’impact dugating de O2 sur les données . . . 86 4.3 Le gating utilisé pendant O3 . . . . 87 4.3.1 Fonctionnement du nouveaugating . . . 87 4.3.2 Effet sur les signaux ayant posé problème durant O2 . . . 88 4.4 Étude des risques du gating . . . . 90 4.4.1 Réaction dugating face à un signal de type CBC . . . 90 4.4.2 Étude statistique de l’impact dugating sur des injections . . . 91 4.4.3 Solution au problème des signaux courts . . . 97 4.5 L’effet du nouveau gating sur des données de O3 . . . . 100 4.5.1 Effet sur les bruits . . . 100 4.5.2 Impact sur le FAR des injections . . . 100 4.5.3 Effet sur la sensibilité de la recherche . . . 104 4.5.4 Conclusion sur les effets du gating . . . 105 4.6 Résumé des effets du nouveau gating pendant la période

d’ob-servation O3 . . . . 106 4.7 Conclusion . . . . 107

B

ienqu’avant d’être envoyées aux différentspipelines d’analyse les données soient net-toyées d’une partie des bruits, il n’est pas rare que certains bruits non-stationnaires survivent à ce traitement et arrivent jusqu’aux pipelines d’analyse.

Afin de gérer les plus intenses d’entre-eux, MBTA traite les données grâce à un outil appelé le gating avant de les analyser. Ce traitement consiste à identifier les moments trop dangereux pour l’analyse et à les retirer des données à analyser.

Dans ce chapitre, nous expliquerons tout d’abord l’intérêt d’un outil tel que le gating.

Puis, nous reviendrons sur celui utilisé durant O2, avant de parler du fonctionnement de la version développée pour O3. Ensuite, nous étudierons le comportement de cet outil envers des événements de type CBC. Enfin, nous résumerons l’impact de ce nouveau gating durant O3.

83

4.1 Introduction au gating

4.1.1 L’intérêt d’un outil agressif de traitement préliminaire des