Skip to content

Converting JetTrimming into a subclass of JetGroomer

Copied from MR 33615 -- explicitly not linking to avoid spamming people who were accidentally tagged.

=====

@delsart, I put together the new JetTrimming class you prepared with my JetGroomer, making the former a subclass of the latter. I think this way it ends up being quite neat, as for any given grooming method, one just has to define the per-jet operation, and configure a filter with the appropriate setup in initialize(). In fact even most of the per-jet operation is the same, it's only the decorations that need to be changed -- so in principle we could even think of moving even more into the JetGroomer class.

In the process, I also reworked PseudoJetTranslator to eliminate bare pointers -- we can work with references everywhere to make the memory management a mite more robust.

A few other minor changes:

  • Created a WriteHandleKey for the output pseudojets in JetGroomer and JetClusterer -- I think it is better to communicate this explicitly to the scheduler. This is autoconfigured, so initialize will print a warning if the user sets any value. Lastly, I changed the name of the container to be ToolName+"FinalPJ", because I think this will be more unique (I think the previous setup could clash if you had 2 jet collections built from the same merged PJ container).
  • Merging the various Read/WriteHandles, I thought UngroomedJets and ParentPseudoJets was a bit more explicit.

This was tested so far with JetRecAlgTestCfg.py, but we could stand to verify the results vs the older classes.

Merge request reports