Monitoring Level 1

Murrough Landon - 19 February 2003
(Level 1 Calorimeter Trigger Group)

Overview

• Introduction
• Trigger Decision
• Trigger Hardware
• Trigger Rates
• Monitoring Matrix

Introduction

Level 1 Trigger

• ``Level 1'' comprises the calorimeter trigger, the barrel (RPC) and endcap (TGC) muons triggers, the central trigger processor (CTP) the Muon CTP interface
• The monitoring requirements of different ``Level 1'' subprojects vary in detail, but there are also some common features.

• This talk concentrates on the Level 1 calorimeter trigger (though our detailed requirements have not been updated for a while)
  http://www.hep.ph.qmul.ac.uk/l1calo/doc/pdf/MonReqs.pdf

Trigger Decision

Check the level 1 trigger is functioning correctly

• For the calorimeter trigger, monitor the whole chain from calorimeter analogue electronics, through receiver stations, preprocessor, cluster and jet/energy processors to the CTP
• Use full calorimeter readout, readout from the preprocessor and later stages of the trigger pipeline
• Simulate the trigger functionality on a subset of events and look for errors
• Full simulation needs the full event: ie via SFI or on dedicated EF nodes
• Check both accepted events and sample of rejected events (selection of suitable monitoring triggers needs more thought)
• Partial simulation (of the digital trigger electronics from the preprocessor onwards) could be done on event fragments collected via ROD crate DAQ (if that supports coherent samples across 2-3 ROD crates)

Trigger Hardware

Monitor operational aspects of the trigger

• Check for levels of crosstalk, measure bit error rates on links and across backplanes, reliability of links, etc using both hardware monitoring via VME at O(1Hz) and event data (some overlap with trigger decision monitoring, but not all errors may affect the resulting L1A)
• Measure ``level 0'' rates and energy spectrum in each trigger tower: preprocessor hardware histogram per tower read by the crate CPUs (at $>$10Hz, but published less frequently)
• Rapid detection of new hot or dead cells, also indication of real beam conditions
• Check current calibrations are still optimal
• Readout related aspects: buffer utilitisation, etc
• Physical quantities (crates, temperatures, voltages, etc) via DCS

Trigger Rates and Performance

Detailed monitoring of rates and deadtime

• Trigger rates through the system: primitives (internal calo/muon details), CTP inputs, prescales, deadtime, final trigger ``items'', etc
• Rates per trigger tower (efficiency across eta-phi space)
• Correlations between trigger rates
• Correlations of trigger rates with beam conditions, etc
• History plots
• Etc...

Trigger performance

• Detailed studies will be mainly done offline, but some online checks may also be useful?

Monitoring Matrix

Impact of monitoring on the network

• We will surely use all available resources for monitoring - not sure what we absolutely need (and network bandwidth may not be the limiting factor)
• Some expected traffic flows (no numbers yet):
  • RODs (might have network interfaces?) to local workstations??
  • crate CPUs to local workstations (hardware monitoring, ROD events)
  • local workstations to central displays (histograms from local monitoring)
  • events to EF tasks
  • histograms/statistics from EF tasks to EF histogram collection
  • various sources saving data to conditions database

Miscellaneous

Where to monitor

• Monitoring at SFI/EF level and via ROD crate DAQ will be the most useful places for normal ATLAS physics running
• Monitoring via the ROS is needed for testing and installation

Calibration

• Some calibrations expected to be done at ROD crate level (events monitored via ROD crate DAQ or maybe on board DSPs)
• Other calibrations will require dedicated EF tasks (or offline)