2.7.1 Le programme Athena
ATHENA est l’environnement logiciel d’ATLAS. Il est basé sur Gaudi [42] développé
initialement par la collaboration LHCb et ensuite conjointement avec la collaboration ATLAS. Il est conçu pour permettre de traiter les données des systèmes de déclenche-ment de même que les données des systèmes d’acquisition. Il doit aussi permettre aux physiciens d’accéder aux données traitées et leur fournir les outils d’analyse. La grande complexité du détecteur ainsi que la variété de la physique étudiée nécessite d’avoir un logiciel modulaire, robuste tout en étant flexible. La programmation orientée objet est idéale pour les besoins de l’expérience, ainsi le langage de programmation utilisé est le
C++ couplé au Python. Certains composants externes au logiciel sont en Fortran
tels les générateurs Monte-Carlo, ou en Java, tels les outils de visualisation d’évènements (Atlantis). ATHENA est composé de modules, ou packages, et d’interfaces qui permettent d’utiliser les modules indépendamment. On peut donc modifier une partie du programme sans impacter sur le comportement des autres modules. On utilise aussi les jobOption, fichiers codés en Python, pour effectuer les configurations laissées libres à l’utilisateur, et pour définir la valeur de certains paramètres utilisés dans les modules.
Deux types de logiciels sont utilisés :
– les algorithmes dérivent de la classe Algorithm. Ils comportent au minimum trois méthodes, Initialize et Finalize qui ne sont utilisés qu’une fois au début et à la fin de l’éxecution, pour configurer, charger les outils et libérer les mémoires utilisées. La méthode Execute contient la boucle principale de traitement de chaque évènement. – les outils dérivent de la classe AlgTool. Ce sont des programmes outils pouvant être appelés par l’algorithme principal plusieurs fois si nécessaire. Ils peuvent aussi être utilisés par plusieurs Algorithms.
Les données sont contenues dans des datasets de différents formats et tailles. Leur accès se fait via StoreGateSvc, base de donnée stockée en mémoire enregistrant les réfé-rences des différents objets utilisés. Ces objets sont eux contenus dans des blocs appelés container, dont les objets sont reliés entre eux par des ElementLink. Par exemple l’ob-jet electron dérivant de la classe egamma est contenu dans un electronContainer et est lié aussi aux objets dans le container EMClusterContainer, trackParticleContainer par des ElementLink contenant les références aux objets traces et cluster reconstruits de l’électron dans leur container respectif. Ainsi, aucune information n’est dupliquée dans ATHENA, ce qui ne serait pas possible vu le flux de données attendu lors des prises de données.
Il existe différents types de formats de données. Les RDO (Raw Data Object) contiennent toutes les informations brutes reçues par le détecteur. Les ESD (Event Data Summary) contiennent les évènements reconstruits au complet, ayant par conséquent une taille très importante et ne sont pas distribués partout. Les AOD (Analysis Object Data) ne contiennent qu’une partie des informations des ESD nécessaire aux analyses de physique. Ils ont une taille de 20% de celle des ESD afin d’être distribués partout dans le monde. Un dernier type de lots de données a été récemment mis au point et est utilisé pour les premières analyses de données, les D3PD, en fait des ntuples lisibles directement sous Root, afin de permettre une analyse conjointe et la vérification multiple des premiers résultats. Le schéma 2.25 donne les différents flux de données aux différentes étapes du logiciel.
Figure2.25 – Schéma simplifié des flux de données [41]
2.7.2 La grille de calcul
La grille de calcul a été développée pour mettre en commun des ressources infor-matiques du monde entier, et pour permettre une puissance et une rapidité de calcul inégalées. Elle est réalisable grâce à l’amélsioration des débits de transfert de données (internet) permettant la transmission rapide d’un grand flux de données.
Les expériences du LHC, dont ATLAS, ont décidé de développer le traitement de leurs données à l’aide de la grille de calcul. En effet, le flux de données attendu, la taille des collaborations internationnales (près de 3000 membres pour ATLAS) nécessitent une utilisation optimale des ressources mondiales de calcul et la répartition des données dans les différents centres en vue de leur analyse. Les types des centres de calcul LCG (LHC
Computing Grid) sont au nombre de trois (figure 2.26). Tout d’abord le Tier0 est la ferme
de calcul du CERN, lieu d’acquisition des données. Son rôle est de stocker les données acquises à long terme, la distribution aux Tier1 (il y en a 11 dans le monde) et la partici-pation à l’activité de reconstruction. Les Tier1 reçoivent une partie des données du Tier0, assurent leur stockage à long terme et contribuent à l’essentiel de la reconstruction. Ils peuvent éventuellement participer à l’analyse des données. En France, le Tier1 est situé au centre de calcul de l’IN2P3 à Lyon. Les Tier2 enfin sont utilisés pour l’analyse des données et les simulations Monte-Carlo. Ce sont généralement des fermes plus petites et il en existe quatre à cinq fois plus que de Tier1. Ils ont aussi une grande capacité de stockage. Le LAL possède une ferme de Tier2.
Dans ATLAS, deux interfaces de la grille peuvent être utilisées conjointement avec
ATHENA: panda et ganga. Concrètement un job envoyé sur la grille est divisé en sous-jobs
plus petits qui sont exécutés simultanément sur différents ordinateurs d’une ferme de calcul. Le temps d’exécution est donc divisé d’autant. Il serait impossible de travailler sans la grille de calcul dès lors que la statistique d’un dataset devient importante, et a fortiori sur les données.
2.7.3 Outils et formats utilisés lors de cette thèse
Pendant cette thèse j’ai été amenée à utiliser plusieurs outils et formats de données : – la grille de calcul
– des données simulées ou réelles en format AOD.
– des ntuples privés construits à partir des AOD à l’aide de la grille pour des analyses intéractives
– des D3PD standards, copiés localement et lus intéractivement pour l’analyse des premières données.
Chapitre 3
La reconstruction des électrons dans
ATLAS
L’efficacité de la recherche du boson de Higgs dans le canal H → ZZ∗ → 4 électrons
dépend essentiellement de la qualité de la reconstruction des électrons et de leur identi-fication. En effet, elle varie comme la puissance quatre de l’efficacité de reconstruction des électrons. Particulièrement à basse masse, 120-130 GeV, certains électrons issus de la désintégration du Higgs ont des énergies très basses, de l’ordre de quelques GeV. Il est donc crucial d’avoir les meilleures performances, à commencer par la reconstruction,
sur une gamme d’énergie très large. La région à bas pT est la plus difficile à maîtriser à
cause du bruit de fond QCD important, et aussi des effets de matière dont l’impact sur le comportement des électrons est plus important, comme nous le verrons.
C’est dans l’optique de contribuer à l’amélioration des performances, tout particulière-ment à basse énergie, que je me suis investie dans l’amélioration de la reconstruction et de l’identification des électrons. Dans ce chapitre,la logique de reconstruction des électrons va être présentée en détails. Je présenterai donc :
– dans un premier temps la reconstruction des électrons,
– je détaillerai ensuite la reconstruction des dépôts électromagnétique et des traces, – enfin je décrirai la méthode d’extrapolation des trajectoires des particules d’une
surface à une autre dans ATLAS.
Ce sont des outils que j’ai eu besoin de comprendre pour ensuite les utiliser en vue d’améliorer les performances de reconstruction, ce que nous verrons au chapitre suivant. La reconstruction des électrons est une partie du programme egamma, qui gère la reconstruction et l’identification des particules électromagnétiques, électrons et photons. Un tel objet est par conséquent désigné par le nom "egamma" d’une manière générique.
3.1 Reconstruction des objets électrons
D’une manière générale, un objet "électron" est un objet egamma constitué d’une trace reconstruite pointant vers un dépôt électromagnétique. On appelle "candidat élec-tron" tout objet électron reconstruit. Deux programmes de reconstruction des électrons sont implémentés dans le programme ATHENA :
– le programme standard définit des électrons "egamma". Il cherche une trace re-construite pointant vers un dépôt électromagnétique reconstruit par l’algorithme
Sliding Window. Nous allons décrire cet algorithme plus en détail dans cette
sec-tion. Si aucune trace n’est trouvée, l’objet egamma sera considéré comme un photon non converti et suivra la chaîne de reconstruction des photons. Pour l’utilisateur, la reconstruction utilisée est indiquée par la valeur d’un entier author. Les électrons ainsi reconstruits portent la valeur author = 1.
– une reconstruction spéciale est utilisée particulièrement pour les électrons de très basse énergie, de l’ordre de quelques GeV, appelés "Softe". L’algorithme Sliding
Window ayant un seuil à 2.5 GeV, tous les électrons d’énergie inférieure ne sont
pas reconstruits par la méthode standard. L’algorithme Softe part de traces recons-truites de bonne qualité pointant vers un dépôt d’énergie relativement isolé. Cette méthode ne sera pas détaillée ici. Les électrons ainsi reconstruits portent la valeur author = 2.
Un électron peut être egamma et softe s’il est reconstruit par les deux méthodes. Dans ce cas, dans egamma on trouve un candidat électron portant la valeur author = 3 (soit author = 1 et 3).
Les méthodes de reconstruction des traces et des dépôts électromagnétiques par le
Sliding Window seront décrites dans les deux sections suivantes.
Par la suite, les candidats électrons suivent une chaîne d’algorithmes décrits ci-dessous.
3.1.1 Accord trace-dépôt EM : EMTrackMatchBuilder
Dans un premier temps, une trace reconstruite est recherchée en face de chaque dépôt d’énergie reconstruit. La trace est acceptée si elle est contenue dans une fenêtre ∆η × ∆ϕ =0.1×0.2. La fenêtre est plus large en ϕ pour tenir compte des effets de rayonnement bremsstrahlung qui modifient la trajectoire en ϕ de l’électron à cause de la rotation dans le champ magnétique. En effet, plus la trace perd de l’énergie, plus elle est courbée. Ensuite
une coupure est appliquée sur le rapport Edepot/Ptrace <10 (jusqu’en 2009). Si la trace
est acceptée, l’objet est considéré comme un électron. L’objet EMTrackMatch, contenant toutes les variables relatives à l’association entre trace et dépôt électromagnétique, est alors enregistré dans le conteneur correspondant, et le pointeur vers cet objet est enregistré dans l’objet électron.
3.1.2 Taille du dépôt EM et forme de la gerbe
Ensuite la taille du dépôt électromagnétique est ajustée (3×7 pour le tonneau et 3×5 pour les bouchons), et il est calibré en tant qu’électron. Les caractéristiques du dépôt sont mises à jour et enregistrées, le pointeur vers le dépôt est attaché à l’électron.
L’algorithme EMShowerBuilder calcule des variables caractérisant la forme de la gerbe électromagnétique qui seront utilisées plus tard dans l’identification. Il crée l’objet EM-Shower et l’attache au candidat électron.
3.1.3 Calcul du quadrivecteur
L’algorithme EMFourMomentumBuilder construit ensuite le quadrivecteur de l’électron en utilisant les informations de la trace et du calorimètre. Initialement, l’impulsion était déduite de la trace et l’énergie du calorimètre mais il a été décidé de combiner les deux informations selon différents cas. Le tableau 3.1 décrit la méthode de reconstruction du quadrivecteur. Combinaison trace-dépôt σ = & (Edepot−Ptrace)2 (σ2 Edepot+σ2 Ptrace) σ < 3 σ ≥ 3
E provient toujours du dépôt E est une combinaison de Etrace et de Ptrace
N nombre de points de mesures Si
N>3 N≤3
η vient de ηtrace η combinaison de ηtrace et ηdepot
ϕ vient de ϕtrace ϕ vient de ϕtrace
Tableau 3.1 – Méthode de calcul du quadrivecteur
3.1.4 Autres outils de reconstruction
D’autres outils de reconstruction sont utilisés ensuite. Ils sont processés automatique-ment mais pas utilisés de manière standard. L’algorithme EMBremsstrahlungBuilder reconstruit à nouveau les traces avec des méthodes très élaborées mais très couteuses en ressources de calcul. Les performances de ces algorithmes ne sont pas encore optimales et ils ne sont pas utilisés pour l’instant par défaut. Un algorithme de construction de variables d’isolations est aussi disponible.
Enfin, un algorithme d’identification est appliqué pour sélectionner les électrons réels et rejeter les faux électrons (jets...). Cet algorithme est décrit dans le chapitre 4.