Skip to content

ATLJETMET-1642 Replace JetJvtEfficiency

Jon Burr requested to merge jburr/athena:JvtRewrite into main

The JetJvtEfficiency is rather overloaded and does too many different things at once. The idea here is to strip it apart into its individual pieces (JVT selection and JVT scale factor calculations). As the interface includes too much this means adding in a new IJvtEfficiencyTool.

Here, the JetJvtEfficiency uses the new tools internally, but should otherwise be largely unchanged. This hopefully means that this can be an unobtrusive change and other frameworks can switch to using the new tools without an immediate break. I'm marking this as draft as, even with this intention there are a lot of changes here and I haven't run the tests yet.

First a quick summary of the changes

  • Add a new IJvtEfficiencyTool interface class
  • Implement JVT, fJVT and NNJVT into their own selection and efficiency tools. Some code is shared between shared JvtSelectionToolBase and JvtEfficiencyToolBase classes.
  • Add a helper class NNJvtBinning to make it easier to read the NNJvt binnings in and out
  • Made the output RpT and NNJvt selections optional in the JetVertexNNTagger

A few notes

  • It would be better to not calculate the NNJvt selection in JetVertexNNTagger
  • Might even be good to calculate RpT in a separate jet moment tool which preceds the JetVertexNNTagger. This would simplify that tool a fair bit as well (and make it easier for it to obey the IJetUpdateJvt interface).
  • What is the purpose of the isJvtPU decorator used in the JetJvtEfficiency tool? It doesn't seem to be used anywhere
  • I've returned -1 rather than +1 when a scale factor is out of range. This is more in line with how other SF tools behave but I can imagine that we'd need to be careful about this if there are tools/algorithms which ignore the CorrectionCode returned
  • I implemented the three algorithms as different pairs of tools, rather than one central tool for selections and one for efficiencies. I'm not wedded to this approach but I do think it is cleaner as it means that there is no coupling between the JVT algorithms and, for example, when we come to remove support for Jvt it merely means removing that tool, rather than editing some larger object.

A few further TODO items after this MR

  • We need to deprecate JetJvtEfficiency. A good starting point would be to remove it from the main athena repo
  • The CP analysis algorithms should be updated too. I'm not sure if keeping the JvtEfficiencyAlg available as a deprecated legacy option might be better than replacing it entirely

Tagging @khoo, @mswiatlo, @miholzbo and @akong as people who had expressed an interest before.

Edited by Jon Burr

Merge request reports