TEC+ bad modules at high rate AND steps in TEC digi multiplicity vs time
Track reconstruction with collision configuration in APV-induced noisy events
TEC+ bad modules at high rate AND steps in TEC digi multiplicity vs time
Track reconstruction with collision configuration in APV-induced noisy events
In this section the status and evolution of the masked modules and channels is described. This section will never be completed...
The start point is the list of modules and connections described in the section about the final TKCC GainScan runs.
A first list of masked modules at the time of CRUZET3/4 was made public by Christophe in this hypernews. In this list there are both the modules which were missing at the time of the creation of the partitions and those which were masked before the start of the physics runs. Those modules were masked by removing them totally from the partition (VERSION TO BE FOUND). A commented list of these modules can be found here. For three modules the causes of the masking are unknown while for the other new modules the most probable cause is indicated.
A second list of masked modules at the time of CRUZET3/4 was posted by Christophe here. In this case the list was suggested by the DQM analysis. The commented list can be found here. For this list the situation is much less clear:
7 modules are masked for unknown reasons
5 modules show a mild correlation which could indicate a (HV?) PG problem. TO BE INVESTIGATED
2 modules are in known bad LV PGs
one modules showed an anomaly in one fibre gainscan profile. TO BE FOLLOWED
The list of modules in the last versions of the TI_08-AUG-2008_1, TO_08-AUG-2008_1, TP_08-AUG-2008_1, TM_08-AUG-2008_1 partitions is compared with that of the gainscan runs and of the masked modules above. The commented list of additionally masked modules is here.
The SiStrip Tracker digi ("siStripDigis","ZeroSuppressed") multiplicity has been investigated as a function of time in many runs collected during the Global Runs. By default only digis with POSITIVE charge are considered. For a few runs also the multiplicity of ALL the digis (including those with charge=0) has been plotted. The event timestamp comes from edm::Event::time() but for the most recent runs also the orbit number is available and plots have been done using it, as well (1min ~ 673k orbits).
CRUZET4
MWGR W37
MWGR W38
MWGR W40-41
In the first ~6-8 minutes of almost every run the number of digis decreases and reaches a stable value. This can be compatible with a cold detector with high pedestals (due to high AOH gain) which drift toward stable values when the AOH become warmer and warmer. In TOB the number of digis in this interval is by far the largest and it increases in the first 1-2 minutes.
Such an increase in TOB is not present if digis from modules with a large number of digis are discarded. As an example these are the plots of the number of digis vs time in modules with less than 35 digis in some of the runs: 58289, 58351.
In TOB a sizeable fraction (10-20%?) of the digis have charge = 0. This is foreseen by the ZS algorithm for strips between two strips above the threshold but, while in TIB set of adjacent digis never have zero total charge (digi and "cluster" charge in TIB in run 62938), in TOB this is the case (digi and "cluster" charge in TOB in run 62938). This can be due to the fact that a older firmware has been used in TOB until now. The plan is to upgrade TOB to the same firmware of TIB and TEC asap.
In the only high rate run which has been analyzed, 64903, the number of digis in the stable region is not as stable as in the other runs, likely due to the higher noise due to the high rate. Only TOB data are available in that run so the interplay between the old firmware and the high rate cannot be solved with these data only. LOOKING FOR ANOTHER HIGH RATE RUN WITH TIB AND TEC
Since October 13 TOB FED firmware has been updated to the same version used in TIB and TEC FEDs. The first data analyzed with this change applied are from CRAFT1 runs 66662 and 66668. A comparison of the digi charge distributions and of the charge distributions of sets of adjacent digis shows that now TOB distribution are more similar to TIB ones in the low charge region, that the amount of zero charge digi in TOB is decreased and that the charge of the sets of adjacent strips is never below 2 ADC counts both in TOB and TIB. Plots are shown below:
| old TOB firmware run: 62938 | updated TOB firmware run 66662 | |
| TIB | digi charge / "cluster" charge | digi charge / "cluster" charge |
| TOB | digi charge / "cluster" charge | digi charge / "cluster" charge |
Concerning the time evolution of the digi multiplicity both those runs do not show any structure in TOB any more:
The digi multiplicity in TIB and TEC is, on the other hand, higher than it used to be in the previously analyzed run. Not yet investigated if this is due to a noise increase or to individual bad modules as reported at the TCO TK meeting on Monday October 13.
Even with the latest version of the firmware in all the partitions, TIB, TOB and TEC digi and adjacent-digi cluster charge distributions show a sizeble fraction of entries in the low charge region where "low" means below (2+2)*noise which should be the lowest threshold for a set of adjacent digis and which, typically is equal to ~4*3=12 for TIB and ~4*4.5=18 for TOB.
Looking at a few of these clusters I found that they were in modules which
were flagged as "to be masked" by Laurent's pedestal run analysis. So I took the
list of masked modules from run
66585 (TEC+: 15 modules),
66584 (TEC-: 55),
66581 (TIB: 46) and
66596 (TOB: 60) and I have produced the digi and cluster charge and
multiplicity distributions with and without rejecting these 176 modules.
REMARK: the TOB list is not complete since it is
the list from the second pedestal run, after the lasers have been switched off.
So some TOB modules which are "masked" are not in this list (yet)
The results are the following for the charge distributions in run 66668:
| TIB | digi charge | cluster charge |
| TOB | digi charge | cluster charge |
| TEC | digi charge | cluster charge |
while the digi and "cluster" multiplicity vs time (orbit) with and without those modules are shown below:
| Digi multiplicity | all modules | masked modules |
| "Cluster" multiplicity | all modules | masked modules |
Therefore ~50% of the digis and ~40% of the "clusters" are from these 168 modules which are not perfectly masked: the masking procedure produce low charge digis but also low noise values in the DB and therefore low thresholds.
Digi Multiplicity: CRAFTDigis and Simple "Clusters" distributions have been investigated in a few runs of CRAFT. Distributions are filled either with all the modules or only with the modules which are expected not to be masked by the pedestal run analysis. The analyzed runs are shown in the menu below.
The mean digi
multiplicity for some of the analyzed runs is shown in the plot below:
This explains
the higher mean multplicity observed after run 69509.The
probability for those modules to loose the phase increase with the number of
triggers. Therefore in high rate runs this effect is more evident, also in
the mean digi multiplicity plot in the run range between 69522 and 69892.Also the
distributions of the number of digis shows peaks and bumps (and overflow)
due to the noisy events described below. The events which exceed 20k digis in run 66668 have been selected. Event displays for event 66668/12809 (27294 digis) and 66668/30367 (558478 digis) are available. It is clear the correlation between TIB/TEC/TID and the TOB alone. These two events correspond, respectively, to the small excess in TK and TOB digi multiplicity at about orbit# 650k and to the large excess in TK, TEC, TIB and TID at about orbit# 1120k in this plot.
Oscillations in the number of digis and "clusters" are clearly visible in run 66714 and 67128 with a strong correlation between TIBTID and TEC. TOB is unaffected:
During the CRAFT data-taking period, it was realized that the Common Mode subtraction was not ok in case of negative drift of the pedestals. This has been fixed since run 69509. Therefore it is possible that these oscillations are due to bad common mode subtraction. The two analyzed runs, 69522 and 69912, with proper CM subtraction do not show any oscillation.
The digi multiplicity has been investigated as a function of the time separation between an event and the previous one (see here for other similar studies). In a large statistics run, 67647, the distribution for the full TK and for each subdetector are shown below both for the mean multiplicity in each DBX bin and for the multiplicity vs DBX 2D distribution:
Events with an excess of digis are observed in the 150-220 DBX region and, much less pronounced, in the 380-450 DBX region.
A zoom in the 150-200DBX region is shown in the plots below:
In the 150-220DBX region most of the events have the usual digi multiplicity but a few percent of them have a much larger number of digis (between 50k to ~1M). These are the huge events reported above. Instead, in the DBX=148 bin (= Latency+1) all the events have a larger digi multiplicity by a factor 5-10. The properties of the events at DBX=148 are more evident in the plots below where the distribution of the digi multiplicity in all events is compared to that of the events in the bin DBX=148 and DBX=144 (which had been equal to Latency+1 since run 69245):
It is worth noting that TOB looks different from the other subdetector likely because a problem in the common mode subtraction which do not allow negative common mode values until run 69509. I have the impression that given the usual number of digis in TOB, a few tens, TOB is the most affected subdetector by these effectively too high thresholds.
In the 380-480 DBX range the distributions of the events in the multiplicity vs DBX 2D plots are shown below:
Events with anomalosly high digi multiplicity appear only in the second bin row. Higher anomalous multiplicity events in these region are present in the runs when the common mode subtraction has been fixed like 69522 and 69912.
Following the discussion about the possible source of these huge events, it turned out that a trigger (#2) can be noisy if preceded by another trigger (#1) AND the trigger #2 occurs in a (or a few) particular time slice(s) of the APV 70-BX cycle. Therefore the distributions of the digi multiplicity vs the absolute BX number, modulo 70, of trigger #2 are shown below:
These distributions show that:
The same distributions zoomed in the low multiplicity region (0-0.13%) show other changes of the digi multiplicity correlated with the APV cycle. One of them is due to the tickmark generation which occurs every 70 BX when the APV is idle. Therefore it affects also isolated events has shown in the plot below where only events with DBX>5000 are considered:
The position of the anomaly is shifted by one BX among TOB and TIB+TEC and it depends on the run. The same distributions in a run with the proper common mode subtraction, 69912, show that the digi multiplicity reduction observed in the previous runs is disappeared probably because it is due to a lowering of the APV baseline. CORRELATIONS WITH THE CLUSTER CHARGE TO BE STUDIED.
In some runs the position of the huge events or of the tickmark generation is not unique. This is because in those runs the Resync signal was issued more than once. This is clear in the distribution of the mean multiplcicity vs the BX mod(70) as a function of the time: the position of the anomalous multiplicity bins changes as a function of time. PLOT TO BE ADDED.
A different way to look at the huge event effect is to plot the average digi multiplicity as a function of the absolute BX number, modulo 70, of trigger #1 and of the BX separation between event 2 and 1. The results are shown below for the DBX(2-1) range 0-1000:
Zoom of the DBX 120-250 region, where the huge events are, is shown below:
High digi multiplicity events are aligned along a diagonal which means BX(#1) + DBX(#2-#1) = constant which is equivalent to BX(#2)= constant, as shown in the plots above. Instead, zooming in the DBX 130-160 range, the excess of digis in the DBX=148 bin is visible and spread among all the BX(#1) values, as shown in the plot below:
A more complete picture is obtained by plotting the digi multiplicity has a function of the second event separation from a fixed position of the cycle when then first event occurred. This is very similar to the plot done by Mark Raymond to explain the effect observed Kristian H. during the high rate test at TIF (ADD LINKS). For run 67647 the distribution is the following, where the red points do not include the events whose DBX=Latency+1 (only isolated pairs, with DBX>5000 w.r.t. the previous events, are used):
instead for a run with the proper common mode subtraction, 69912, the distributions are the following, where no reduction of the digi multiplicity is observed:
Zoomed plots to the critical intervals are shown below:
| Huge Events | |
| 67647 | 69912 |
 |
 |
| Frame Header | |
| 67647 | 69912 |
 |
 |
| Frame End | |
| 67647 | 69912 |
 |
 |
| Tickmark | |
| 67647 | 69912 |
 |
 |
Other analyzed run plots are in the menu below:
Similar plots have been produced using the number of reconstructed tracks (ctfWithMaterialTracksP5) instead of digis. Run 66637 and 66714 distributions are shown below:
There is an excess of tracks in the 400-450 BXs interval (correlated with the small excess of digis seen above?).
On-track Cluster ChargeAnother monitored quantity is the on-track cluster charge.
Due to the observed correlation between the digi multiplicity and the event time separation similar studies are being performed on the on-track cluster charge.
The time correlations which can affect the on-track cluster charge are:
The on-track cluster charge distributions and the track pt distributions are filled for:
Because of the different phase of the APV cycle in TOB and TIB/D+TEC, cluster related distributions are made using the proper phase for each subdetector clusters. Instead pt track distributions are filled using the TIB/D+TEC phase. Because of this only runs with a unique phase (no ReSync during the run) have been analyzed with the exception of run 69997 wihch has been analyzed with the APV-cycle phase of the start of the run.
Examples of these plots are shown below. Plots for all the analyzed runs are available in the pull down menu below.
Isolated pairs are selected , as well, in order to have events pairs with clean APV cycle (no queued events). An example of these plots is shown below and are available in the pull down menu below:
Another,
complementary, approach has been followed to remove the effect of the APV-induced
noise events in these on-track cluster charge distributions. It has been shown
that most of the fake tracks are created by the noisy digis in the so called
Latency+1 Events and, more frequently, the FrameHeader Events . The
former can be identified, tagged and removed only if the separation from the
previous event(s) is available and this introduce an inefficiency in the
selection. The same applies for the FrameHeader Events but in this case,
despite the fact that they are triggered by a preceding events, they occur
always in the same position w.r.t. the 70-BX APV cycle. Therefore this approach
remove all the events which occurs at well defined position within the APV
cycle, regardless of the presence of a preceding events. In this way there is no
inefficiency due to the knownledge of the distance from the previous events and
the only inefficiency is due the fraction of removed bins in the 70-BX wide APV
cycle.
Looking at plots like this one, it results that the influence of the frame header on the event digi multiplicity extend from DBX=295+latency to 323+latency with four very noisy bins from 298+latency to 301+latency (the maximum is at 298+latency) and other three noisy bins in a second peak between 317+latency and 319+latency. These intervals correspond in the APV cycle to the bin intervals (corrected for the phase and the latency) [16,44], [19,22] (maximum at 19) and [38,40]. In the following plots the on-track cluster charge vs the absolute BX mod(70) is shown with indicated the ranges of the three intervals: solid lines are the wide interval, dashed lines are the first peak and dotted lines are the second peak (the same plots for all the analyzed runs are available in the pull down menu below):
It can be noticed that in TEC and TID there is an "excess" of low charge on-track clusters (due to fake tracks) in the second peak and, especially for TEC, in the bins on the right of the first peak. Moreover there is no excess of low charge on-track clusters in the region of the first peak: this is somehow expected since the number of total clusters is so high for these events that the tracking is not performed (RESULTS FROM OFF TRACK CLUSTERS TO BE ADDED). Similar behaviour is observed in all the analyzed runs with some additional features in some runs which are described in the individual run result pages.
The distributions of the on-track cluster charge have been done, therefore, removing the events which follows in the four intervals described above. The plots below show that without these events the low charge peak is strongly suppressed: it has to be taken into account that this procedure does NOT remove the Latency+1 events which have been shown to contribute to this low peak, as well.
The mean cluster multiplicity has been computed for some runs for the whole Tracker and for the different subdetectors. The following is the trend for the analyzed runs:
Runs between 69522 and 69892 are "high rate" runs. This explains the higher cluster multiplicity which is due to:
Since run 69850 some of these TEC bad modules were included in SiStripQuality in the Global Tag CRAFT_V4 and, therefore, the TEC cluster multiplicity has been reduced. An anomalous multiplicity is observed in TID in run 70675 (TO BE FOLOWED)
The inclusive cluster multiplicity has been investigated and its correlations with the APV-induced noisy events have been checked. As expected from the results on the digi multiplicity, a similar pattern is observed for the cluster multiplicity.
The distribution of the mean cluster multiplicity as a function of the event separation w.r.t. the start of APV cycle when the previous event occurred shows the same pattern of the digi multiplicity:
The following plots show the cluster multiplicity vs DBX w.r.t. APV cycle in run 69912 (latency=143) in a wide range and in the region of the FrameHeader Events:
The number of clusters in the APV-induced noisy events with the largest multiplicity, Huge Events and the three largest bins of the FrameHeader Event range, are several order of magnitude larger than the typical cluster multiplicity in normal events. Therefore even if the fraction of these events is low (~R*(25nsec)*4, where R is the total trigger rate and the factor 4 is due the fact that four bins in DBX are considered), they can contribute significantly to any inclusive cluster study and monitoring. Since to select these events the information about the event separation is needed, this approach cannot be followed since only a fraction of these events can be selected and the contribution of those events which are not selected will be neglected. Therefore the approach based on the position of these high multiplicity events in the APV cycle has been followed. The Huge Events and the FrameHeader Events in the three highest multiplicity bins always occur in the same bins of the APV cycle. As shown below the distribution of the number of clusters reconstructed in a run in each bin of the APV cycle shows an excess corresponding to the Huge Event bin (solid lines) and to the three largest FrameHeader Event bins (dashed lines).
The following is an example of a "normal" rate run, 70036:
The following is an example of a high rate run, 69522:
The plots of all the other analyzed runs can be found in the menu below:
Assuming a uniform distribution of events in the APV cycle, the fraction of expected clusters in each bin is 1/70~ 1.4%, so any excess of the fraction of clusters in those bins w.r.t. to the expected fraction can be explained to the noisy events. It is worth noting that even if the fraction of events in each bin is constant, the fraction of noisy events in the bins where they are expected increases with the total trigger rate. Therefore the excess of clusters in these bins depends on the total trigger rate. In the plot below the fraction of clusters in these bins for some analyzed runs are reported.
The runs between 69522 and 69892 are "High rate" runs. This exaplain the large contribution of the noisy events to the cluster multiplicity. TEC looks anomalous w.r.t. the general trend. This is due to the problem of the out of sync TEC+ modules which introduces a large cluster multiplicity in every bin on the APV cycle.
During the high rate runs (since run 69522) it has been observed that the number of digis and clusters increased quickly and steadily in the first minutes of the high rate period due to some (10-20) modules of TEC+. It has been observed, also, that the TEC digi multiplicity shows a step-like behavior in almost all the runs, including the low/cosmic rate ones.
The digi multiplicity maps of some runs have been investigated and the list of modules with more than 5-10 digis per event (on average) have been selected. With this procedure all the bad TEC+ modules has been identified in the high rate runs. It appeared that all these modules are in TEC+ Sector 5 and most of them (but not all of them) in ring 5 and 7. In the following table all the modules which were found with an anomalous digi multiplicity in TEC+ Sector 5 are listed with the information of the runs when they were bad.
| Disks | Petals | Rings | Modules | 69365 | 69522 | 69557 | 69564 | 69750 | 69788 | 69797 | 69800 | 69850 | 69874 | 69892 | 69912 | 70416 | 70664 | 70674 | ||
| Disk1 | BP | R5 | 470308262 | x | x | x | x | x | x | x | x | x | x | x | x | x | x | |||
| R5 | 470308265 | x | x | x | x | x | x | x | x | x | x | x | x | x | x | |||||
| R7 | 470308332 | x | ||||||||||||||||||
| FP | R5 | 470312357 | x | x | x | x | x | x | x | x | x | x | ||||||||
| R5 | 470312361 | x | x | x | x | x | x | x | ||||||||||||
| Disk2 | BP | |||||||||||||||||||
| R7 | 470324712 | x | ||||||||||||||||||
| FP | R5 | 470328741 | x | x | x | x | x | x | x | x | x | x | ||||||||
| R5 | 470328742 | x | x | x | x | x | x | x | x | x | x | |||||||||
| R7 | 470328816 | x | ||||||||||||||||||
| Disk3 | BP | R4 | 470341004 | x | ||||||||||||||||
| R5 | 470341030 | x | x | x | x | x | x | x | x | x | ||||||||||
| R5 | 470341033 | x | x | x | x | x | x | x | x | x | ||||||||||
| R5 | 470341034 | x | x | x | x | x | x | x | x | |||||||||||
| R7 | 470341092 | x | x | |||||||||||||||||
| R7 | 470341100 | x | x | x | x | x | x | x | ||||||||||||
| R7 | 470341104 | x | x | x | ||||||||||||||||
| FP | R5 | 470345126 | x | x | x | x | x | x | x | x | x | |||||||||
| R7 | 470345188 | x | ||||||||||||||||||
| R7 | 470345196 | x | ||||||||||||||||||
| R7 | 470345204 | x | x | |||||||||||||||||
| Disk4 | BP | R3 | 470357348 | x | x | x | x | x | x | x | x | x | ||||||||
| R4 | 470357384 | x | x | x | x | x | x | |||||||||||||
| R5 | 470357417 | x | x | x | x | |||||||||||||||
| R5 | 470357421 | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | ||||
| R7 | 470357476 | x | x | x | x | x | x | x | x | x | x | x | x | x | x | x | ||||
| FP | R5 | 470361513 | x | x | x | x | x | x | x | x | x | x | x | x | ||||||
| R7 | 470361584 | x | x | x | x | x | x | x | x | x | x | x | x | |||||||
| Disk7 | BP | R4 | 470406532 | x | x | x | x | x | ||||||||||||
Following the links for each run number the list of outlier modules in each run is displayed with the average number of digis per event *10000. The 5 modules of TEC- which were bad in run 69750 and 69912 were due to a HV channel which was off.
During the
CRAFT08 test reprocessing with 31X run 70415 was analyzed and an additional
bad module was found: 470361576 (Disk4, FP5, Ring 7).
The above modules are in 5 different control rings (one per disk) in the same FEC (to be found). Nine power groups are involved, most of them of type "3", that is ring5+7 but also two of type "2" (ring3+4+6). The color in the ring column indicates the power group: modules with the same color in each disk are in the same power group. The 3D map of these modules is shown below as seen from the IP and toward the IP:
The same study has been performed also for the low/cosmic rate runs analyzed so far and high digi multiplicity has been observed in some of the same modules. In the following table the number of (low rate) runs in which each of the modules has been found anomalous is reported. In total 18 runs have been analyzed, in addition to the 11 reported above.
| Modules | number of runs |
| 470308262 | 1 |
| 470308265 | 6 |
| 470312357 | 6 |
| 470312361 | 9 |
| 470328741 | 1 |
| 470328742 | 1 |
| 470341030 | 4 |
| 470341033 | 1 |
| 470341100 | 4 |
| 470345126 | 2 |
| 470357421 | 6 |
| 470357476 | 8 |
Also in this case "all" the bad modules are from TEC+ Sector 5, the additional bad modules found with this procedure are likely due to bad PGs or to other problems not related to the loss of phase.
A better correlation between these modules and the step-like behavior has to be established by checking the digi multiplicity map in different time slices during the runs and by checking if the pattern of the bad digi in these modules in the low rate runs is compatible with the loss of APV-cycle phase with the procedure described below
These bad modules provide many (~50-100) digis in each event, most of them with saturated charge. The pattern of these digis has been investigated in order to understand which kind of possible failure affected these modules.
To test a possible loss of phase of the APVs in these modules w.r.t. the phase of the APVs of the rest of the Tracker, the pattern of the digi charge in each strip of these modules have been studied as a function of the position of the event within the 70-BX APV cycle. For each event the position within the APV cycle is determined by computing (orbitNumber*3564+bunchCrossing)%70 and the corresponding TProfile (out of 70) is filled with the charge collected in each strip of the module under study. The absolute phase of the APV cycle of the Tracker is determined from the noise studies described above.
The first results have been obtained by analyzing 1000 events of run 69522 during the LumiSection 90 (orbit number ~94M) when the high rate phase of this run was finished but the TEC(+) continued to have a high digi multiplicity. The profiles of the digi charge of the 18 bad modules of this run, reported above, have been studied as a function of the position in the APV cycle (in this run the cycle starts at 69). The profile bins are reshuffled in order to reproduce the sorting of the data in the frame transmitted by the modules, according to the rules provided by G. Sguazzoni. The results are compatible among all the modules and have the following features:
The following plots represents the (reshuffled) profile of the digi charge in the three data frames of module 470308262 for the events which occur in the first 51 bins of the APV cycle, red curve, and for the events which occur in the rest of the cycle, blue curve and in each of the 70 bins of the APV cycle in the 2D plot:
The same plot is available for module 470328741, as an example. The two above patterns can be explained by the following mechanism:
The bad module is out of phase by N BXs w.r.t. the rest of the Tracker. When a red or a blue trigger occurs, all the tracker modules, but the bad module(s), transmit a frame like the green one, at the beginning of n-th cycle after the trigger arrived. The bad module, instead, behaves differently w.r.t. the rest of the tracker whether the trigger is the red one or the blue one. If the red trigger occurs, between the beginning of the tracker cycle and the bad module cycle, the bad module transmitted frame (the red one) is too early and the final tick reach the FED when it is still reading the data (the FED uses the arrival time of the headers of the majority of the channels to start the frame readout). Instead when a blue trigger occurs, between the start of the bad module cycle and the start of the tracker cycle, the (blue) frame is too late and its header reach the FED when it has already started to read the data. The position of the tick or of the header contamination of the data depends on N and the distance is always 186 BX, as observed.
As a first test of the impact of the APV-induced noisy events on the track reconstruction with the collision configuration, some of these events have been selected and reconstructed using the StandardSequences of CMSSW 3_1_0_pre1.
In each of the analyzed runs four different classes of events have been selected:
In the following tables the number of selected events and the number of reconstructed tracks (generalTracks) for each of the above classes are reported
| TOB Huge Events | |||
| Run | Events | Events with tracks | Number of tracks |
| 66668 | 0 | 0 | 0 |
| 69912 | 75 | 0 | 0 |
| 70195 | 132 | 0 | 0 |
| 70675 | 19 | 0 | 0 |
It is likely that the last pixel-less step, called TOB+TEC, is not included, yet, in this study. TO BE FOLLOWED.
| TIBTEC Huge Events | |||
| Run | Events | Events with tracks | Number of tracks |
| 66668 | 1 | 1 | 1448 |
| 69912 | 147 | 110 | 66081 |
| 70195 | 137 | CRASH | CRASH |
| 70675 | 23 | CRASH | CRASH |
In these events all the reconstructed tracks are with |eta| >1-1.2 which means endcaps.
| FrameHeader Events | |||
| Run | Events | Events with tracks | Number of tracks |
| 66668 | 7 | 0 | 0 |
| 69912 | 1770 | 41 | 117 |
| 70195 | 3265 | 113 | 373 |
| 70675 | 550 | 0 | 0 |
Also in these events all the reconstructed tracks are with |eta| > 1-1.2 and almost all of them are in the TEC-. This could be due to the fact that TEC+ common mode subtraction was not ok until run 70395 and, therefore, the noise could be suppressed. The FrameHeader Event selection selects events in a wide DBX range (23 bins). The noise level in these bins is not at all uniform as discussed in other places. Therefore it would be interesting to tighten the selection to isolate the real source of fake tracks. TO BE FOLLOWED
| Latency+1 Events | |||
| Run | Events | Events with tracks | Number of tracks |
| 66668 | 1 | 0 | 0 |
| 69912 | 214 | 0 | 0 |
| 70195 | 140 | 0 | 0 |
| 70675 | 22 | 0 | 0 |
