Luminosity counter monitoring
As part of the main lumi line(s), some monitoring based on the computed counters needs to be produced, both for luminosity calibration and for general condition monitoring (see also #XYZ).
Here is a preliminary list of necessary monitoring output:
- Counters, every second
-
(for each bx type): number of selected lumi events -
(for each counter and bx type): number of events over threshold (from CondDB)
-
- Histograms, every few minutes (or more for 2D)
-
(for each bx type): number of selected lumi events per BCID (1D) -
(for each counter and bx type): number of events over threshold per BCID (1D) -
(for each counter and bx type): number of events per counter value (1D) -
(for each counter and bx type): number of events per counter value and BCID (2D) -
(for each bx type and some pairs of counters): number of events per counter value (2D)
-
When binning counter values, non-uniform bins will be necessary, which might be different depending on the counter. If there are more than one lumi lines, each must be able to output independent monitoring histograms and counters.
HLT1 has the benefit of seeing the full rate of unbiased events. As such it is very beneficial to define a "parasitic" lumi line that uses the physics line reconstruction to compute some counters. Ideally, the physics reconstruction runs on all events (i.e. there is no GEC). If there is a GEC, whenever an event does not pass, a large placeholder value can be used for the counters. Then, the monitoring as described above would also run on such a parasitic lumi line.
During VDM or emittance scans, the beam positions and mu change rapidly. The monitoring information should be ideally synchronised with the ODIN step number (i.e. cut off and send data when a step ends), or if not possible (e.g. due to limitations of the monitoring system after HLT1), data must be sent out with a sufficiently high rate (once every second) so that it can be selected afterwards.