Skip to content

Generate lumi schema in Allen configuration

Daniel Charles Craik requested to merge dcraik_lumi_json_config into master

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 by Daniel Charles Craik

Merge request reports