Support retrieval of jet constituents

[graeme-a-stewart]

For substructure studies, it's necessary to go from a final jet back to its constituent clusters.

For this, we need to (internally) map from the jet's index, through the history vector, to find all of the original cluster particle indexes.

Then we should return these particles to the user.

One question is, however, how the user will find their selected "final" jets, and retain enough information to find the mapping into the cluster sequence to perform this operation. The history index of the jet index are essentially internal bookkeeping objects that shouldn't really be exposed.

[graeme-a-stewart]

Note on how FastJet does this - it works with Pseudo jet objects that keep a link to _cluster_hist_index, which is then their entry point.

Note that our current functions to retrieve exclusive_jets and inclusive_jets return LorentzVectorCyl, so more information is required in this case.

[graeme-a-stewart]

I thought about a few things here:

1. Change the return type of the selectors to (Vector{LorentzVectorCyl}, Vector{Int}), where the second part of the tuple returns the jet index

   • Downsides are that it changes a public API interface and managing the correspondence between the two pieces is involves rather clunky index aligning

2. Change the return type of the selectors to Dict(Int, LorentzVectorCyl)

   • This is better as the mapping is taken care of by key=>value. However, although the previous return type can be recovered by, e.g., values(exclusive_jets(...)) it still changes the API and to a non-trivial type

3. Make the return type a parameter of the function, changing the signature to, e.g.,
   inclusive_jets(clusterseq::ClusterSequence; ptmin = 0.0, T=LorentzVectorCyl)

   • This would allow specification of T=PseudoJet that would return objects that we can then get the constituents of; it doesn't change the default return type, so the API is preserved for current code

Clearly I am keener on 3 than the others, so I would implement this on a branch and let people test it out (or come up with better ideas!).

[graeme-a-stewart]

I also was thinking that perhaps users don't need jets to be (re)created for the constituents, but they want to know the indexes of the original clusters that went into the jets. They can then index into their original particle collection.