Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
  • DaVinci DaVinci
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 19
    • Issues 19
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Jira
    • Jira
  • Merge requests 9
    • Merge requests 9
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • 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
  • LHCb
  • DaVinciDaVinci
  • Merge requests
  • !84

Merged
Created Jul 25, 2017 by Alex Pearce@apearce🌈Maintainer

Fixes for Tesla productions under Stripping28

  • Overview 15
  • Commits 1
  • Changes 1

This MR fixes the issue found in LHCBGAUSS-1108, namely that Tesla was not producing ProtoParticle ↔ MCParticle relations tables in 'DST-style' productions, where the MC particles are not filtered.

The issue was a change in the behaviour of how the ChargedPP2MC algorithm treats RootInTES between Stripping26 (DaVinci v41r2p5) and Stripping28 (v41r4p2). The changes were for the better, and Tesla was exploiting the old behaviour in an odd way, but somehow I didn't spot this change when porting the S26 patches to S28.

I'm running a larger validation locally right now, but I'm pretty sure this is the source of the problem. This MR targets 2016-patches with the intention of becoming the v41r4p3 release.

/cc @rmatev @gcorti

Assignee
Assign to
Reviewer
Request review from
Time tracking
Source branch: apearce-tesla-mc-s28-yet-again