Test de la carte trigger à Manchester

Cette phase de test a eu lieu en Juin 2018 à l’Université de Manchester. Les buts de ces tests de la chaîne électronique sont multiples :

• tester pour la première fois les parties transmission, réception et prise de décision de la carte trigger avec une chaîne complète de l’électronique ;

• utiliser un châssis trajectographe et un châssis calorimètre avec une carte frontale et une carte contrôleur dans chacun ;

• utiliser les muons cosmiques pour faire de l’acquisition de données après une prise de décision calorimètre + trajectographe avec des détecteurs.

Pour la partie calorimètre, deux barres de scintillateur couplées à des photomultipli-cateurs ont été utilisés. Pour la partie trajectographe, un prototype de 18 cellules Geiger

CHAPITRE 3. LE SYSTÈME DE DÉCLENCHEMENT ET D’ACQUISITION DE L’ÉLECTRONIQUE

présent à Manchester était disponible. Les cellules utilisées sont les mêmes que pour Su-perNEMO. Pour l’électronique, nous disposions de deux châssis. Le premier châssis, dédié pour le calorimètre, contenait la carte contrôle calorimètre ainsi que deux cartes frontales. Le second châssis, dédié au trajectographe, contenait la carte contrôleur trajectographe et une carte frontale. Les deux cartes contrôleurs étaient branchés sur la carte trigger au moyen d’un réseau Ethernet.

Les premiers tests ont consisté à générer une décision calorimètre sur la base d’une multiplicité égale à un ou deux photomultiplicateurs touchés. La dynamique des photo-multiplicateurs utilisés étaient proche de celle de SuperNEMO. Nous avons pu facilement obtenir un signal calorimètre dans la carte frontale. Les primitives trigger calorimètre créées remontaient ensuite de la carte frontale vers la carte contrôleur puis vers la carte trigger. Des acquisitions de données en calorimètre seuls ont été effectué validant ainsi le bon fonctionnement de la chaîne calorimètre. Au vu de la surface des lames de scintillateur, le taux attendu de muons était de l’ordre de 5 Hz. En décision calorimètre avec un seul scintillateur touché et un seuil à 50 mV, le taux obtenu expérimentalement était d’environ 3 Hz. En plaçant les deux lames de scintillateur l’un au-dessus de l’autre et en fixant la multiplicité égale à 2, le taux obtenu était inférieur à 1 Hz.

Une fois le volume de la chambre remplie de gaz (hélium), les cellules branchées et mises sous tension, les deux barres de scintillateur ont été placées respectivement au-dessus et en-dessous du prototype de 18 cellules pour la recherche de coïncidences calorimètre-trajectographe. Un schéma et une photo du dispositif expérimental sont visibles en figure 3.29. PMT B Row 0 Row 1 PMT C 3 meter 18 Cells tank Muon 120 cm

Figure3.29 – Schéma (à gauche) et photographie (à droite) du dispositif utilisé à Manchester. Des décisions L2 CARACO ont pu être générées avec un seuil de multiplicité en calo-rimètre égal à un ou deux. Le fait de demander explicitement deux calocalo-rimètres garantit qu’un muon a bien traversé la chambre mais le nombre d’évènements était très faible (taux < 0,1 Hz) à cause de la surface réduite des barres de scintillateur. Une fois la décision L1 calorimètre validée, la fenêtre de coïncidence s’ouvrait pendant 8 µs. Les algorithmes pour la recherche de traces préparés en amont et implémentés dans la carte trigger ont fonc-tionné directement avec les détecteurs. Cela valide le fait que les primitives trigger pour la partie trajectographe ont bien été générées et qu’elles sont cohérentes car la carte trigger a pu valider le fait qu’un agrégat de cellules spatialement proches ont déclenchées au même moment. Une fois la décision prise, la carte trigger envoyait ce signal L2 aux cartes contrô-leurs puis aux cartes frontales pour l’acquisition de données. La stratégie d’acquisition consistait à venir vider les puces des cartes frontales ayant déclenchées puis prendre tous

CHAPITRE 3. LE SYSTÈME DE DÉCLENCHEMENT ET D’ACQUISITION DE L’ÉLECTRONIQUE les registres trajectographes jusqu’à 100 µs après la décision L2. Pour chaque cellule du trajectographe, seule la voie anodique et une des deux voies cathodiques étaient branchées sur la carte frontale. L’acquisition du registre pour le temps t6 associé à une des cathodes n’a donc jamais été effectuée mais l’acquisition des cinq autres temps a été possible. Une erreur dans le firmware a été découverte concernant l’acquisition de données dans les cartes frontales calorimètre. En mode L2, la carte frontale envoyait ses données à l’acquisition dès qu’elle avait une décision L1. En conséquence, nous avions des évènements calorimètres seuls alors qu’une coïncidence calorimètre trajectographe était explicitement demandée. Un exemple d’évènement obtenu avec deux photomultiplicateurs touchés et suffisamment de cellules Geiger pour valider une décision L2 est présenté en figure3.30.

Le bilan de cette phase de test à Manchester est très positif car nous avons pu tester et valider la quasi-totalité de la chaîne électronique. Le prototype de 18 cellules a permis de montrer que les primitives trigger du trajectographe étaient bien générés dans les cartes frontales. Deux châssis ont été utilisés avec chacun une carte contrôleur spécifique pour le calorimètre et le trajectographe. C’était aussi la première mise en service de la carte trigger avec de vrais détecteurs en condition de fonctionnement en temps réel. Des erreurs dans le firmware des cartes frontales ont été trouvées et corrigées.

muon PM 1 PM 2 Plans Rangée 1 Rangée 0 0 8

Figure 3.30 – Vue de face d’un évènement obtenu avec le dispositif de Manchester après une décision CARACO (calorimètre + trajectographe). Au moins un des deux calorimètres a

déclenché et au moins 3 plans de cellules (en projection) ont été touchées.

Conclusion

Ces différentes phases de test nous ont permis de valider les stratégies de prise de décision et d’acquisition des données. Le firmware implémenté dans les cartes est lui aussi validé de par le bon fonctionnement avéré de la chaîne électronique. La génération et la remontée des primitives trigger des cartes frontales aux cartes contrôleurs puis à la carte trigger permettent la réalisation de coïncidences calorimètre-trajectographe grâce aux algorithmes présents dans le firmware de la carte trigger. Ces coïncidences sont cohérentes en temps et en espace. Avant l’intégration finale in-situ, d’autres tests avec des injecteurs de signaux dans les cartes électroniques frontales devront avoir lieu afin de vérifier que chaque voie génère à la bonne position sa primitive trigger associée. Cela permettra également de tester en profondeur les algorithmes de prise de décision en parcourant chacune des

CHAPITRE 3. LE SYSTÈME DE DÉCLENCHEMENT ET D’ACQUISITION DE L’ÉLECTRONIQUE

20 zones fictives du trigger. Toutes ces phases de tests sont nécessaires afin de garantir une bonne intégration lors de l’installation finale au Laboratoire Souterrain de Modane. Le début de l’intégration électronique se fera en septembre 2018.

Chapitre 4

Développement logiciel et

modélisation : Falaise

L’environnement logiciel de la collaboration SuperNEMO pour la simulation et le trai-tement des données est nommé Falaise. Falaise est opérationnel depuis plusieurs années et s’inscrit dans la continuité des outils logiciels développés dans le langage C++ pour l’expé-rience NEMO-3 puis pour la R&D SuperNEMO entre 2005 et 2012. Il a été essentiellement conçu et développé par le groupe du LPC Caen avec des contributions significatives no-tamment du LAL à Orsay.

Cette suite logicielle permet la génération des données de simulation, le traitement des données Monte-Carlo ainsi que celles issues du détecteur. Des algorithmes spécifiques de simulation, de calibration et de reconstruction permettent de réaliser une analyse complète de différents jeu de données.

Ce chapitre présente cet environnement logiciel basé sur les outils développés au sein de la collaboration. Les principales phases de traitement des données de Falaise seront présentées et plus particulièrement les fonctionnalités développées durant cette thèse :

• Le système de déclenchement de l’électronique a été entièrement implémenté de manière logicielle afin d’en explorer les principes et de pouvoir les valider par une approche Monte-Carlo ;

• La mise au point du format des données issues de l’électronique a permis de proposer à la collaboration un modèle pour les données réelles telles que produites par le système d’acquisition de l’expérience. Une stratégie préliminaire de construction des évènements a été mise en place pour les différentes phases de tests et servira pour la stratégie finale.

4.1 Environnement logiciel

L’ensemble de l’environnement logiciel de la collaboration s’appuie sur des thèques existantes développées et validées par la communauté scientifique. Des biblio-thèques logicielles éprouvées telles que Boost, Geant4 [100], ROOT [101] ou encore la

GNU Scientific Library (GSL) sont utilisées par la collaboration SuperNEMO. La chaîne

logicielle respecte les contraintes suivantes :

• Portabilité sur postes de travail typiques (Linux, macOS) et fermes de calcul (CCIN2P3) ; • Modularité et confinement des fonctionnalités ;

• Utilisation de techniques et langages de programmation modernes (Programmation Orientée Objet (POO), C++ standard. . .) ;

CHAPITRE 4. DÉVELOPPEMENT LOGICIEL ET MODÉLISATION : FALAISE • Utilisation d’outils de gestion : versionnage (Git), hébergement et développement

collaboratif (GitHub, GitLab). . . ;

• Utilisation et publication de bibliothèques sous licence libre (Open source) ;

• Unification des modèles de données, outils d’entrée-sortie, gestion et formats des configurations.