Skip to content
GitLab
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 14
    • Issues 14
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Jira
    • Jira
  • Merge requests 15
    • Merge requests 15
  • 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
  • LHCbLHCb
  • DaVinciDaVinci
  • Merge requests
  • !815

Add MCPrimaries and more MC functors

  • Review changes

  • Download
  • Email patches
  • Plain diff
Open Jiahui Zhuo requested to merge jzhuo_MCPrimaries into master Jan 20, 2023
  • Overview 15
  • Commits 18
  • Pipelines 15
  • Changes 5

Following the discussion in Rec#409

This MR creates the necessary tools to replace the MCTupleToolPrimaries in Funtuple, and also adds some useful MC functors.

What is done?

  • Read all MC PVs from MC_Header FYI: @amathad
  • Refactor MC functors like: MOTHER and ORIGINVERTEX
  • New MC functors are included like MC_LIFETIME, MC_VTX_TYPE..
  • New functional functor TARGET to get the pointer from LHCb::SmartRef (Needed to get objects from MC_Header)

FAQs:

How does get_mc_header() work?

as @ldufour discussed in Rec#409 (comment 6241665), the get_mc_header() will require first the MCVertices are unpacked, since the MCVertices are unpacked automatically using get_mc_particles(), the dependency here is to require mc_particles as inputs to chain the dependency automatically.

Why do we refactor F.MOTHER and F.ORIGINVERTEX?

before ORIGIN_VX, ORIGIN_VY, and ORIGIN_VZ are three different functors which don't make sense, not it's defined as a composition of more basic functors like:

ORIGIN_VX = X_COORDINATE @ POSITION @ MC_ORIGINVERTEX
ORIGIN_VY = Y_COORDINATE @ POSITION @ MC_ORIGINVERTEX
ORIGIN_VZ = Z_COORDINATE @ POSITION @ MC_ORIGINVERTEX

which is more elegant and cleaner in the code.

Why do we need F.TARGET?

The LHCb::SmartRef will only fetch the object when the object is called, the Sel::Utils::deref_if_ptr can't handle this smart pointer correctly, so the F.TARGET is called to convert this LHCb::SmartRef to the classic pointer.

This should be tested with Analysis!946 Rec!3279 LHCb!3935

FYI: @pkoppenb @erodrigu @amathad @ldufour

Edited Jan 20, 2023 by Jiahui Zhuo
Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: jzhuo_MCPrimaries