All the ROS Monitoring histograms are defined and filled inside the file ROSMonSCT.cxx, that is of course part of the SctRosMonitor code. They can be divided into four categories:

- SCT ROD Errors
- SCT ROS Errors
- SCT MOD Occupancies
- SCT ROS Occupancies

The SCT ROD Errors histograms contain informations about all the possible errors that can occur on the ROD level, while the SCT ROS Errors histograms contain informations about the errors occurring in one ROS (corresponding to 11 or 12 RODs).

The SCT ROS and MOD Occupancies contain informations about the number of hits recorded by an entire ROS (~528 modules) or by a single module. The Occupancy plots are filled two times, once with "simple" hits (in the code are called "remain"), and once with coincidence hits (called "coinc" in the code). The coincidence hits are identified by a very simple algorithm (opposite side +/- 128 Strips).

All the histograms are published for all the 8 indipendent ROSs that are inside the SCT:

- BA-00
- BA-01
- BC-00
- BC-01
- ECA-00
- ECA-01
- ECC-00
- ECC-01

Called m_sum in the code, this histogram contains the number of hits vs the module number. The module numbering is ROS internal, but the conversion to the other coordinates systems is available on https://pc-sct-www01.cern.ch/ModInfo/.

Called m_sum_time in the code, this histogram contains the total number of hits in the ROS vs time (expressed in seconds). It is a rolling histogram, in the sense that, when all the bins are filled, they start rolling from right to left. In each moment, the total number of bins is 2^14=16384 (in the code you will see 1<<14).

Called m_sum_evt in the code, this histogram contains the total number of hits in the ROS vs the 'event number'. The event number is actually just a counter, and thus there is no relation between the event_id of one ROS and the event_id of another ROS (same event_id do not correspond to the same event, because different ROSs sample different events!). This is also a rolling histogram, but it has some specific problems due to the number of bins. Since we have more than one event for second, 2^14 bins are not enough, and we need to have 2^16. With so many bins the histograms is too heavy to be presented in OHP, and for this reason we decided to create the following histogram.

Called m_thr_evt in the code, this histogram is filled with the total number of hits in the ROS ONLY IF the number of hits per single module is greater than 384 for at least one module (this corresponds to 25% of occupancy, where the occupancy is defined as the number of hits in a module divided by the nominal number of chips). In other words, only the events in which there was at least one module with an occupancy greater than 25% contribute to this histograms. The histogram is rolling as the others, and on the x axis we have now another event counter, which is called just 'event counter'.

Called m_sum_l1a in the code, this histogram is showing the total number of hits in th ROS vs the l1_id.

Called m_sum_bci in the code, this is a bi-dimensional histogram showing the total number of hits in th ROS vs the bci_id and vs time.

-- EleonoraBenhar - 28-Mar-2011

Topic revision: r9 - 2011-05-16 - EleonoraBenhar

Copyright &© 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.

or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback

or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback