Skip to content

Derivation Framework trigger matching

Jon Burr requested to merge jburr/athena:DFTriggerMatchingSeparateTools into 21.2

This has all the necessary code for performing trigger matching in the derivation framework.

There are three main tools

  • IParticleRetrievalTool This tool is responsible for building the full list of combinations of online objects that passed the trigger.
  • DerivationFramework::TriggerMatchingTool This tool builds the list of online combinations corresponding to the objects retrieved above. They then get written out to the StoreGate in xAOD::TrigCompositeContainers
  • Trig::MatchFromCompositeTool This implements the Trig::IMatchingTool interface but works by reading in the containers written in the above tool.

I've tried to comment the code fairly comprehensively but there will (inevitably) be areas where I've failed to do that so please ask wherever things aren't clear so that I can improve the comments.

I've run two sorts of tests with this:
The first was to run the composite-writing tool and then directly after it run an algorithm comparing the results of the new tool and the old tool. The second was to run the tool in the derivation framework (as intended) and then run the comparison algorithm on the resulting file. I've commited the comparison algorithm in the DerivationFrameworkTrigger package in case anyone wants to run these tests themselves but it would probably be a good idea to remove it before accepting the MR.

There are differences between the two tools.

  • Egamma triggers can sometimes return multiple objects per RoI (usually only one passes the trigger selections and the objects are, by construction, close to each other). In the current matching tool both objects are returned as candidates for the matching. In this tool only the highest pT object is returned and each leg of the trigger is guaranteed to only return one candidate.
  • In egamma etcut triggers the trigger selection is only done on the calocluster. In the current matching tool the matching is done between the user provided egamma object and the online calocluster, in the new tool the matching is done between the primary calocluster of the offline object and the online calocluster. The current tool can also sometimes produce quite a long list of caloclusters that lie a long way below the threshold - I think this is to do with the above point but I'm not sure.

These differences account for all of the differences I've observed between the two tools.

I'm happy to provide more information about the tests run and to run others if necessary.

On top of this it would be good to have a 'quality of life' additions to make it easier to sequence this process in the derivation framework - those can come in a later MR.

Tagging @jcatmore, @akraszna, @tamartin and @tbold for comments.

Merge request reports