-
Notifications
You must be signed in to change notification settings - Fork 13
Description
We should define what the public interfaces are to the package. At the moment we have:
Input
N2Plain
Defaults to a collection of arbitrary objects, where px, py, pz, energy are defined for each object (in JetReconstruction, i.e., JetReconstruction.px(T)) to extract the relevant 4-vector parameters.
I like that, but the default used in Particle.jl is a little bit hokey for my taste as the index numbers are mapped to each quantity in a magic number kind of way.
N2Tiled
A collection of PseudoJet structs.
The thing I dislike currently is that the struct has an implementation specific parameter, viz. _cluster_hist_index. It's also rather close to LorentzVectorHEP, albeit that circular parameters are cached (not sure if we need that).
Proposal
Standardise to accept input particles as a collection of LorentzVectors, used via the LorentzVectorHEP package, which provides the appropriate px, py, pz, energy definitions already. This also achieves #5.
- I still like the idea of documenting for type
Tthe idea of definingJetReconstruction.px{T}, etc. that provides a clear way for users to use their own types with the package.
Internal Use
It is probably optimal that each algorithm uses an internal EDM when users pass arbitrary types, as these can be tuned for internal efficiency (e.g., the N2Tiled method can keep using its current PseudoJet).
Output
N2Plain returns the same type of jet objects that it was given as input. N2Tiled returns its own PseudoJet objects.
Also the sequences are different, with N2Tiled returning a FastJet-like clusterisation history and N2Plain a vector of ints, giving the merging index sequence for each input particle (and intermediates).
N2Tiled also filters on
I am really not sure what's best here - uniformly return something like LorentzVectorCyl, which gives