Generalised kT Algorithm for pp collisions #71
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add a new algorithm type, GenKt, which takes an arbitrary power value. For both strategies, add the algorithm named parameter to the argument list, allowing the use of algorithms where both must be specified. Add functions that will check the consistency of the power value and algorithm type, but also set them when one or other is not specified. Add a new list of algorithms where the power is arbitrary. Add unittests for the consistency checks.
Reconstruction mode of GenKt now supported, when the power value is not in [-1, 0, 1]. This is not often used, but it is a valid algorithm choice. For both concrete strategies and 'Best', the algorithm can now be specified directly. If the algorithm and the power are specified then these are checked to be consistent. If only one is specified then the other is set to the correct value. Note that for GenKt both are required! ClusterSeq is adapted to record both the algorithm and the power. Power is stored always as a Float to ensure type stability. The constructor now needs both power and algorithm passed to it (but this is an internal API). set_algorithm_power_consistency! is changed to get_algorithm_power_consistency, which returns a tuple of the consistent power/algorithm values (can't mutate primitive types).
Adapt the basic jetreco.jl script to allow specification of power and/or algorithm. These will be checked for consistency. Note that for GenKt both must be given!
Allow these to also be driven by p and/or algorithm from the command line
Add a few examples to the test cases
Fix the instrumented-jetrco.jl call to inclusive jets Use logging in jetreco-constituents.jl to avoid console logging during the test not going to /dev/null Add tests against the example scripts
Test against FastJet's output for p=1.5
Also move these tests to a separate script to avoid the main script from becoming too large
These are put to one side pending a restructuring to avoid trying GLMakie tests in the CI
|
There were non-trivial issues in running the examples tests, so these are put onto the backburner for now:
I currently have no insight into that one. The better plan is to restructure the examples to be able to run the subset which are CI friendly, thus move away from a monolithic |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add proper support for the generalised kT algorithm for pp collisions (i.e., operating in$(y, \phi)$ space).
Added a
JetAlgorithmtype for generalised kT, viz.GenKt.Strategies are restructured to be able to be driven by only the power, or the algorithm, or (for
GenKt) both. A new function,get_algorithm_power_consistencyis added that will return the "partner" of a (power/algorithm) given an (algorithm/power). If inconsistent input is given an exception is thrown.Documentation is updated explaining how to call with either
poralgorithm, or both forGenKt.ClusterSequence now stores the power value and the algorithm and has to be initialised with both. In addition the power is always stored as a
Float64.Examples are restructured to also be able to be driven by power, or algorithm, or both. However, if neither is given then the scripts will use
AntiKtand print a warning. There is also now a clearer separation between calling the jet reconstruction itself and getting the inclusive/exclusive constituents.A test to compare Generalised kT output with FastJet for the case
p=1.5is added.Tests are also added to run our code examples, to check none of these break (at least for the standalone Julia scripts).
Misc
_tiled_jet_reconstruct) to ensure that power and algorithm are handled properly in the public interface (tiled_jet_reconstruct).Closes #49