The Athena monitoring framework

The Athena framework provides a setup for producing histograms for online and offline Data Quality Monitoring. For the offline DQM, the Athena monitoring is the primary interface for producing histograms from the reconstruction that runs on Tier-0¹. The online DQM, on the other hand, runs in real time on a fraction of the events processed by the Event Filter level of the ATLAS trigger (see Figure 4.8). The advantage of the Athena monitoring is that it can run online, through the processing of Raw Data (RDOs), but is based on standard offline software and is thus able to reconstruct objects such as tracks. This also implies that the resulting online histograms can be reproduced offline at a later stage by accessing the RDOs.

The Athena monitoring runs on sampled events provided by the EMon service, which are selected specifying trigger type and other configurable parameters, such as event rate.

The SCT Athena monitoring is composed of several tools producing different types of histograms; SCTHitsNoiseMonTool,SCTTracksMonTool,SCTHitEffMonTool and SCTErrMonTool. As the naming suggests, these tools produces different kinds of histograms:

1Tier-0 is a large computer farm located at CERN, where the data recorded by the experiments is first stored, before being distributed to the smaller Tier-1s and Tier-2s

Figure 4.8: A schematic overview of the data flow in the online monitoring, starting with events recorded by the ATLAS trigger and the SCT RODs and finishing with the OHP and DQMD displays viewed by the SCT shifter.

• Hits histograms. The SCTHitsNoiseMonTool produces two-dimensional maps of the number of hits in the modules for each barrel layer and end-cap disk. The 2D maps are also produced for each link (side) of the module. Figure 4.9 shows the hit map for the second innermost SCT barrel layer, link 1. The monitoring is even capable of publishing hit maps for every module and side in the SCT (about 8000 histograms).

• Noise occupancy. The SCTHitsNoiseMonTool provides a 2-dimensional noise occupancy histogram for each link of every barrel layer and end-cap disk. The tool also provides summary histograms of the noise occupancy for the entire SCT as well as the barrel and end-caps separately. A hit is defined as noise if it is not part of a space point belonging to a reconstructed track (see section 4.2.2).

• Tracking histograms. The SCTTracksMonTool produces histograms such as hits-on-tracks, residuals, pulls and RMS of the tracks. It also publishes overall histograms such as the accumulative number of tracks for the current run. This is a useful histogram for immediate detection of a possible issue with the SCT, seen as a sudden decrease in the track rate. The track tool also produces histograms for the timing of the hits-on-tracks. The SCT is read out for three time bins for each bunch-crossing for each trigger. If the SCT signal arrives in

the time-slot before or after the trigger, it would be visible in these histograms as a shift compared to the reference.

• Efficiencyhistograms. The SCTEffMonTool calculates the hit efficiency of the modules and publishes 2D histograms for each barrel layer and end-cap disk (for each side) showing the efficiencies of the individual modules. It also produces summary histograms, such as the average efficiencies for each layer in the barrel and end-cap disk.

• Different type of errors. The SCTErrorMonTool produces the same setup of 2D histograms as the efficiency and noise tool for different type of errors. There are errors originating from the hardware, such as timeout errors and errors re-lated to synchronization conflicts with the rest of ATLAS and the LHC, such as Level 1 ID errors and bunch-crossing ID errors. There are also summary 2D histograms combining the total of the individual errors. This particular tool also combines information from all tools in order to produce the so called con-figuration histogram. This histogram (shown in Figure 4.11) gives an overview of the SCT by presenting the number of disabled modules in the SCT, the num-ber of noisy modules, modules giving errors, inefficient modules and finally the number of links that are masked off.

Figure 4.9: The 2D map of SCT hits for link 1 of the second innermost barrel, during data-taking.

The output produced by the monitoring is handled by the Online Histogramming Service (OHS), which supports raw and ROOT files. It allows for the routing of commands; any application can issue a command related to a particular histogram and

the OHS takes care of sending the command to the appropriate histogram provider.

The OHS uses the Informations Service (IS) to manage histograms and provide a transient storage between histogram producers and displays. The IS is also used for archiving and sharing information among the various DAQ applications. It routes information such as run conditions, beam parameters, message logs, etc.

The Athena monitoring package produces an output ROOT file containing his-tograms grouped into directories and sub-directories according to the different types of histograms and which part of the detector they concern. The code processes the events in parallel through five instances running on different machines in order to increase the sampling rate. The maximum event processing rate is about 1 Hz. The five different instances are combined by a Gatherer, which publishes the summary through histograms containing the combined results. In this manner, if one of the Athena monitoring instances fails, the monitoring output will still be provided, merely at a lower rate.

The histograms provided by the Gatherer, as well as those provided by separate instances, are published to the IS server. These can be viewed, together with the histograms from the other sub-detectors, in the Online Histogramming (OH) display.

The OH display is not as user-friendly as the more developed displays such as the OHP or DQMD (see below). The OH display simply shows the content of the OHS in a modified ROOT browser, which can be very useful for debugging and for back-up in case the OHP and/or DQMD presenters are temporarily not functioning.

The final step of the online DQM data flow is for the histograms to be passed to the more refined shifter-friendly displays; the Online Histogramming Presenter (OHP) and the Data Quality Monitoring Display (DQMD) (see Fig. 4.8), where the latter provides automatic data quality checks for the histograms. The histograms shown can be both from the combination of the different Athena monitoring instances provided by the Gatherer and histograms from one of the separate instances.

Trigger aware monitoring

During the last years of commissioning and data-taking, another tool has been added to the DQM in order to provide trigger awareness to the Athena monitoring. The trigger aware monitoring enables the option of producing different sets of histograms for the separate trigger streams. This function is useful if, for example, one would like to acquire information on SCT tracks from one particular trigger stream. One of the advantages with the trigger aware monitoring is the ability to measure the noise occupancy for only empty bunch triggers. The trigger aware monitoring then uses the collision-less trigger as input to produce noise occupancy histograms for the scenario where no tracks are expected. This is one of the prominent ways of properly measuring the noise while LHC is providing ATLAS with p-p collisions.