Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
  • Allen Allen
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 183
    • Issues 183
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Jira
    • Jira
  • Merge requests 72
    • Merge requests 72
  • 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
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • LHCbLHCb
  • AllenAllen
  • Merge requests
  • !1083

Generate lumi schema in Allen configuration

  • Review changes

  • Download
  • Email patches
  • Plain diff
Merged Daniel Charles Craik requested to merge dcraik_lumi_json_config into master Dec 07, 2022
  • Overview 68
  • Commits 27
  • Pipelines 25
  • Changes 21

This MR moves the generation of a lumiSummary schema into the Allen configuration (currently performed manually). A list of counter names and required capacities is added to lumi_reconstruction.py and is used to generate an optimised lumi schema. This schema is propagated to the lumi algorithms to use in place of the previously used header file. This removes the need to externally generate both enum and json representations of the schema and manually copy these into the Allen codebase.

The lumi schema is passed from the python configuration code to the C++ algorithms as a property in the structure {counterName : (counterOffset, counterSize) ... }, which is processed by init in each lumi algorithm to extract the offsets and sizes of the required counters. Currently, if an algorithm fills a counter that is not in the schema, the counter is just ignored (specifically, its size is set to 0 so that nothing is written to any offset) and a message is printed to the output. I'm not sure if this is the desired behaviour (I'm not aware of an existing example of Algorithm::init terminating execution so I assume we prefer to avoid that).

As std::pair seems to be incompatible with device code and nested std::arrays incompatible with Gaudi, offsets and sizes for the counters used in a given algorithm are stored in a std::array<unsigned, 2*N_counters>.

The current implementation does not explicitly support two concurrent lumi schemata (as would be needed if/when we add a second post-scaled lumi line) but should be simple to extend - assuming we go the "two summary banks" route, the map passed to the algorithms would come from the combination of the two schemata and the tuple for each counter would be extended to include an index for the lumi summary. If we instead go the "extended summary" route, then the generation code would change to be able to group the mandatory and optional fields into separate words with the optional ones at the end and the code in the algorithms would be unchanged (in either case the writer would obviously change).

Depends on LHCb!3904 (merged) to commit new lumi schemata to the git repository.

As this MR changes the way the lumi summary counters are configured, it will have merge conflicts with !1040 (merged) and !1079 (merged). The simplest approach is probably to merge !1040 (merged) then this MR, then !1079 (merged).

FYI @raaij @dcampora @sxian @edallocc @egraveri @balagura

Edited Dec 15, 2022 by Daniel Charles Craik
Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: dcraik_lumi_json_config