Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
  • athena athena
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Jira
    • Jira
  • Merge requests 180
    • Merge requests 180
  • Deployments
    • Deployments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • Code review
    • Issue
    • Repository
  • Activity
  • Graph
  • Commits
Collapse sidebar
  • atlas
  • athenaathena
  • Merge requests
  • !47380

Merged
Created Oct 19, 2021 by Tadej Novak@tadejDeveloper

Improve systematics handling in AsgxAODNTupleMakerAlg

  • Overview 15
  • Commits 1
  • Pipelines 1
  • Changes 3

This is an alternative implementation to !47105 (closed). I opened a new MR as this is basically another approach to the same solution. As systematics are now handled by the SystematicsSvc we need to properly handle that also in the output algorithms. Besides just updating the AsgxAODNTupleMakerAlg to use SystematicsSvc directly I also implemented some improvements to the flexibility of the algorithm.

The algorithm itself is quite smart and can parse container and variable names automatically. The problem are systematics. Now a branch will only be written for a given systematic if it is affected by it (either at the container or decoration level).

In my tests this yields all the branches as before without relying on how the decoration names are built.

The only caveat with this change is is that the same container/variable name needs to be used as defined in the algorithm or sequence, e.g. if one outputs AnalysisMuons_%SYS% with the decoration effSF_%SYS%, then AnalysisMuons_%SYS%.effSF_%SYS% -> mu_effSF_%SYS% works but AnalysisMuons_NOSYS.effSF_%SYS% -> mu_effSF_%SYS% does not as SystematicsSvc is only aware of AnalysisMuons_%SYS%.

/cc @krumnack @jburr @mmuskinj

Edited Oct 19, 2021 by Tadej Novak
Assignee
Assign to
Reviewer
Request review from
Time tracking
Source branch: cp/outputalg