Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat: Implement a new orthogonal range search seed finder (#904)
As I said in #901, I have been playing around with seed finding a little bit lately. Last weekend, I mentioned an idea for a new (?) kind of seed finding algorithm based on range search datastructures, and this is the very, very first semi-working implementation of it, just before the weekend. The idea behind this algorithm is relatively simple. In traditional seedfinding, we check a whole lot of candidate spacepoints to see whether they meet some condition. If you look at this differently, each spacepoint defines a volume in the z-r-φ space, which contains any spacepoints it can form a doublet with. What if we reversed this logic? What if we defined this volume first, and then just extract the spacepoints inside of that space? That way, we can vastly reduce the number of spacepoints we need to look at. How do we do this quickly? With [_k_-d trees](https://en.wikipedia.org/wiki/K-d_tree). These data structures are cheap to build, and they give us very fast orthogonal range searches. In other words, we can very quickly look up which of our spacepoints lie within an axis-aligned orthognal n-dimensional hyperrectangle. In this case, which spacepoints lie within a z-r-φ box. So, the core idea of this seedfinder is to define as many of our seedfinding constraints in orthogonal fashion. That way, we can make our candidate hyperrectangle smaller and smaller. The tighter the constraints we can place, the better. Then, we look up the relevant spacepoints, and we can avoid looking at any others. That also means this solution requires no binning whatsoever. ## Constraint conversion Currently there are quite a few constraints in the code. Here is my status update on how well it is going to convert each of them. In some cases, we can define a weaker version of the constraints in orthogonal fashion. This is still very powerful, and it doesn't actually lose us any efficiency (because we can always check the tighter constraint in a non-orthogonal way later, not a problem)! ### Unary constraints Currently, I am not aware of any unary constraints in the Acts seed finding code. That is to say, logic to determine whether a point is allowed to be a lower spacepoint. However, I have the following thoughts about introducing some: * I believe the binning code does some kind of magic to determine whether a spacepoint can be a lower spacepoint. Since my solution doesn't use any binning, I don't have access to this just yet. However, if we can incorporate this logic it could be very powerful. * Maximum single-point η: we currently have some checks in place to see if the pseudorapidity of particles is not too high. We could realistically use this maximum pseudorapidity, combined with the collision region range to constrain the bottom spacepoints. ### Binary constraints These are the existing binary constraints on spacepoint duplets: Constraint | Description | Orthogonalization -|-|- Minimum ∆r | Ensure that the second spacepoint is within a certain difference in radius | Full Maximum cot θ | Ensure that the pseudorapidity of the duplet is not too high | Unsuccessful z-origin range | Ensure that the duplet would have originated from the collision point | Weakened Maximum ∆φ<sup>1</sup> | Ensure that the duplet does not bend too much in the x-y plane | Full <sup>1</sup> This check does not exist explicitly in the existing seed finder, but is implicit in the binning process. ### Ternary constraints There are a lot of ternary constraints (to check whether a triplet is valid): Constraint | Description | Orthogonalization -|-|- Scattering angle | ??? | Unsuccessful Helix diameter | Ensure the helix diameter is within some range | In progress Impact parameters | Ensure the impact parameters are close to the collision point | In progress Monotonic z<sup>1</sup> | Ensure that z increases or decreases monotonically between points | Full <sup>1</sup> This check does not exist in the existing seed finder, check #901. There are also constraints defined in the experiment-specific cuts, and the seed filter, and in other places. If we could convert some of those to orthogonal constraints the implementation would become much more powerful. However, I don't really understand what is happening in those files just yet. Need more reading. ## Current performance The current performance of this seedfinder is... Complicated. On my machine, it runs a 4000 π<sup>+</sup> event in about 5 seconds, three times slower than the existing seedfinder. Its efficiency is much higher though, and the fake rate is much lower. So that's something. However, that is in part because I am creating far more seed candidates, so take this with a big grain of salt. ## Potential gain There are two ways that I can think of to use this kind of algorithm. The first is an inside-to-outside algorithm, where we pick a lower spacepoint first, check the space it defines for a middle spacepoint, and then check the space the two of them define for a third spacepoint. This algorithm has time complexity 𝒪(_n_<sup>3</sup>), and it has space complexity 𝒪(_n_). Due to the constants, I still believe this implementation can outperform the 𝒪(_n_<sup>2</sup>) existing algorithm, however. The second way would be to construct a set of duplets using this logic, and then to fit those together like we do with traditional seedfinding. This has 𝒪(_n_<sup>2</sup>) time complexity like the existing code, but also space complexity 𝒪(_n_<sup>2</sup>). ## Things that are completed * The implementation of the _k_-d tree seems to work very well, and it is quite fast. * Basic seedfinding using this strategy is functional. ## Things that don't work yet * My maximum ∆φ constraint does not cross the 2π boundary yet. * I used the existing seedfinding algorithm as a stepping stone, which I have completely destroyed in the process. Obviously I do not intend on keeping it that way, and the existing algorithm will be restored to its full glory. * Lots more. ## Things that can be improved * Add more constraints, and tighten existing ones. * Lots of things, pretty much everything. But I really want to go home for the weekend, so I will write this part next week.
- Loading branch information