The SISCone jet algorithm optimised for low particle multiplicities

• Memory requirements are negligible for low parton multiplicities, and no external files or other programs are needed.Source: PROGRAM SUMMARY · p. 2
• The program uses an infrared-safe cone algorithm to cluster particles into jets.Source: PROGRAM SUMMARY · p. 2
• The implementation is hard-coded for at most 64 particles on 64-bit machines but is recommended only up to 10 final state particles.Source: PROGRAM SUMMARY · p. 2
• O(µs) running time is typical for configurations with up to 5 final state particles.Source: PROGRAM SUMMARY · p. 2

• SISCone is a seedless infrared-safe cone algorithm [1–3], enabling reliable perturbative calculations and comparison between experiment and theory.Source: §1 · p. 3
• The reference algorithm scales as O(n2lnn) rather than the original O(n · 2n) method, making it suitable for large experimental particle multiplicities [2, 3].Source: §1 · p. 3
• In NNLO subtraction calculations, repeated SISCone clustering made the reference implementation’s CPU time comparable to matrix-element evaluation and slowed predictions.Source: §1 · p. 3
• The article reports C++ implementations for hadronic collisions and electron-positron annihilation, while retaining the reference syntax where possible.Source: §1 · pp. 3–4
• The implementation is optimized for few final-state particles, achieving up to a factor 70 improvement for two-particle configurations.Source: §1 · p. 4
• For configurations near one hundred particles, the reference implementation should be used; the crossover occurs around 10 final state particles.Source: §1 · p. 4

The SISCone jet algorithm

• The algorithm depends on R, f, npass, vmin, a distance measure, and three split–merge functions whose definitions distinguish the two collision geometries.Source: §2 · pp. 4–6
• The algorithm finds stable cones, collects them as protojets, iterates up to npass, then applies split–merge with f and vmin.Source: §2 · p. 4
• A stable cone has all included particles within distance R of its summed-momentum axis and all excluded particles outside R.Source: §2 · p. 5
• The split–merge procedure removes protojets below vmin, orders the remainder with vordering, and resolves overlaps using voverlap and f.Source: §2 · p. 5
• Overlapping protojets either split shared particles toward the nearer axis when voverlap(I ∩J) < fvoverlap(J), or merge when the inequality is reversed.Source: §2 · p. 5
• The cylindrical hadronic version uses rapidity and azimuth, with transverse-momentum-based threshold, ordering, and overlap functions; its ordering choice is infrared-safe and recommended from ref. [3].Source: §2 · p. 6
• The spherical electron-positron version uses the angle between particle and protojet momenta, with energy-based threshold and overlap functions.Source: §2 · p. 6

3 The implementation for low particle multiplicities

• For few particles, the implementation uses the O(n·2^n) stable-cone method because reducing sub-dominant costs matters more than asymptotic scaling.This approach is acceptable because the implementation is intended only for small n, unlike the O(n^2lnn) method optimized for roughly one hundred particles.Source: §3 · p. 7
• The implementation is templated over the user's four-vector class, avoiding data-copying overhead in fixed-order programs.A compatible four-vector class must provide the required standard methods, and an example class is included.Source: §3 · p. 7
• Jets are represented by unsigned-integer bit masks, supporting up to 64 particles on 64-bit machines and enabling fast bit operations.The practical recommendation is to switch earlier to the large-multiplicity implementation because the low-multiplicity version is intended for small configurations.Source: §3 · p. 7
• The spherical version replaces angular distances with y_i,J, a monotonic function of the angle that avoids trigonometric calls during distance evaluation.Normalized spatial three-vectors are precomputed, leaving only a square-root operation for normalization.Source: §3 · pp. 7–8
• The cylindrical version precomputes azimuthal angles and delays rapidity calculations, discarding some unstable cones using azimuthal distance alone.This avoids some expensive log and atan2 evaluations; an additional optimization uses transverse-momentum conservation when the total p⊥-sum is zero.Source: §3 · p. 8

4 How to use the program

• The implementation is header-only C++ code supplied through template classes for cylindrical and spherical SISCone clustering.No compilation or installation is required for the implementation itself; users include the relevant header files.Source: §4 · pp. 8–9
• Users initialize a jet finder with a maximum particle count and invoke compute_jets with particles, cone size R, overlap parameter f, pass limit, and threshold.The interface matches implementation [3], facilitating switching between implementations according to particle multiplicity.Source: §4 · pp. 10–11
• compute_jets returns the jet count, while final_jets stores each jet as an unsigned integer whose set bits identify constituent particles.This representation supports direct bitwise inspection of particle membership.Source: §4 · p. 11
• The optional total-p⊥-zero flag enables special optimizations for pure QCD events but should remain disabled for mixed QCD-electroweak events such as W+jets.The default value is false.Source: §4 · p. 11
• The example program initializes four particles, runs cylindrical clustering, and outputs three jets with particles 0 and 1 clustered together.The spherical example uses the same momenta and produces the same three-jet particle grouping, with the singleton jets listed in reversed order.Source: §4 · pp. 11–12
• Figure 1 compares the CPU-time ratio of implementation [3] to this implementation against the number of final-state particles, with the crossover between 9 and 10 particles.The comparison uses the cylindrical version.Source: Figure 1 · p. 13

Benchmark setup

• The implementations find exactly the same number of jets for all O(10^6) random events tested across particle multiplicities from 2 to 11.The comparison evaluates both implementations at each multiplicity.Source: §5 · p. 13

Cylindrical geometry

• For cylindrical geometry, this implementation is faster than the implementation of [3] for up to nine final-state particles, across comparisons involving 2–11 particles and O(10^6) random events.The absolute timings of both implementations are shown in Table 1.Source: §5 · p. 13, Table 1 · p. 14

Spherical geometry

• A speed-up factor of almost 70 at two particles and roughly 35 at three particles is obtained for the spherical version, which remains faster through 10 particles.The three-particle gain was essential for an NNLO three-jet-rate calculation because otherwise clustering would have outweighed matrix-element time.Source: §5 · p. 14, Table 2 · p. 14

Interpretation

• The spherical speed-up exceeds the cylindrical one because the spherical implementation avoids trigonometric evaluations in its main algorithm, while the cylindrical version uses log- and atan2-functions.The reference implementation behaves oppositely, performing better for cylindrical than spherical geometry.Source: §5 · p. 14

Scope

• The implementation is intended for theoretical fixed-order perturbative calculations, where the number of final-state particles is relatively low.Source: §6 · p. 14

Performance comparison

• The spherical-version performance comparison measures the CPU-time ratio between the reference and new implementations, with crossover between 10 and 11 particles.The blue line denotes a ratio of 1.Source: Figure 2 · p. 15, §6 · p. 15

Conclusions

• The implementation outperforms the reference implementation of [3] up to roughly nine final-state particles and can provide a speed-up factor of up to 70 at low multiplicity.For higher multiplicities, the reference implementation of [3] should be used.Source: Figure 2 · p. 15, §6 · p. 16