Skip to content

R3 trigger matching

Jon Burr requested to merge jburr/athena:R3TriggerMatching into master

Draft implementation of trigger matching using the navigation graph.

In order to do this I had to implement the mechanism to build trigger combinations. For now I decided not to use the code in TrigCompositeUtils/Combinators.h as it didn't have a good way to handle legs with > 1 multiplicity (the duplicated objects had to be filtered out afterwards) and there was no to use the CombinationIterator in a generic way (i.e. without knowing the collections that will be iterated over at compile time).

To do this I added in two STL-type iterators. The KFromNItr is used to generate combinations (i.e. picking 'k' numbers from a range 'N') and the IPartCombItr which uses a series of those to generate the different combinations of actual LinkInfo objects. STL-style range-based for loops are provided by having a Combinations class whose begin and end methods return these types of iterator.

I tested that the R3MatchingTool at least sometimes returns true for all of these chains:

  • HLT_e3_etcut_L1EM3
  • HLT_e5_lhmedium_L1EM3
  • HLT_2e3_etcut_L12EM3
  • HLT_mu6_L1MU6
  • HLT_mu6_ivarmedium_L1MU6
  • HLT_2mu6_L12MU6
  • HLT_e17_lhloose_mu14_L1EM15VH_MU10
  • HLT_e7_lhmedium_mu24_L1MU20
  • HLT_e26_lhmedium_mu8noL1_L1EM22VHI

Obviously more in-depth testing is required but these seem to cover a good range.

I added a function returning a Combinations object to TrigCompositeUtils - long term I would propose removing the code in Combinators.

Right now I only have a version here that returns combinations like std::vector<TrigCompositeUtils::LinkInfo<xAOD::IParticleContainer>>, but I could also write versions returning std::tuple<TrigCompositeUtils::LinkInfo<Ts>...> (where Ts is a variadic template parameter pack provided in the call) if that level of flexibility is required/desired as well.

Edited by Jon Burr

Merge request reports