Skip to content

GitLab

configurations for Hlt1 and Hlt2 track reconstruction

Merged Sascha Stahl requested to merge sstahl_Hlt2Reco_newConf into master

Based on !180 (closed)

  • Hlt2 track reconstruction is now implemented
  • major code cleanup and restructuring (factorization of reconstruction and selection), closes #41 (closed) and #33 (closed)
  • revisited existing qmtests and added new ones
    • add tests for HLT2 reconstruction
    • removed HLT1 test (including MVA lines) and replaced it with an HLT1 reconstruction-only test

The dataflow configuration in this MR attempts to follow a few simple principles.

  1. Objects representing particles "flow" through the make_* functions. Tracks are one such example. Each configuration function produces a new data by adding some new information. E.g. the VELO UT tracking adds UT cluster information to VELO tracks, thereby extending them. DataHandles of object representing particles are passed as positional arguments, while all others are passed as keyword arguments with appropriate defaults. For example, make_velout_tracks

    • takes velo_tracks as a positional argument (no default)
    • takes make_ut_clusters (the function that returns the UT clusters) as a keyword argument with a default
    • returns the output tracks of the VeloUTTracking algorithm

    Functions that start from raw data (e.g. make_velo_tracks) take no positional arguments. Steps that combine multiple objects representing particles (e.g. combiners or the TrackBestTrackCreator) take multiple positional arguments as inputs.

  2. Conversions are configured "immediately" after producers. For example, make_upstream_tracks

    • follows the first principle and takes VELO tracks as input
    • uses an algorithm to do the VELO-UT tracking (by default make_velout_tracks, but can be changed for anything with the same output type)
    • configures the possible conversions and returns all track objects of different types (currently in a dictionary)

  3. The functions above only define a single "logical" step (e.g. extending with UT information). The global data flow is configured in as "flat" as possible functions, where the logical steps are pieced together. These functions can return multiple outputs, e.g. make_hlt2_tracks returns all intermediate track containers plus the "Best" track container.

Edited by Rosen Matev