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
JetGroomerandJetClusterer-- I think it is better to communicate this explicitly to the scheduler. This is autoconfigured, soinitializewill print a warning if the user sets any value. Lastly, I changed the name of the container to beToolName+"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
UngroomedJetsandParentPseudoJetswas a bit more explicit.
This was tested so far with JetRecAlgTestCfg.py, but we could stand to verify the results vs the older classes.