refactor!: Remove now-obsolete property skipZMiddleBinSearch
#2835
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
|
Is this ready to review @CarloVarni? |
|
forgot to ping you @paulgessinger . This is ready for review |
This was referenced Jan 8, 2024
|
FYI this PR is marked as a breaking PR since it removes a configuration property from the seeding. However, Athena is not complaining since this configuration property is only used for Fast tracking, and we do not have yet an Athena-ACTS configuration for that. |
paulgessinger
approved these changes
Jan 15, 2024
acts-project-service
added
the
Fails Athena tests
kodiakhq bot
pushed a commit
that referenced
this pull request
Jan 16, 2024
This will complete the adaptation of the grid to an N-dimentional case. The user is now able to iterate on any axis as they like without the need to rotate their geometry.
Next step is to see how the seed finding routine can be adapted to be more general
This PR is also a bug-fix since in the past we had:
```cpp
template <typename external_spacepoint_t>
boost::container::small_vector<std::size_t, 9>
Acts::BinFinder<external_spacepoint_t>::findBins(
std::size_t phiBin, std::size_t zBin,
const Acts::SpacePointGrid<external_spacepoint_t>* binnedSP) const {
// if zBinNeighbors is not defined, get the indices using
// neighborHoodIndices
if (m_zBinNeighbors->empty()) {
return binnedSP->neighborHoodIndices({phiBin, zBin}).collect();
}
// if the zBinNeighbors is defined, get the indices from there
std::array<std::pair<int, int>, 2> sizePerAxis;
sizePerAxis.at(0) = std::make_pair(-m_numPhiNeighbors, m_numPhiNeighbors);
sizePerAxis.at(1) = (*m_zBinNeighbors)[zBin - 1];
return binnedSP->neighborHoodIndices({phiBin, zBin}, sizePerAxis).collect();
}
```
In the case `m_zBinNeighbors` is empty, the code is instructed to search neighbours in the range `{-1, 1}` FOR EVERY AXIS (this is what `binnedSP->neighborHoodIndices({phiBin, zBin}).collect();` does), thus overwriting the value set by the user for `m_numPhiNeighbors`.
Now, the axes are treated independently
This requires: #2835
kodiakhq bot
pushed a commit
that referenced
this pull request
Jan 18, 2024
A general class for defining a `BinnedGroup`. This class stores a `grid` (owns it), two `GridBinFinders` and a navigation pattern, optionally defined by the user. The PR also defines its iterator. This will replace the current `BinnedSPGroup` implementation, which is very specific. Also, creating and filling a grid cannot be generalized imho: variable definitions, selection cuts, number of axes and their ordering. As such, the creation and the filling of the grid are now handled externally, and not inside the `BinnedGroup` class, and it's the user's duty to make sure the filling happens. In my mind, all of this should be handled by the user for any custom way of doing it. One thing we can provide (as we currently do but I'm afraid is more a "nice consequence" then a "design") some pre-defined grids for specific geometries. For instance we can define a `CylindricalSpacePointGrid<external_spacepoint_t>` (as well as `CylindricalBinnedGroup<external_spacepoint_t>`) or a `TelescopeSpacePointGrid<external_spacepoint_t>` (and its `TelescopeBinnedGroup<external_spacepoint_t>`). These last points are not covered here, will be addressed in another PR once this one is in. My idea is to define these "specialization" as simple `typedef`s of the above generic classes, as well as defining functions for their creation and filling. This can be located inside a new `Acts/Seeding/detail` folder, so we can add as many specializations as possible. Requires: - #2838 - #2835 - #2839 (maybe optional?)
kodiakhq bot
pushed a commit
that referenced
this pull request
Jan 19, 2024
Follow up from #2854 In this PR I am defining a grid geometry for a cylindrical experiment with (phi, z) bins. This is done in a specific file that is included in the GridSpacePoint file. Other specializations can then be easily added in the same fashion (e.g. a pre-defined grid for telescope geometry). Requires: - #2838 - #2854 - #2835
paulgessinger
removed
the
Fails Athena tests
LaraCalic
pushed a commit
to LaraCalic/acts
that referenced
this pull request
Feb 10, 2024
…project#2835) This needs acts-project#2718 to be in. As quoted there: The grid iterator will be able to iterate on whatever sequence of bins you like. In other words... for a usual seed finding process we have: `zBinsCustomLooping = [1, 2, 3, 4, 11, 10, 9, 8, 6, 5, 7]` but for fast tracking you can simply provide a shorter vector. For instance: `zBinsCustomLooping = [11, 10, 9, 8, 6, 5, 7]` much simpler imho.
LaraCalic
pushed a commit
to LaraCalic/acts
that referenced
this pull request
Feb 10, 2024
This will complete the adaptation of the grid to an N-dimentional case. The user is now able to iterate on any axis as they like without the need to rotate their geometry.
Next step is to see how the seed finding routine can be adapted to be more general
This PR is also a bug-fix since in the past we had:
```cpp
template <typename external_spacepoint_t>
boost::container::small_vector<std::size_t, 9>
Acts::BinFinder<external_spacepoint_t>::findBins(
std::size_t phiBin, std::size_t zBin,
const Acts::SpacePointGrid<external_spacepoint_t>* binnedSP) const {
// if zBinNeighbors is not defined, get the indices using
// neighborHoodIndices
if (m_zBinNeighbors->empty()) {
return binnedSP->neighborHoodIndices({phiBin, zBin}).collect();
}
// if the zBinNeighbors is defined, get the indices from there
std::array<std::pair<int, int>, 2> sizePerAxis;
sizePerAxis.at(0) = std::make_pair(-m_numPhiNeighbors, m_numPhiNeighbors);
sizePerAxis.at(1) = (*m_zBinNeighbors)[zBin - 1];
return binnedSP->neighborHoodIndices({phiBin, zBin}, sizePerAxis).collect();
}
```
In the case `m_zBinNeighbors` is empty, the code is instructed to search neighbours in the range `{-1, 1}` FOR EVERY AXIS (this is what `binnedSP->neighborHoodIndices({phiBin, zBin}).collect();` does), thus overwriting the value set by the user for `m_numPhiNeighbors`.
Now, the axes are treated independently
This requires: acts-project#2835
LaraCalic
pushed a commit
to LaraCalic/acts
that referenced
this pull request
Feb 10, 2024
A general class for defining a `BinnedGroup`. This class stores a `grid` (owns it), two `GridBinFinders` and a navigation pattern, optionally defined by the user. The PR also defines its iterator. This will replace the current `BinnedSPGroup` implementation, which is very specific. Also, creating and filling a grid cannot be generalized imho: variable definitions, selection cuts, number of axes and their ordering. As such, the creation and the filling of the grid are now handled externally, and not inside the `BinnedGroup` class, and it's the user's duty to make sure the filling happens. In my mind, all of this should be handled by the user for any custom way of doing it. One thing we can provide (as we currently do but I'm afraid is more a "nice consequence" then a "design") some pre-defined grids for specific geometries. For instance we can define a `CylindricalSpacePointGrid<external_spacepoint_t>` (as well as `CylindricalBinnedGroup<external_spacepoint_t>`) or a `TelescopeSpacePointGrid<external_spacepoint_t>` (and its `TelescopeBinnedGroup<external_spacepoint_t>`). These last points are not covered here, will be addressed in another PR once this one is in. My idea is to define these "specialization" as simple `typedef`s of the above generic classes, as well as defining functions for their creation and filling. This can be located inside a new `Acts/Seeding/detail` folder, so we can add as many specializations as possible. Requires: - acts-project#2838 - acts-project#2835 - acts-project#2839 (maybe optional?)
LaraCalic
pushed a commit
to LaraCalic/acts
that referenced
this pull request
Feb 10, 2024
…#2858) Follow up from acts-project#2854 In this PR I am defining a grid geometry for a cylindrical experiment with (phi, z) bins. This is done in a specific file that is included in the GridSpacePoint file. Other specializations can then be easily added in the same fashion (e.g. a pre-defined grid for telescope geometry). Requires: - acts-project#2838 - acts-project#2854 - acts-project#2835
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.
This needs #2718 to be in.
As quoted there: The grid iterator will be able to iterate on whatever sequence of bins you like.
In other words... for a usual seed finding process we have:
zBinsCustomLooping = [1, 2, 3, 4, 11, 10, 9, 8, 6, 5, 7]but for fast tracking you can simply provide a shorter vector. For instance:
zBinsCustomLooping = [11, 10, 9, 8, 6, 5, 7]much simpler imho.