DELPHI 96-150 MVX 19 October 24, 1996
DELPHI Collaboration
Online Monitoring of the DELPHI VFT Pixel Detector
J.M. Heuser
1,*,
2
M. Caccia , L. Roos
3
Abstract
During the winter shutdown 1995/96 the DELPHI Silicon Tracker has been upgraded in the forward region. The Very Forward Tracker which is composed of mini strip and pixel detectors covers the polar angle from = 10 to 25. This note describes the online data monitoring of the Silicon Tracker with emphasis on the pixel detector part.
1 2 3
corresponding author, E-mail:
[email protected] Universitat Wuppertal, Fachbereich Physik, Postfach 100127, D-42097 Wuppertal, Germany Universita degli Studi and INFN, Dipartimento di Fisica, Via Celoria 16, I-20133 Milano, Italy Institut des Sciences Nucleaires, IN2P3-CNRS, Univ. de Grenoble 1, F-38020 Grenoble Cedex, France
1
Introduction
Online data quality checking is an important task for a detector group where the operation of its detector is monitored at raw data level. Possible malfunctions can be discovered at the very beginning of the data chain, and fast actions can be taken in case of problems. Especially for a new detector like the VFT pixel detector in DELPHI [1, 2], basic experience on how to operate the detector with the slow control system etc. has been gained using the online monitor. Within the DELPHI online cluster environment a standardized real-time data monitoring system has been developed[3]. For each detector, a monitor program runs in the detector workstation that spies the data from the detector acquisition system and processes it online. Standard libraries are provided to access the detector data and LEP information[4]. User routines contain the detector speci c code like data decoding, processing and booking and lling of histograms. The histograms are written to a global section of the workstation's memory and are archived to les. They can be displayed e.g. with the Histogram Presenter[5], a standard tool in the DELPHI online cluster, both online and reading from les. Reference histograms can overlay the ones from acquired data.
2
Detectors in the Silicon Tracker
The DELPHI Silicon Tracker consists of the three layers barrel micro strip detector with double sided readout and the Very Forward Tracker. On both end caps the VFT is built from two layers of mini strip and pixel detectors. The installation of the pixel detector is not completed yet, the second layer is only in quarter AD (see gure 1). The modules of the barrel micro strip detector de ne several sectors (closer and outer layer: 24, inner layer: 20 sectors) and provide 150.000 readout channels in total [6]. The VFT mini strip detector is constructed in four crowns of 12 modules each. The number of readout channels is 24.500 [7]. The VFT pixel detector in its nal con guration is made of four cones of modules with 1.200.000 detector elements in total; modules with 765.000 pixels are currently installed. One cone consists of two crowns of 18 or 20 detector modules (\raquettes") with 8000 pixels each. From the slow control and readout point of view the crowns are devided into half crowns (repeaters). Detailed descriptions of the pixel detector construction, readout and slow control have been given in [8] and [9]. With the strip detectors, all channels are read out per event. The analog signals are digitized and a zero suppression and cluster analysis of neighbouring channels is performed online in the fastbus SIROCCOs. The signal heights and addresses of a certain number of strips around recognized hits are stored as well as pedestals and noise numbers for the channels. The pixel detector provides binary information on whether a pixel has been hit. Due to the sparse data scan in the front end chips only the addresses of hit pixels are read by the crate processor and converted from a hardware to an oine numbering scheme. Hot pixels, i.e. pixels which are ring with (almost) every event, are suppressed online in the crate processor. Maps with hot pixels addresses have been acquired before using special crate processor software during \no beam"-periods. 1
3
Silicon Tracker Data Structure
The data stream from the strip and pixel detectors is read by crate processors and formatted into data blocklets. Strip and pixel blocklets have their own speci c format[8, 10]. Strip data forms one blocklet, whereas for the pixels there are two blocklets: one for data words and one for error codes in case of data acquisition error detections. Since there is one partition for the Silicon Tracker, the Local Event Supervisor (LES) combines these blocklets in one ZEBRA structure which can be accessed by other tasks like the online monitor. The ZEBRA structure that has been chosen follows link -5 of the Partition Master Bank (PMB). The strip data blocklet hangs on this link and the pixel blocklets are chained to the rst bank (see gure 2). This prevents from possible data loss since the reading of a blocklet may be skipped. When jumping to the next blocklet, its type is identi ed by header words.
4
The Pixel Online Monitor
The monitor program for the Vertex Detector which has been set up during the past years of operation has been extended for the new Silicon Tracker components. Advantages of one monitor program for the Silicon Tracker are easier maintenance and better use of the detector workstation's resources. According to the Silicon Tracker data structure, the monitor program's main loop scans the data blocklets and detects whether they belong to barrel micro strips, VFT mini strips or pixels. The relevant subroutines are called. The data decoding and cluster nding algorithms are the same as in use for the oine software. Single subdetectors may be disabled from monitoring by proper de nition of symbolic names at monitor start-up time. The pixel detector histograms di er in many respects from the ones for micro strip detectors. While analog quantities like signal heights, pedestals and noise are available for micro strip detectors and information on the functionality of the single components can be gained from the shape of their distributions, the binary pixel data needs a di erent approach. Furthermore, it is not possible in the framework of the online monitor to book and store pixel histograms with entries for each of the large number of detector elements, as it has been done for the strip channels. The detectors are monitored down to the level of the readout chips instead. Single pixels are identi ed when searching for new hot pixels at the beginning of each run. With the presenter, the pixel histograms are grouped according to the topics: pixels and event size, correlation of hits in neighbouring crowns, clusters and clusters size, warnings and errors from readout boards. The following subsections give a few examples.
4.1 Pixels and Event Size Histograms
The main aim of the pixel monitor is to detect dead or noisy modules and readout chips. The thresholds of the pixel front end electronics should be set as low as possible by the slow control system to insure high eciency in particle detection, but at the same time 2
high enough to cut o responses due to noise. Noise appears as an increased number of pixels ring per event. Either one or several raquettes with 16 readout chips get noisy, or only a part of a module, i.e. a chip, shows lots of hits. Several histograms have been set up which display the event size for the entire pixel detector and the modules according to their geometrical position. As indicated in gure 1, the data is arranged for crowns 0 to 7, following the oine numbering convention. Each crown related histogram is for the modules of two half crowns or repeaters, respectively. 4.1.1
Event Size of the Entire Detector
Despite of the large number of detector elements, the pixel event size is much smaller than the one for the strip detectors. This results from the sparse data scan readout and the noisy pixels suppression. Figure 3 shows the histogram presenter page with a trace plot of the entire pixel detector's event size. During ll 3596 of day 231 (Aug. 18, 1996), an average number of 75 pixels per event has been recorded for 4117 events from two to six o'clock. This is about 1:4 10?4 of the pixels in the working modules (540000). The bin width of this pro le histogram is 1 minute, so that usually several events contribute to one entry. To spot large events in time, a similar trace plots lists events with more than 200 pixels responding. A rst impression on the quality of the threshold settings has been gained regarding the correlation of pixel hits in one of the crowns versus the others. Correlations are expected within physics runs especially for neighbouring crowns. Figure 4 shows a clear correlation of hits in crown 1 versus crown 3 after threshold and detector bias optimization. With thresholds adjusted too low almost no correlations have been observed due to lots of noisy pixels responding. 4.1.2
Event Size of Single Modules
The distribution and mean number of hit pixels per event and raquette provides additional information on the state of the modules. Figure 5 lists event sizes for the modules of crowns 2 and 5. Crown 2 is the detector's most noisy one. Obviously several events had occured with a complete chip ring in two modules. This results in single event sizes of 576 pixels. Preceding this chip blinking, the modules normally start to develop an increasing noise level. An automatic procedure, called \Anti Blinking Command", is about to be used to prevent chips from getting very noisy. The acquisition software detects such enlarged data from the modules and calls the slow control system to increase the thresholds there in limited steps. From the corresponding histograms below it may be seen that the mean event size for noisy modules is greater than one pixel. Quiet modules like the ones in crown 5 normally respond much less than with every event. Problematic or dead front end chips on the pixel modules are visualized by recording the average hit occupancy per chip and event. The histogram presenter page in gure 6 shows that in half crowns 9 and 13 two half modules and in half crown 4 two full modules are disabled from readout. The half crowns 8, 10, 11, 12, 14, and 15 are not installed yet, and the four half crowns 0, 2, 3 and 7 had to be switched o or set to high thresholds due to problems with the detector polarization or logic signals. 3
4.1.3
Noisy Pixels Search
Regarding the average number of hit pixels per chip and event ( gure 7, numbers in 0.1%) one can state that single chips stick out. They contain pixels which respond with (almost) every event. These noisy pixels have shown up after the map for the noisy pixels suppression had been learned by the crate processor software. In order to investigate the development of such fake hits the online monitor has been equipped with routines to observe the rst thousand pixel events of each run. The addresses and \temperatures" of pixels responding with more than 10% of the events are listed to ll-based logbook les. Both the data acquisition and the oine analysis can pro t from these tables. Figure 8 compares event sizes of all working detector modules to the situation after suppression of additionally found hot pixels. Approximately 25% of all events contained hits from hot pixels, and suppression would reduce the event size considerably. It has to be noted that not ltered triggers contributed to these online histograms.
4.2 Clusters and Clusters Size Histograms
A cluster analysis of the hit pixels gives important hints on the data quality. Particles passing the detectors are expected to hit pixels only in a limited region, depending on the geometrical orientation of the detectors. This should result in small clusters, i.e. a small number of pixels joined to each others. Due to the detector thickness of 300 m, the pixel size of 330 m 330 m and the orientation of 12 (internal layer) and 32 (external layer) with respect to the beam axis, clusters are expected to be one or two pixels wide and up to 6 pixels long (3 pixels for the external layer). Several clusters may overlay each others. The number of clusters depends on the physics conditions and beam quality. Noisy pixels and blinking chips can disturb this picture. In gure 9 the distribution of the number of clusters per event is shown for crowns 3 and 7 (detector side A) and crown 2 (detector side C). Figure 10 lists the two dimensional distribution of cluster sizes. With the crowns on side A, there are only a few clusters per event and the clusters sizes match the expectation. The modules in crown 2 on side C are noisy. Both the number of clusters per event and the clusters dimensions are by far larger than the ones of side A detectors. Warnings and error messages from the attatched readout boards con rm a problem in crown 2. Additional histograms exist which monitor special cases of big clusters such as blinking chip columns or complete chips.
4.3 Data Acquisition Error Histograms
The data acquisition software checks the pixel data stream coming from the repeaters and the fastbus readout modules. Inconsistencies are written both to logbook les and the pixel error blocklet so that they are easily accessible to the outside world e.g. via the histogram presenter. Data of half crowns being a ected by readout errors has to be taken with care. Figure 11 lists several readout board errors like bad accounting numbers and the number of data words not matching the information in the header word of a blocklet. Mainly the boards of crown 2 (half crowns number 4 and 6) often report wrong accounting numbers 4
and incorrect event lengths. It is being studied if such readout failures contribute to the increased number of pixels and large clusters sizes there. Data acquisition problems with repeater 4 have been traced back to two modules which have been disabled from readout.
5
Conclusions
The online monitor is an essential tool for operating the DELPHI pixel detector. From the beginning of the start-up, the monitor task has enabled the detector group to check the functionality of the data acquisition chain in real time. The tensions and currents settings for the detectors and front end electronics have been tuned with respect to the response seen in the monitor histograms. The long term stability of the detector's settings can be tracked from the archived histogram les. Electrical and readout problems in parts of the pixel detectors have been discovered both with the online monitor and the slow control system and interaction has been possible. The pixel monitor is part of the Silicon Tracker online monitor which reads the combined data structure of strip and pixel detectors. This concept simpli es the maintenance of the code, and physicists being on call for the Silicon Tracker can use an integrated system. It is designed for the fully equipped detector and is operational for the next year's pixel detector upgrade.
References [1] M. Caccia, K.H. Becks et al., Progress in the construction of the DELPHI pixel detector, Delphi note 96-56 MVX 14, May 2nd, 1996 [2] P. Delpierre et al., The DELPHI pixels, contribution to VERTEX 96 conference, to be published in NIM [3] V.Chorowicz, The real-time monitoring in DELPHI, Delphi note 95-30 DAS 163, March 6, 1995 [4] V.Chorowicz, The DELPHI skeleton for detector online monitoring, Delphi note 9533 DAS 166, March 21, 1995 [5] L.Beneteau, T.Camporesi, The DELPHI histogram presenter, DELPHI note 92-100 DAS 129, July 8, 1992 [6] A. Zalewska, Conventions for the barrel part of the DELPHI Silicon Tracker 1996, Delphi note 96-146 MVX 18, October 1996 [7] W. Adam et al., The Status of the DELPHI Very Forward Ministrip Detector, DELPHI note 96-58 MVX 15, April 30, 1996 [8] C. Aubret et al., DELPHI Pixel Detector Readout, College de France, Paris, September 13, 1996 [9] S. Kersten, Slow Control for the DELPHI Pixel Detector, Wuppertal, October 1996 [10] P. Jalocha, CERN, private communication 5
side D 13
8
9 5
0
1
12
4
e+
eside A
side C 7 15
3
2
6 10
11
7 5
14
4 6
3 1 0 2 crown number
Figure 1: Pixel detector crown and half crown (repeater) numbering
partition master bank link -5 blocklet length
blocklet length
detector ID: 300 strip ID: 688E
detector ID: 300 pixel ID: 6919
strip data words:
pixel data words
destinguish VD and VFT mini strip blocklet layer 0: mini 1: closer 2: inner 3: outer
blocklet length detector ID: 300 pixel ID: 6919 DAS error words
Figure 2: Silicon Tracker data structure 6
Figure 3: Trace plot of the pixel detector's event size 7
Figure 4: Correlation of hit pixels/event, crown 1 vs. crown 3
Figure 5: Event sizes for the modules of crowns 2 and 5 8
Figure 6: Average number of hit pixels per event, chip by chip
Figure 7: Average number of pixels per chip and event [0.1%], half crown 13 9
Figure 8: Event size before and after hot pixels suppression
Figure 9: Number of pixel clusters, crowns 3, 7 and 2 10
Figure 10: Cluster size, spatial extent in lines vs. columns
Figure 11: Pixel data acquisition errors 11
