Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
  • Corryvreckan Corryvreckan
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 38
    • Issues 38
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 12
    • Merge requests 12
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Issue
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • CorryvreckanCorryvreckan
  • CorryvreckanCorryvreckan
  • Merge requests
  • !273

Add new module: TrackingMultiplet

  • Review changes

  • Download
  • Email patches
  • Plain diff
Merged Paul Jean Schutze requested to merge pschutze/corryvreckan:multiplet into master Apr 02, 2020
  • Overview 108
  • Commits 109
  • Pipelines 24
  • Changes 12

This MR adds a new module, TrackingMultiplet and a corresponding Track object Multiplet.

A multiplet track consists of two StraightLineTracks, one up- and one downstream, that can be matched at the position of a scatterer. Hence, for the tracking, first a track finding for the two tracklets is performed, then a matching of these two.

For the tracklet finding, the first and the last detector in the lists of up- and downstream detectors are used as references. Every combination of clusters in the two reference detectors is a track candidate, and clusters are added along this track if the spatial and the time range (config parameters) matches. The candidate is discarded when the number of clusters is too low or another tracklet is found within an isolation range (config parameter) at the position to the scatterer.

For the matching, every upstream tracklet is checked for matching downstream tracklets. The closest match, if within the matching cut (config parameter), wins.

Along the way, the only change closer to the core is another getter function for KDTree objects, where one can now get the full ClusterVector.

Things you could probably help me with:

  • Is the time matching for the tracking handled appropriately?
  • Should there be a time matching between up- & downstream tracklets? If yes, how?
  • There's currently a lot of different spatial cuts. Should/could this be simplified?

Edit:

Some more things to check before being ready to merge:

  • Check on a more performant iteration over detectors suggested by @simonspa
  • Add module test
  • Check for memory leaks (duh)
Edited May 12, 2020 by Paul Jean Schutze
Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: multiplet