How to handle jet groomers/transformers in fastjet

[jmduarte]

Starting a discussion about how to handle jet groomers/transformers in fastjet.

If you look at the FastJet manual: https://fastjet.fr/repo/fastjet-doc-3.4.0.pdf (Section 9), you'll see there's a general class of functions that transform a jet, i.e. they take as input a jet (as a list of constituents), modify those constituents in some way (typically removing some), and return the modified list of jet constituents. In C++ code, MyTransformer inherits from fastjet::Transformers and you can use it as such:

MyTransformer transformer;
PseudoJet transformed_jet = transformer(jet);

Basically, all jet groomers fall under this category (pruning, trimming, mass drop, modified mass drop, soft drop, etc.), inherit from the fastjet::Transformers class, and are either included in standard FastJet (and thus should have SWIG bindings) or FastJet Contrib (and thus don't have SWIG bindings).

My thought is it would be nice if we could do something similar on the Python side:

transformer = fastjet.MyTransformer()
transformed_jets = transformer(jets)

where ideally jets can be a multi-event or single-event awkward array of jets constituents after being clustered.

Is this feasible? What do others think?

To start with, here's a list of some transformers we could support found either in FastJet (https://gitlab.com/fastjet/fastjet) or in FastJet Contrib (https://github.com/cms-externals/fastjet-contrib/tree/cms/v1.044):

fastjet::Filter
fastjet::Pruner
fastjet::MassDropTagger
fastjet::contrib::ModifiedMassDropTagger
fastjet::contrib::SoftDrop

[raymondEhlers]

Hi!

To add a comment from the heavy ion perspective, there's interest here from some folks within ALICE (unfortunately, I'm just dropping in this comment since I don't have time to contribute at the moment). In particular, there's another class of transformers which are used for background subtraction (eg. Subtractor in fastjet, Constituent Subtraction in fj-contrib). They're generally fastjet::Transformer derived classes taking vector -> vector, so they should (roughly) fit the transform pattern, although there is sometimes additional functionality (for example, in CS for what's known as event-wise subtraction). They would also need bindings for the BackgroundEstiatmor classes.

You'll have to decide if these are in scope or not for this discussion, but it's something to keep in mind for your design. (As it stands, I can't yet use these bindings since I have my own private bindings with additional functionality which predate these bindings, and I can't take the time to add it in and switch over right now. However, I would be excited if I was able to do so, and this would be a good step in that direction!)

[lgray]

Since a lot of this top level functionality for configuration is handled by swig the object creation itself is easy.
What's needed is a function that does xformed = fastjet.apply_transformation(transformer, jets), but it looks like the way you invoke each tagger is a little different, so may need some slightly specialized implementation in each case.

Writing the function that deals with building awkward / numpy arrays should be pretty generic though.

[lgray]

So long as they all inherit from a that base class and we can wrap a single point of entry in all cases, this should be something we can turn into a consistent columnar interface. I've got some other things on my plate (dask/coffea stuff) but could try my hand, it would not be that hard IMHO.