Filtrage via le système de déclenchement de niveau 1 asso-

MuID

Le MUIDLL1 étant un système de déclenchement en ligne, il doit être conforme aux spécifications de PHENIX. Il doit notamment être capable de traiter chaque croi- sement de paquets d’ions du faisceau et de livrer sa décision en moins de 40 coups d’horloge de PHENIX, soit environ 4 µs. Enfin, il doit sélectionner les événements « muon » intéressants.

Plusieurs éléments indiquent qu’il est possible, techniquement, d’associer un sys- tème de déclenchement au MuID :

– Le temps de réponse d’un tube Iarocci, caractérisé par le temps de dérive (60 ns), est largement inférieur à la période qui sépare le croisement des pa- quets d’ions du faisceau (106 ns).

– La faible granularité du MuID implique un nombre relativement peu élevé de canaux à traiter par l’électronique de lecture.

– La structure du MuID (alternance de plans d’absorption et de plans de dé- tection) conduit à sélectionner en grande majorité des muons, et ce avec une impulsion minimale qui dépend de la profondeur d’absorbeur traversée avant la détection. Parmi les traces laissées dans le MuID, la proportion de pions par rapport aux muons est de 3.10−4. Pour un muon produit au vertex, l’impulsion minimale requise pour atteindre le premier plan de détection (gap 0) du MuID

est de ∼ 1, 5 GeV/c ; elle est de ∼ 2, 3 GeV/c pour atteindre le dernier plan (gap 4).

Description du MUIDLL1 : les critères requis

La partie « décision » du MUIDLL1 se fonde sur le nombre et la profondeur des routes laissées par les présumés muons dans le MuID. Chaque bras et chaque orientation au sein d’un bras sont traités de manière indépendante. Durant le Run 5 Cu + Cu à √sNN = 200 GeV, un événement a déclenché le MUIDLL1 dans un bras donné lorsque deux routes dites Deep sont trouvées dans le MuID. Pour qu’une route soit déclarée Deep, ses coups constitutifs dans le MuID doivent simultanément remplir les conditions suivantes :

– le gap 0 ou le gap 1 a été touché ; – le gap 3 ou le gap 4 a été touché ;

– un nombre N minimal de gaps ont été touchés.

Autrement dit, l’absence de coup dans un gap est autorisée (ce qui est interdit, c’est l’absence de coup dans deux gaps consécutifs). Ceci permet de ne pas être handicapé par l’efficacité inférieure à l’unité d’un panneau du MuID (canoniquement ∼ 97%).

En essayant de parcourir tous les cas autorisés par les conditions ci-dessus, il apparaît que pour N = 3 et N = 4, une route Deep atteint au minimum le quatrième et avant-dernier gap du MuID.

Les événements du Run 5 Cu+ Cu à √sNN = 200 GeV ont été sélectionnés sur la base d’une coïncidence entre le BBCLL1 et le MUIDLL1. La première moitié de la luminosité a été recueillie avec une condition de N = 4 gaps touchés au mini- mum sur 5 ; la deuxième moitié avec N = 3. Ceci définit deux périodes de prises de données, désormais nommées MUIDLL1 4/5 et MUIDLL1 3/5. C’est notamment notre évaluation du taux de rejet et de l’efficacité de détection du J/ψ → µ+_µ− pour ces deux conditions qui a justifié l’abandon du MUIDLL1 4/5 au profit du MUIDLL1 3/5, la perte en efficacité étant trop importante alors que le gain en pou- voir de rejet restait modeste (cf. sectionIV.1.3sur le taux de rejet et l’efficacité, ainsi

que la sectionV.3.2du chapitre traitant des acceptances et efficacités). Algorithme du MUIDLL1 : recherche et validation de route

Voyons à présent à quoi ressemble l’implémentation (hardware2en l’occurence) du MUIDLL1. Il est utile de la connaître car les simulations qui permettront d’évaluer son taux de rejet et son efficacité doivent coller au plus près de la réalité, autrement dit l’algorithme implémenté de manière software se doit d’être une stricte émulation du modèle hardware.

Pour chaque bras, les modules électroniques où est implémenté l’algorithme du MUIDLL1 reçoivent directement les signaux des cartes ROC d’acquisition du MUID qui, à chaque événement, récupèrent et numérisent la réponse des bi-packs de tubes

Iarocci. Un bi-pack est équivalent à un bit d’information. L’origine de chaque bit de donnée reçu par le MUIDLL1 est donc parfaitement connue (ROC, câble reliant ROC et bi-pack, identité et localisation du bi-pack) et est implicite dans la manière dont le câblage ROC-MUIDLL1 a été réalisé. Pour l’essentiel, en fonction de la place du bit dans le paquet de données reçu, l’algorithme du MUIDLL1 se résume à plusieurs séries d’opérations booléennes bit à bit qui sont effectuées en parallèle. Chaque série dépend d’un nombre très limité de bi-packs : 13 bi-packs dans l’implémentation ac- tuelle du MUIDLL1, soit un bi-pack dans le gap 0, et trois bi-packs dans chacun des quatre autres gaps. Cet ensemble forme un symset. L’algorithme de validation d’une route Deep tel qu’il est décrit précédemment est en fait exécuté au niveau de chaque symsetselon chaque orientation (cf. Fig.IV.1) et ne forme que la deuxième partie de l’algorithme du MUIDLL1. Le fait que cette validation soit exécutée pour tous les symsetsimplique que les perfomances en terme de vitesse d’exécution du MUIDLL1 sont insensibles au nombre de routes par événement, c.-à-d. à la multiplicité par évé- nement.

F. IV.1: Algorithme du MUIDLL1 au niveau d’un symset. Un symset est consti- tué de 13 bi-packs logiques appartenant aux différents gaps du MuID. Pour le gap0, seul le bi-pack central fait partie du symset. Pour tous les autres gaps, le bi-pack central et les bi-packs plus proches voisins (dans l’espace des indices) font partie du symset. N est le nombre minimal requis de gaps touchés : N= 4 ou N = 3 au cours du Run 5.

Toute l’astuce du MUIDLL1 réside dans le choix des bi-packs qui font partie d’un symset: c’est en cela que consiste la première partie de l’algorithme du MUIDLL1.

– En raison de l’absence de champ magnétique dans le MuID, la trajectoire la plus probable d’une particule qui entre dans le MuID est une ligne droite3 3_{Nous oublions ici les diffusions multiples qui peuvent se produire à la rencontre des plans d’ab-}

qui pointe vers le vertex. Il convient donc de rechercher des coups dans une fenêtre angulaire étroite autour de cette direction. L’ouverture angulaire est définie de manière locale : vu la faible granularité du MuID, à un gap donné, cette fenêtre angulaire est équivalente à un bi-pack de part et d’autre du bi-pack a prioritouché le long de cette ligne droite. Ce dernier est dénommé « bi-pack central », les deux autres sont ses bi-packs « satellites ».

– L’algorithme du MUIDLL1 ne se soucie que des bi-packs « logiques ». Pour un gap donné, un bi-pack logique d’ordonnée y, orienté horizontalement, est obtenu en effectuant un OU logique entre tous les bi-packs orientés horizonta- lement et physiquement situés à la même ordonnée y pour ce gap. De même définit-on un bi-pack logique d’abscisse x orienté verticalement. En fait, un muon pénétrant selon un angle donné dans le MuID allume un bi-pack lo- gique dans chaque orientation. Utiliser des bi-packs logiques permet donc une grande économie (un facteur ∼ 3) en termes de câblage entre les ROC et le MUIDLL1. Par la suite, les bi-packs dont il sera question sont uniquement des bi-packs logiques.

– Considérons les bi-packs orientés horizontalement (le raisonnement est le même pour l’orientation verticale). Pour chaque gap, les bi-packs sont « empilés » les uns au-dessus autres et ont donc une ordonnée y croissante. Un bi-pack par gap est touché par la trajectoire la plus probable, c.-à-d. la ligne droite de pente dy/dz. L’ensemble des bi-packs touchés ont ainsi un point commun : ils sont situés au même dy/dz. Par conséquent, seuls les bi-packs de même dy/dz sont concernés par la recherche d’une route idéale (une ligne droite) de pente dy/dz par le MUIDLL1. Ceci est illustré par la Fig.IV.2. Ces bi-packs sont donc étiquetés4 avec le même indice i. Dans le cas d’une route plus réaliste, la recherche de coups s’effectue dans une petite fenêtre angulaire. Il faut donc inclure à la fois les bi-packs centraux et les bi-packs satellites. L’ensemble constitue un symset, ainsi nommé car les bi-packs qui en font partie ont des indices symétriques : chaque bi-pack de part et d’autre du bi-pack central d’in- dice i porte l’indice i ± 1. Un symset peut donc être considéré comme un candi- dat éligible au statut de route pour le système de déclenchement. La recherche de route est ainsi effectuée de manière indépendante pour chaque orientation. En résumé, pour chaque bras et chaque orientation, une fois que tous les bi- packs ont été étiqueté avec un indice en fonction de leur position, l’algorithme du MUIDLL1 consiste à (i) générer un symset pour chaque bi-pack du gap 0, (ii) voir sorption du MuID. En effet, ces diffusions multiples peuvent être considérées comme négligeables sauf sur le dernier gap atteint par la particule. Comme le MUIDLL1 est conçu pour se déclencher sur des routes Deep, donc sur des muons de grande impulsion, on peut considérer qu’il n’y a quasiment pas de diffusion multiple tout au long de la traversée du MuID. Il n’est donc pas nécessaire de chercher des coups dans une grande fenêtre angulaire autour de la trajectoire la plus probable, c.-à-d. la ligne droite. 4_{En pratique, l’algorithme du MUIDLL1 attribue les indices de sorte que chacun étiquette un} unique bi-pack logique dans le gap 0. Chaque indice correspond donc à la valeur de dy/dz au centre de chaque bi-pack appartenant au gap 0, autrement dit dy/dz est en quelque sorte quantifié. Aussi, pour les autres gaps, un indice peut correspondre à de multiples bi-packs logiques car le même nombre de bi-packs logiques, couvrant une même extension spatiale dy, se retrouvent à un dz de plus en plus grand.

F. IV.2: Exemple montrant les bi-packs logiques touchés le long de la trajectoire la plus probable d’un muon issu du vertex et le symset correspondant (en rouge).

si chaque symset constitue une route valide, (iii) vérifier qu’une route n’a pas été comptée deux fois en éliminant les symsets contigus, (iv) compter le nombre de routes Deep. La décision d’accepter l’événement peut ensuite être prise. C’est le cas si deux routes Deep sont effectivement trouvées dans un bras pour chaque orientation.

Dans la version software, l’émulateur du MUIDLL1 reproduit à l’identique les étapes (i) à (iv). Cependant, il ne dispose en entrée que des données telles qu’elles sont empaquetées par le système d’acquisition de PHENIX (sous forme de PRDFF) ou sous le format réduit de DST5où figurent les coups dans le détecteur. Pour qu’elles soient utilisables par le MUIDLL1, il faut donc lui fournir au préalable une sorte de pierre de Rosette, la « cartographie du MUIDLL1 ». Celle-ci n’est autre qu’une liste exhaustive des bi-packs physiques du MuID avec les informations suivantes : bras, orientation, gap, panneau, identité de la ROC, numéro du mot dans le paquet de données, numéro du bit dans le mot, numéro du bi-pack sur le panneau, indice étiquetant le bi-pack.

Problème matériel rencontré dans le bras Nord

Durant le Run 5 Cu+ Cu à √sNN = 200 GeV, nous avons eu un dysfonctionne- ment relatif du MUIDLL1, au niveau de la recherche des primitives pour les routes dans le bras Nord du MuID et ce pour l’orientation verticale uniquement. La perte d’efficacité fut estimée en comparant les réponses (connues) du MUIDLL1 et celles de l’émulateur du MUIDLL1 sur des événements du même lot de données réelles. Elle correspond à un facteur de correction de (81.5 ± 3)%.

Nous avons finalement identifié la source de ce dysfonctionnement comme étant une paire de câbles permutés au niveau de deux cartes électroniques d’acquisition (ROC) du MuID, en charge de la lecture de bi-packs suivant l’orientation verticale et placés sur le dernier gap du bras Nord. Nous avons répercuté cette permutation en utilisant une nouvelle cartographie du MUIDLL1 et vérifié que l’émulateur du MUIDLL1 reproduisait effectivement le comportement en ligne du MUIDLL1. Les taux de rejet et efficacités du MUIDLL1 reportés dans la sectionIV.1.3sont estimés en utilisant cette nouvelle cartographie du MUIDLL1 lors des simulations.