Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: use grid for surface ordering #21

Closed
asalzburger opened this issue Jan 27, 2021 · 7 comments
Closed

feat: use grid for surface ordering #21

asalzburger opened this issue Jan 27, 2021 · 7 comments
Assignees
Labels
enhancement New feature or request

Comments

@asalzburger
Copy link
Contributor

This feature is in preparation to describe full detectors with grid navigation. It will prepare this with small changes to the current tests:

Currently, in test_surfaces.hpp surfaces for a dummy cylinder barrel and/or endcap disc are generated using:

  • barrel: dtuple<darray<scalar, 2>, dvector<transform3>> barrel_description
  • endcap: dtuple<darray<scalar, 3>, dvector<transform3>> endcap_description

In a first step, expand the two methods to include also a suitable grid2 implementation, which is created with the correct indices of the surfaces in either barrel or endcap:

  • barrel: rphi, z
  • endcap: r, phi

Then, write a test, where you check the bin contains the best surface and with a zone check around (the grid should allow you to not only get the index of the bin, but a defined zone around).

@asalzburger asalzburger added the enhancement New feature or request label Jan 28, 2021
@niermann999
Copy link
Contributor

So in the end the functions should return the grids instead of the vector tuples? Should this at some point become a detector description structure used in conjunction with the allocated memory for the surfaces?

@asalzburger
Copy link
Contributor Author

asalzburger commented Jan 28, 2021

It should return:

bounds, transform, grid

Where the grid points to the index of the according transform.

@asalzburger
Copy link
Contributor Author

The overall goal is to change the surface finding in a volume from all (what is happening right now) to grid with a zone.

@niermann999
Copy link
Contributor

Ok, so the binning is not configurable, but should be found automatically from say the detector dimensions, the number of surfaces, and their sizes etc., right? The range for the neighbor search should be fixed?

@asalzburger
Copy link
Contributor Author

In test_surfaces.hpp you actually know the binning in rphi/z or r/phi, so you do not have to automatically detect it (also for the reading of a detector via csv/json we should rely on the binning to be known.

@asalzburger
Copy link
Contributor Author

Hi @niermann999 - I decided to work a bit more on this, and created #31 as a first detector, this introduces some grid structure for finding the surfaces in local proximity, seems to work for a start.

@asalzburger
Copy link
Contributor Author

This is fixed with #31 and some onwards PRs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants