Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
  • R Rec
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 289
    • Issues 289
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Jira
    • Jira
  • Merge requests 65
    • Merge requests 65
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • LHCbLHCb
  • Rec
  • Merge requests
  • !488

PrLongLivedTracking: Correctly update the X-projection before calculating the MVA value for a Track

  • Review changes

  • Download
  • Email patches
  • Plain diff
Merged Christoph Hasse requested to merge FixPrLongLivedTrackingXProj into master Feb 01, 2017
  • Overview 3
  • Commits 2
  • Pipelines 0
  • Changes 1

This adds an update of the x-projection before adding it to the deviation variable used for the MVA.

Problem in previous version:
The call to hit->projection() did not return the correct x-projection associated with the track we are currently calculating the MVA value for.
This is because the track only owns the pointer to the hit, so a different track candidate can later on pick said hit up again and update the projection.
Therefor a call to hit->projection in line 526 will return a value that was actually calculated with the last track candidate that used this hit.

To check I ran the reco over 300 Events and did not see any significant changes in the timing due the additional update call.
The number of reconstructed tracks is now 39106 vs previously 39061.

Hi @decianm, as discussed just "pinging" you on here so you can have a look :) Thanks!

Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: FixPrLongLivedTrackingXProj