Skip to content

Draft: Add RecAlg to tuple lumisummary-like information from RawBankspre-commit fixes

Oscar Boente Garciarequested to merge
obo_rawbanks_lumisummary into master

This MR adds a new RecAlg to tuple global information on Lumi lines when RAWBANK information is available. Follows Rec/RecAlgs/src/LumiSummaryTuple.cpp, adding additional information directly read from the RAWBANKS.

The algorithm is called from Moore with a script similar to Hlt/Hlt2Conf/options/lumisummary_lumistream_tupling_vdm_2024.py. This script is being added in [To be included: merge request in Moore].

A use case is to process the NOBIAS stream of Lead24 data, where raw banks are persisted with the 1kHz lumi line. The script includes information required for studies of LHC backgrounds and the determination of the centrality in ion collisions. The list of information from the RAWBANKS added to the tuple is:

  • Global occupancy variables from rawbanks:
    • Total VeloClusters and VeloClusters per region
    • Total ECAL energy, ET, and per CALO region (to be cross-checked)
    • Total HCal energy and ET
    • Total Muon hits and per station (to be cross-checked)
    • Total SciFi clusters and per station (to be cross-checked)
    • Plume: RawPlumeTotalADC, RawPlumeMeanADC, RawPlumeNCoinc (how relevant this variables are right now?)
    • Total UT clusters
    • Total RICH1 and RICH2 hits
  • Velo track information, an array with all velo tracks in the event is saved, the information per track is chi2, nDoF, phi, eta, tx, ty, isBackwardTrack, nVPclusters, Closest-to-beam-state (x, y, z)
  • Primary vertex information, an array with al PVs in the event is saved, info per pv: (x, y, z) position, chi2, ndof

This MR goes with XXXXX. There, an option file to run on NOBIAS Lead24 data is added.

To be added (or discussed about its relevance):

  • Fill number information (from ODIN or lhcb conditions),
  • SMOG gas, conditions, etc
  • Select either Retina or SuperPixels is used (now hardcorded to SP as it is what was used in Lead24 data-taking)
  • Number of tracks per PV. This can be guessed from nDof, but it is better to know directly from the source, and know how many are backward and how many forward per PV.
  • Do we want to make some of the Inputs optional? It could be interesting if for some dataset we only store raw banks from given sub-detectors. As it is now, a input needs to be passed for each sub-detector for the algorithm to run.

cc @vazhovko . Adding also @carata and @chgu, as they are working on the LHC background study in lead-lead and might have feed-back which information is interesting to include.

Edited by Oscar Boente Garcia

Merge request reports