FastGeoModel et XML

Pendant la phase de prototypage et de développement des géométries ITk, le programme

paramé-trique IDRes [ref43] a servi de base pour l’ évaluation rapide des résolutions sur les paramètres des

traces, de l’herméticité du détecteur et du nombre de points de mesure en fonction de la pseudo-rapidité.

Ce programme est cependant insuffisant pour évaluer véritablement les performances du détecteur

final. Il ne tient pas compte de la redondance des points de mesure due à la superposition des modules

dans certaines régions, considère un effet moyenné de diffusion élastique avec une localisation

approxi-mative de la matière inerte du détecteur, la création de particules secondaires est inexistante et les

dépôts d’énergie issus du pile-up ne peuvent pas être simulés. Ces effets ne peuvent être intégrés que

dans le framework de simulation complète du détecteur.

Le programme de simulation complète d’ATLAS utilise une description géométrique basée sur des

librairies GeoModel [ref44]. Cette géométrie est ensuite convertie dans une géométrie Geant4 [ref45] ou

une géométrie de reconstruction, la TrackingGeometry [ref46] dans notre cas. En 2014, deux

difficul-tés majeures empêchaient la collaboration ATLAS de réaliser les études en simulation complète qui

auraient permis de choisir le meilleur détecteur ITk rapidement, et sans ambiguité :

1. L’expertise technique nécessaire à l’implémentation d’un GeoModel pixel se trouvait dans les

mains d’une seule et unique personne pour toute la collaboration ATLAS : Sabine Elles, ingénieure

en informatique au LAPP. Son implication déjà très importante sur la simulation du détecteur IBL

ne lui permettait pas de dégager suffisamment de temps pour développer et assurer le suivi d’un (ou

plusieurs) GeoModel ITk.

2. Même en supposant que le GeoModel ITk soit disponible, les classes de TrackingGeometry

exis-tantes ne permettaient pas d’extrapoler les trajectoires dans les structures contenant des modules

inclinés. La Figure 44 montre que pour naviguer dans une couche pixel contenant des modules inclinés

et extraire la liste des surface de tracking, il faut pouvoir déterminer à la fois le point d’entrée et le

point de sortie, ce qui n’est pas prévu pour les classes de tracking classiques basées sur des cylindres ne

contenant que des modules horizontaux. De nouvelles classes étaient en cours d’implémentation dans

le framework Athena, mais toute la validation du tracking restait à faire.

Figure 44 – Représentation schématique de la navigation dans une couche de pixels. Pour des modules

horizontaux, le point d’entrée dans la couche de tracking est suffisamment proche du point de sortie

pour permettre d’identifier de manière unique un module et son plus proche voisin. Dans le cas de

modules inclinés, le nombre de surfaces actives touchées dépend de la distance parcourue et de l’angle

de la trajectoire à l’entrée du volume de tracking.

Pour tenter de faire avancer les choses, le LAPP a proposé en 2014 que Sabine Elles réorganise

entièrement le code C++ du GeoModel ITk Pixel en packages indépendants

. L’idée était de parvenir à

encapsuler toutes les connaissances techniques de Sabine dans des “boites noires”, et de rendre ces boites

configurables de façon suffisamment intuitive pour qu’un collaborateur non expert puisse facilement

construire un FastGeoModel à partir de paramètres simples : nombre de couches, nombre de disques,

rayons des cylindres, taille des modules pixels, pitch, inclinaison des modules, angle de tilt des échelles,

matériaux (tubes de refroidissement, câbles, structure mécanique, etc.. ). L’objectif était de fournir

à la collaboration un outil permettant de réaliser “rapidement” des études en simulation complète de

plusieurs géométries en parallèle, et de pouvoir choisir ainsi objectivement la meilleure solution pour

optimiser les performances de physique.

Rémi Lafaye et moi-même avons pris en charge l’écriture du package d’interface “physicien”, basé sur

l’utilisation de fichiers XML

qui permettait deux choses : en premier lieu, construire la TrackingGeometry

en s’affranchissant du GeoModel, et dans un second temps, utiliser ce même package pour configurer

la construction du FastGeoModel associé, indispensable pour produire les cartes de matière précises

utilisées par le tracking. L’imbrication de ces différents éléments est illustrée sur la Figure 45.

Concernant la validation, nous avons interfacé ces nouvelles géométries de tracking avec FATRAS

[ref47], en étroite collaboration avec Andreas Salzburger (CERN) et Noemi Calace (Unige). La

recons-truction des hits a été validée pour toutes les configurations de détecteurs possibles : LoI, Inclined,

Extended, avec rings, avec disques, et même hybrides, comprenant à la fois des couches de modules

inclinés et des couches cylindriques standard. La Figure 46 montre la reconstruction des hits dans

FATRAS pour une configuration de détecteur incliné. La Figure 47 montre les visualisations de la

TrackingGeometry avec le logiciel VP1 [ref48], et la Figure 48 présente des vues 3D des FastGeoModel

configurables de Sabine Elles.

10. https://twiki.cern.ch/twiki/bin/view/Sandbox/FastGeoModelGeometryImplementationGuide 11. https://twiki.cern.ch/twiki/bin/view/Sandbox/CustomGeometryImplementationGuide

3.3 Simulation ITk 39

Figure 45 – Contributions du LAPP pour permettre une construction rapide de géométries ITk

configurables via des fichiers XML.

Figure 47 – Visualisation 3D avec le logiciel VP1 des surfaces de tracking et des hits simulés dans

FATRAS pour plusieurs géométries de détecteurs ITk

3.3 Simulation ITk 41

Il aura fallut plus de deux ans pour que ce travail aboutisse et soit entièrement intégré et validé

dans le framework de simulation complète d’ATLAS. Deux packages FastGeoModel contenant les bases

nécessaires au développement de deux concepts de détecteurs concurrents ont été fournis par Sabine

Elles à la communauté ITk : le package Extended pour l’équipe de Berkeley, et le package Inclined

pour l’Université de Genève. Ces deux détecteurs sont présentés sur la Figure 49.

Figure 49 – Vue longitudinale des deux géométries concurrentes pour le détecteur ITk étendu jusqu’à

|η| < 4 : Inclined layout (haut) et Extended layout (bas).

Les premiers lots de données en simulation complète ont pu être produits à partir de l’été 2016,

autorisant enfin une comparaison objective des deux propositions de détecteurs. En janvier 2017, la

3.3 Simulation ITk 43

Layout Task Force rend son rapport définitif [pub11], qui prône la construction d’un détecteur à pixels

“embrassant les propriétés du concept incliné”. La Figure 50 montre la comparaison des performances

des deux géométries concurrentes pour la reconstruction du paramètre d’impact transverse de muons

isolés de faible impulsion. La Figure 51 montre les résolutions sur les paramètres des traces dans

des événements t¯t superposés avec 200 événements de pile-up, plus représentatives des processus de

physique attendus au HL-LHC.

Figure 50 – Résolution sur le paramètre d’impact transverse pour des muons isolés de P

=1 GeV, en

fonction de la pseudo-rapidité, pour les géométries “Inclined” et “Extended”

L’ensemble des comparaisons de performance entre les deux géométries peut être consulté dans

le rapport de la Layout Task Force, et de nombreux résultats annexes sont discutés dans l’excellent

manuscrit de thèse de Noemi Calace [ref49].

Figure 51 – Résolution sur le paramètres d’impact transverse d

, longitudinalz

et impulsion

trans-verse relative pour des traces provenant des paires de quarks top, générées avec 200 événements

d’em-pilement, pour les géométries “Inclined” et “Extended”. La géométrie inclinée montre des performances

significativement meilleures, en particulier dans la région à très grande pseudo-rapidité où le bruit

d’empilement est le plus dense.

3.3 Simulation ITk 45