La méthode
Idéalement, les valeurs run par run des corrections d’acceptance × efficacité de- vraient être obtenues en exécutant la totalité des étapes détaillées dans la sectionV.2
run number South North 151239 0 2 152099 0 2 154658 0 2 156569 0 2 156862 0 3 157311 0 2 158994 2 5 159112 3 5
T. V.1: Nombre de FEM non opérationnelles pour le MuTr (bras Sud et Nord) pour les runs utilisés pour l’évaluation de la dispersion sur les corrections d’acceptance × efficacité lors de l’analyse préliminaire.
(page124) pour chacun des bons runs.
C’est ainsi que nous avons procédé pour les quelques runs de l’analyse prélimi- naire. Mais ce grand nombre d’étapes intermédiaires prendrait un temps bien trop important si nous devions faire de même pour la totalité des bons runs. De plus, les effectuer toutes n’est pas tout-à-fait indispensable. En effet, si la multiplicité vue par le détecteur varie assez peu d’un run à l’autre, alors seule l’étape #4 (la réponse du détecteur) a un impact significatif sur les variations d’acceptance × efficacité. La rai- son est la suivante : c’est pendant cette étape que les hits Monte Carlo sont convertis en hits au sens des données réelles en faisant intervenir une description réaliste de la configuration du détecteur. L’idée est donc de recourir au même lot de J/ψ Monte Carlo et au même lot correspondant de bruit de fond provenant de vraies don- nées, mais de varier la configuration du détecteur. Par conséquent, les étapes #1 à #3 sont exécutées une seule fois.
Les éléments7décrivant la configuration du détecteur qui peuvent varier d’un run à l’autre sont :
– la configuration des hautes tensions pour le MuTr i.e. les anodes volontaire- ment éteintes et celles temporairement et involontairement inactives (enregis- trée sur fichiers) ;
– les gains et piédestaux nécessaires pour reproduire la numérisation des charges sur les cathodes par les ADC du MuTr (en mémoire dans la base de données) ; – le nombre de FEM non-opérationnels pour le MuTr (en mémoire dans la base
de données).
7Les efficacités des bi-pack du MuID varient aussi d’un run à l’autre. Cependant, nous avons utilisé un seul et même ensemble de fichiers (un par bras) pour les décrire, ceux-ci contenant les efficacités moyennes par bi-pack sur l’ensemble de la prise de données. Cf. sectionB.1.3.
Quelques précautions à considérer
Le raisonnement que nous venons d’exposer repose sur l’hypothèse selon la- quelle le taux d’occupation des bras muons n’a pas subi de fluctuations importantes tout au long de la prise de données. Cette hypothèse n’est pas déraisonnable au pre- mier abord, au moins en ce qui concerne les conditions de faisceau. En effet, celles-ci étaient plutôt stables tout au long du Run 5 : la collimation était réalisée très vite en début de vie du faisceau, ce qui induit à l’arrière du MuID de faibles variations de la pollution en particules issues des interactions avec le tube à vide du faisceau. Ceci a eu pour conséquence que le MuID pouvait être mis sous (haute) tension tout aussi vite, d’où une luminosité exploitée par les bras muons très proche (environ 92%) de la valeur enregistrée par PHENIX. Cette maîtrise des conditions de faisceau im- plique également que le taux de collisions est resté stable durant la prise de données exploitables pour la physique. Néanmoins, ceci ne nous dispense pas de vérifier que la multiplicité enregistrée au niveau des bras muons est restée stable durant la période de prise de données.
Il faut aussi choisir avec précaution le run duquel nous allons tirer le lot de hits qui serviront de bruit de fond : par exemple, nous devons éviter que, pour ce run, il y ait des zones mortes, donc dépourvues de hits, à des endroits du détecteur qui ne seraient pas identiques entre tous les runs. Imaginons que, par inadvertance, cette cir- constance se présente : nous avons extrait notre bruit de fond d’un run A pour lequel le demi-octant a d’une des stations du MuTr s’est arrêté de fonctionner pendant la prise de données. Durant le run B, le demi-octant a était tout-à-fait fonctionnel mais le demi-octant b ne l’était pas. Selon la méthode que nous avons précédemment ex- posée, nous voulons connaître les corrections d’acceptance × efficacité pour le run B en insérant des J/ψ Monte Carlo dans les données réelles issues du run A et en ap- pliquant la configuration du détecteur en vigueur pendant le run B. En conséquence, nous n’aurons que des hits Monte Carlo sur le demi-octant a puisque celui-ci n’a pu enregistrer le passage d’aucune particule pendant la prise de données du run A. Cela va biaiser la valeur ainsi « prédite » d’acceptance × efficacité du run B puisque l’absence de bruit de fond dans le demi-octant a va faciliter la reconstruction. Notons que la valeur vraie d’acceptance × efficacité, dénommée « acceptance × efficacité réelle », aurait été obtenue en insérant les J/ψ Monte Carlo dans le bruit de fond issu du run B et auquels aurait été appliquée la configuration du détecteur selon ce même run B. Profitons de cet exemple pour mettre au point notre vocabulaire : le run B sera connu par la suite sous le nom de « run de configuration », le run A peut-être considéré comme un « run de référence » en matière de bruit de fond. La seule dif- férence entre l’acceptance × efficacité prédite et l’acceptance × efficacité réelle est donc l’origine des hits de données réelles qui font office de bruit de fond. La méthode présentée peut ainsi être validée en comparant, pour un échantillon de runs, les valeurs réelles et prédites de l’acceptance × efficacité.
Une autre condition sur le run de référence est que sa distribution en centralité ne comporte pas d’anomalies (distribution plate). Il faut aussi que sa distribution de la position zvtxdu vertex soit typique (centrée à environ zéro, de largeur standard entre
20 et 30 cm).
Une autre précaution importante concerne la manière dont nous allons déterminer la valeur moyenne de l’acceptance × efficacité une fois tous les runs de configuration parcourus. Pour être complètement rigoureux dans ce calcul, chaque run devrait plu- tôt contribuer à hauteur du nombre d’événements BBCLL1 obtenus après coupure sur le zvtxet appartenant à un croisement physique des paquets d’ions. Mais l’ana- lyse préliminaire a montré que la variation d’un run à l’autre de la distribution en zvtxdes événements est petite. D’autre part, comme le montre la figureV.3, la frac- tion d’événements non issus de croisement physique des paquets d’ions est faible (1 − 2%) dans l’intervalle considéré pour le vertex ( |zvtx| < 30 cm ). Ces coupures vont donc affecter de manière très similaire le nombre d’événements BBCLL1 pour chaque run. En conséquence, le pourcentage d’événements perdus peut être consi- déré comme indépendant du numéro de run et on peut le mettre en facteur lors du calcul de la moyenne : utiliser le nombre d’événements BBCLL1 obtenu après ou avant coupures est donc équivalent. Bien entendu, il est plus commode d’utiliser ce dernier nombre puisqu’il peut être directement lu dans la base de données.
F. V.3: Évolution en fonction du numéro de run du pourcentage d’événements minimum biasrejetés car n’appartenant pas à un croisement physique des paquets d’ions. Le vertex des événements considérés avant d’appliquer cette coupure est dans la tranche |zvtx|< 30 cm.
La réalisation
Le run 152099, déjà utilisé, possède toutes les qualités requises telles que nous les avons énoncées précédemment :
– en terme de zones mortes (cf. sectionsIV.1.4etB.1.1), puisque c’est un run à zones mortes minimales dans le MuTr, et les anodes/FEM désactivées pendant ce run l’ont été pendant toute la prise de données du Run 5 ;
– en terme de distribution en centralité et en vertex (cf. FigV.4) ;
– en terme de multiplicité enregistrée au niveau du détecteur, comme nous le verrons dans la section suivante.
Ce run est donc à double titre8 un run de référence. Nous avons ainsi bénéficié du lot de J/ψ Monte Carlo et du lot de bruit de fond issu de l’étude d’acceptance × efficacité utilisant ce seul et unique run. Mais pour raccourcir davantage le temps consacré à chaque run de configuration de la liste, nous avons réduit la statistique utilisée (environ 118 mille événements au lieu des ∼ 249, 4 mille disponibles pour l’embedding). Zn30to30cent_152099 Entries 249372 Mean 47.54 RMS 27.1 centrality(%) 0 20 40 60 80 100 0 0.002 0.004 0.006 0.008 0.01 0.012 0.014 Zn30to30cent_152099 Entries 249372 Mean 47.54 RMS 27.1 run 152099 run 156606 run 157311 centrality distribution
(a) Distributions normalisées de la centralité.
allZcent_152099 Entries 249372 Mean 0.04043 RMS 15.46 (cm) vtx z -30 -20 -10 0 10 20 30 0 0.001 0.002 0.003 0.004 0.005 0.006 0.007 allZcent_152099 Entries 249372 Mean 0.04043 RMS 15.46 run 152099 run 156606 run 157311 distribution vtx z
(b) Distributions normalisées de la position lon- gitudinale zvtxdu vertex.
F. V.4: Distributions d’intérêt pour le run de référence 152099 duquel est issu le bruit de fond utilisé pour évaluer les corrections d’acceptance × efficacité sur l’en- semble de la période de prise de données. Le run 152099, situé vers le milieu de la période MUIDLL1 4/5, est ici comparé à deux autres runs qui appartiennent à la période MUIDLL1 3/5. Ceci permet de se faire une idée des variations de ces dis- tributions d’un bout à l’autre de la prise de données. Un coup d’oeil aux graphiques tracés lors de la surveillance en ligne des prises de données PHENIX indique que les distributions aussi décentrées en zvtxque le run 156606 sont localisées sur une courte période de temps (quelques jours), peu après le changement de condition de déclenchement du MUIDLL1 et le changement de polarité des aimants contrôlant le champ magnétique de PHENIX. Le cas général est plutôt celui illustré ici par les runs 152099 et 157311.
Notons que quelques runs de configuration ont été exclus de l’étude : ceux dont les fichiers de configuration des hautes tensions pour le MuTr manquent à l’appel 8Il est une référence pour la configuration du détecteur et pour le « bruit de fond »utilisé lors de l’embedding.
(5 runs sur 261), et ceux pour lesquels un nombre anormalement élevé (∼ 97%) d’événements sont rejetés lors de la phase9 d’extraction du signal car identifiés à tort comme n’appartenant pas à un croisement physique des paquets d’ions (16 runs sur 261). L’exclusion de ces runs a une influence négligeable sur la valeur de AεJ/ψ moyennée sur l’ensemble de la période de la prise de données puisque les 240 runs utilisés représentent 91.4% du nombre total d’événements minimum bias enregistrés.