You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 T the idea of defining JetReconstruction.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 $p_{Tmin}$ and N2Plain doesn't.
I am really not sure what's best here - uniformly return something like LorentzVectorCyl, which gives $(p_T, \eta, \phi)$ coordinates?
The text was updated successfully, but these errors were encountered:
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 (inJetReconstruction
, 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 toLorentzVectorHEP
, albeit that circular parameters are cached (not sure if we need that).Proposal
Standardise to accept input particles as a collection of
LorentzVector
s, used via theLorentzVectorHEP
package, which provides the appropriatepx
,py
,pz
,energy
definitions already. This also achieves #5.T
the 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$p_{Tmin}$ and N2Plain doesn't.
I am really not sure what's best here - uniformly return something like$(p_T, \eta, \phi)$ coordinates?
LorentzVectorCyl
, which givesThe text was updated successfully, but these errors were encountered: