Skip to content

Remove hardcoded btaggingLink

This is a big one, relating to #35 (closed).

I'm removing dependence on the hardcoded btaggingLink that we use to navigate from xAOD::Jet to xAOD::BTagging. This is necessary if we ever want to support multiple BTagging objects on a single jet. It turns out to be pretty precarious too: we accessed btaggingLink (usually via xAOD::BTaggingUtilities::getBTagging(jet)) in a half-dozen places, and sometimes not in the most accessible ones.

To do this I had to add a few configuration options:

  • At top level we need to specify btagging_link so that the jets know what object to read
  • At the level of every tracks structure, we need to specify the btagging_link as well. Here an empty string means we take the tracks directly from the jet.

There are still a few places where we use xAOD::BTaggingUtilities::getBTagging(jet), which we should probably follow up on #35 (closed). The most notable one is in TrackVertexDecorator, hopefully @svanstro can take a look at that when he has time. I don't think making arbitrary links work everywhere has to happen right away. But to make sure it works, I also added the ca-dump-minimal-btag script / CI test.

There were a lot of other little changes along the way to clean stuff up:

  • Make sure the ca-* scripts return a failure code when they fail! This was a bug in our CI.
  • Shallow copying b-jets: Add an integer to the names we give shallow copies in TStore. This is sort of a cheap "hash" to make sure calling this function multiple times in one event doesn't cause a clash.
  • Remove some default variables from internal functions in the jet writer: having defaults seemed error prone, better to make the compiler check that all inputs are specified (in this case).
  • Add a bit of structure to the track selector configuration, by putting all the cuts in one struct.
Edited by Dan Guest

Merge request reports