LorenzVectorBase interfaces

[graeme-a-stewart]

For the two main jet types used in the package, implement LorenzVectorBase interfaces by declaring them to be PxPyPzE four vectors.

Delegate most of the jet property accessors to the LorenzVectorBase implementations, with some "fixup" for phi, rapidity and pseudorapidity:

• phi, change the angle range to be [0, 2π)
• rapidity and pseudorapidity, clamp values to those previously used (basically, _MaxRap)
  This ensures compatibility with previous results from the package.

Improve documentation for those specific accessors which use cached values from our own jets (being more type specialised, these are chosen over the accessors for abstract FourMomentum types).

Implement constructors for PseudoJet and EEJet from any types that also implement LorenzVectorBase interfaces. Drop the old generic constructors that used JetReconstruction.{px,py,pz,energy}() methods - the common LorenzVectorBase interface is the way to go now.

Add tests for LorenzVectorBase interface constructors as well as LorenzVector and LorenzVectorCyl.

Update documentation on supported types for the reconstruction methods.

Rename CommonJetStructs.jl to CommonJet.jl as it contains far more than just struct definitions now.

Fix an inconsistency in the construction of (EEJet, PseudoJet) from (PseudoJet, EEJet) (allowing cluster_hist_index to be optionally set explicitly).

Closes #77

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.07%. Comparing base (3838eb2) to head (2bcbf81).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #223      +/-   ##
==========================================
+ Coverage   81.56%   82.07%   +0.50%     
==========================================
  Files          21       21              
  Lines        1405     1400       -5     
==========================================
+ Hits         1146     1149       +3     
+ Misses        259      251       -8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mmikhasenko]

I have not worked with the package yet.
I've looked over the files and have not noticed anything critical to comment.
Most of changes are clear and related to using LorentzVectorBase interface.

Logic related to cluster_hist_index was not very clear to me.
Is it needed to create PseudoJet. In the previous version, there was a constructor without index. Now, index assumed to be 0 if not passed.

[graeme-a-stewart]

Thank you for looking over @mmikhasenko. I had missed that bare identifiers imply the keyword name.

The reason that cluster_hist_index became more explicit is that we changed the jet structs to be immutable, which is a bit faster in normal Julia and also improves life for juliac.

[m-fila]

I see a small caveat that EEJet and PseudoJet when called in generic code through LorentzVectorBase interface doesn't make use of the values cached in field, e.g LorentzVectorBase.pt2(pseudojet) calculates pt2 rather than using _pt2 field of PseudoJet.
This also creates an opportunity for mistakes if functions from JetReconstruction ever desynchronize with their counterparts from LorentzVectorBase

BTW, is PseudoJet._inv_pt2 used anywhere??

[graeme-a-stewart]

Thanks for the comment @m-fila. Yes, there is a risk of desynchronisation, but I think it's small. There's probably a case for some internal refactoring to avoid "aliases" and to use LorentzVectorBase functions directly when needed.

For EEJet and PseudoJet you are correct, if the wrong module is used then the non-caching method is called. This can be fixed by providing type specific methods for LorentzVectorBase. I think it's still better to have pt2(::FourVector) call LorentzVectorBase.pt2() as there is no guarantee that all FourVector types would cache this.

AFAICS you are right about _inv_pt2, it isn't used - the important $k_T$ variable is always calculated as $p_T^{2p}$.