Skip to content

Draft: Track residual ART tests

Matous Vozak requested to merge mvozak/athena:mu-nsw-arttest into main

This is the first MR request to make muon track residual ART tests.

The idea is as follows:

  • During the reconstruction create an ntuple that would store relevant information containting hit/measurement information (station eta,phi,channel etc) all associated to selected tracks
  • A simple (python) script will then run over this ntuple and dump the residuals (and other information) into the histograms
  • These histograms will then be used by dcube and ART SW for continues monitoring against a reference to study any changes

Technical implementation:

  • I was thinking a bit where to implement such ntuple dump. I have found several locations of packages/algs scattered across the MS

https://gitlab.cern.ch/atlas/athena/-/tree/master/MuonSpectrometer/MuonValidation/MuonTrackValidation

https://gitlab.cern.ch/atlas/athena/-/tree/master/MuonSpectrometer/MuonValidation/MuonRecValidation/MuonRecValidationNtuples

https://gitlab.cern.ch/atlas/athena/-/tree/master/MuonSpectrometer/MuonValidation/MuonRecValidation/MuonTrackPerformance

https://gitlab.cern.ch/atlas/athena/-/blob/master/MuonSpectrometer/MuonValidation/MuonHistogramming/MuonHistUtils/Root/MuonTree.cxx

https://gitlab.cern.ch/atlas/athena/-/tree/master/MuonSpectrometer/MuonValidation/MuonPRDTest

below I provide my understanding of these but to summarise I think the most feasible place is either MuonPRDTest or MuonTrackPerformance pkg. For now as a first attempt I have tried the latter for A) it contains already some nice functions to select and print various information about tracks B) MuonPRDTest does not contain association to tracks anyway C) just from the name having it in MuonPRDTest might be confusing. In the first push you will see that I basically try to use functionality from the MuonTesterTree and MuonPRDTest inside the PerformanceAlg pkg. At this moment, the code compiles, runs and produces an ntuple with for now track kinematics from Truth TrackRecords. What I am trying to figure out now is how to add the hit information but associated to each track. I was thinking of doing something similar as in the stand-alone MuonTester. Basically having an additional vector branch of integers with the length of the data (PRD/RDO/SDO...), filled with track index. However, this would probably require potential changes to the variables, e.g. for instance passing track collection in the fill and do some sort of matching here. Perhaps, there is a better way though. I am happy to discuss this.


Some brief description of packages mentioned above:


https://gitlab.cern.ch/atlas/athena/-/tree/master/MuonSpectrometer/MuonValidation/MuonTrackValidation

https://gitlab.cern.ch/atlas/athena/-/tree/master/MuonSpectrometer/MuonValidation/MuonRecValidation/MuonRecValidationNtuples

  • Contains MuoninsideOutAnalysis with hard coded histograms to fill (including residuals and pulls)
  • Stores various information about segments, time, hits, candidates, …
  • Author Niels Van Eldik? (seems at least 7 years old)

https://gitlab.cern.ch/atlas/athena/-/tree/master/MuonSpectrometer/MuonValidation/MuonRecValidation/MuonTrackPerformance

  • Can be turned on by doTrackPerformance muon flag
  • Main output is text file with track info (efficiency of reco etc)
  • No ntuple as output
  • Contains already a lot of track/segment related algorithms (mainly just counters … )

https://gitlab.cern.ch/atlas/athena/-/blob/master/MuonSpectrometer/MuonValidation/MuonHistogramming/MuonHistUtils/Root/MuonTree.cxx

https://gitlab.cern.ch/atlas/athena/-/tree/master/MuonSpectrometer/MuonValidation/MuonPRDTest

  • Stores prep data (RDO, SDO, PRD, Hits …)
  • Can probably implement this relatively easily but here I don’t have association to muons/tracks
  • It uses two types of data structure:
    • MuonTesterTree
      • With MuonTesterBranches (Vectors, Matrix )
    • ValAlgVariables

Merge request reports