refactor: updates for new PDU geometry #83
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
13 tasks
c-dilks
changed the title
7 tasks
Closed
wdconinc
pushed a commit
to eic/EICrecon
that referenced
this pull request
Aug 29, 2023
### Briefly, what does this PR introduce? Updates respecting eic/epic#331 - `richgeo`: - use DD4hep `VariantParameters` to streamline access to sensor positioning and orientation - various updates respecting eic/epic#331 - tests of sensor positioning and orientation are moved to `epic` with that PR - respect the readout field change: `module` -> `pdu` and `sipm` - method `richgeo::ReadoutGeo::PixelGapMask` was cut and pasted from `PhotoMultiplierHitDigi` - `PhotoMultiplierHitDigi`: - move pixel gap (mask) cuts to `richgeo` service in `ReadoutGeo` - delete config parameter `PhotoMultiplierHitDigiConfig::pixelSize`, since it can be obtained from `richgeo` ### What kind of change does this PR introduce? - [ ] Bug fix (issue #__) - [x] New feature (issue #__) - [ ] Documentation update - [x] Other: refactor ### Please check if this PR fulfills the following: - [ ] Tests for the changes have been added - [ ] Documentation has been added / updated - [x] Changes have been communicated to collaborators ### Does this PR introduce breaking changes? What changes might users need to make to their code? yes: this PR should be merged at the same time as - eic/epic#331 - eic/drich-dev#83 ### Does this PR change default behavior? not really, benchmarks appear to be the same --------- Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
wdconinc
added a commit
to eic/epic
that referenced
this pull request
Aug 29, 2023
### Briefly, what does this PR introduce? This is a big change for the dRICH sensor geometry. It was initially started by @JunhuaiXu and continued by @c-dilks with the advice of Marco Contalbrigo, et al. #### Summary of changes: - adjust some thicknesses, such as vessel walls and acrylic filter - refactor of the sensor geometry (which on `main` is just a thin `Box` for each SiPM) - add the resin backing, following [the S13361-3050NE-08 SiPM datasheet](https://www.hamamatsu.com/eu/en/product/optical-sensors/mppc/mppc_mppc-array/S13361-3050NE-08.html); the photosensitive volume plus the resin backing forms a "SiPM assembly" - make a 2x2 matrix of SiPM assemblies, forming a Photodetector Unit (PDU); include service materials behind each 2x2 matrix forming the full PDU assembly - `frontservices`, currently just a box - `boards`: 5 circuit boards, coming out of the `frontservices` box - `backservices`, currently just another box - all of these are made of Aluminum, for now - The spherical tiling algorithm now tiles PDU assemblies, instead of the original SiPM `Box`es - Change the readout bit fields, so sensors are identified by a PDU number `pdu` and a SiPM number (0-3) `sipm`, instead of just a single `module` number - Extrude the annular region of the vessel (the part outside the aerogel snout) toward the -z direction, to allow the sensor services to fit; this is a step toward modelling sensor boxes, which will house each sector's set of PDUs (outside the scope of this PR) #### Pictures and Geometry details: See `sensors.pdf` from <https://indico.bnl.gov/event/19848/> --- ### What kind of change does this PR introduce? - [ ] Bug fix (issue #__) - [X] New feature, closing the following: - close #111 - close #175 - close #333 - close #328 - [ ] Documentation update - [ ] Other: __ --- ### Please check if this PR fulfills the following: - [x] Tests for the changes have been added - [X] Documentation has been added / updated - [x] Changes have been communicated to collaborators --- ### Does this PR introduce breaking changes? What changes might users need to make to their code? **YES**, addressed by these PRs; all of them should be merged simultaneously: - eic/EICrecon#727 - eic/drich-dev#83 #### Things to check downstream: - [x] pixel gap cuts - [x] event display and readout - [x] are the photons stopped by the resin, or do they still penetrate through? - [x] sensor thickness and IRT geometry conversion - [x] number of photons / interaction of photons at the resin/sensor/air surface - [x] PID --- ### Does this PR change default behavior? yes, photons will stop within the resin volume (currently on `main` they pass through and stop at the vessel wall behind the sensors); this should also prevent photons causing hits from behind (unlikely, but can happen) and from the sensor sides (because of the resin walls) --------- Co-authored-by: Christopher Dilks <[email protected]> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> Co-authored-by: Christopher Dilks <[email protected]> Co-authored-by: Wouter Deconinck <[email protected]>
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.
Briefly, what does this PR introduce?
Updates respecting eic/epic#331
What kind of change does this PR introduce?
Please check if this PR fulfills the following:
Does this PR introduce breaking changes? What changes might users need to make to their code?
no
Does this PR change default behavior?
no