FT3 Tiling: Stave Geometry#15339
Merged
njacazio merged 31 commits intoAliceO2Group:devfrom May 4, 2026
Merged
Conversation
… different module placement. Rewrite structure to be more granular and extendable. The old code remains for backward compatibility for now
…accordingly. Also simplify create_layout_scopingV3 function since the layout_type isn't needed.
…ement to remain within nominal radii. Also remove initial placement of sensor stack before calling fill_stave, moving to using y_start instead.
…wap based on direction
…, not just the first in the stack
…old geometry. Also rename material counts to 'volume' instead of 'sensor'. EDIT: Change TGeo layer thickness back to original. EDIT2: Change Middle layer disc usage to newly added segmentation.
… 20/04/26: Revert to newly added middle disc layer segmentation.
…get the structural support (in carbon) from the staves
…Also change kSensorsPerStack to a vector in which order of sensor stack height we will pad the staves.
… and move in correct direction when placing sensors later
…n staves that have full +Rout to -Rout coverage
… a different number of sensor stacks on the positive/negative side of the stave leading to garbage memory access. Fixed now.
…isualisation purposes
… to previous layout, to encapsulate the staves with face at local z=0 in air, we need to shift the staves and sensors locally since the mother volume is always around local z=0. Shift the layer volume by the same amount when adding it to get the right global position.
…ow means that the stave faces are not at local z=0 but instead at z=+-totalSensorMaterialThickness+0.1. Also fix global position bug since movement outwards is directional.
…tly use simple calculated values for stave placements, these are subject to change. Hence the existence of kSegmentedOTOnly
Cleanup following linting standards in O2
Collaborator
|
Hi @njacazio , @fcolamar , could you have a look at this pull request? @JustusRudolph has implemented a more realistic geometry for the tracker discs, including the carbon fiber staves and volumes at the sensor level. This is also the starting point for implementing the digitisation. Cheers, Marco. |
njacazio
approved these changes
May 4, 2026
Collaborator
|
Hi @marcovanleeuwen thanks, looking good. I enabled the tests then we merge! |
njacazio
approved these changes
May 4, 2026
scannito
pushed a commit
to scannito/AliceO2
that referenced
this pull request
May 8, 2026
* Add separate file for constants in FT3 module creation * Create modular design in similar fashion as before, but with slightly different module placement. Rewrite structure to be more granular and extendable. The old code remains for backward compatibility for now * Give new geometry creation an FT3Layout enum and change Layer&Module accordingly. Also simplify create_layout_scopingV3 function since the layout_type isn't needed. * Add functionality for the user to enforce a strict cut on module placement to remain within nominal radii. Also remove initial placement of sensor stack before calling fill_stave, moving to using y_start instead. * Make forward and backward directions mirrored, front and back faces swap based on direction * Add loop over all sensors in stack so all sensors are added to volume, not just the first in the stack * Add constants for hollow stave based geometry * Add carbon fiber material, functionality to toggle between stave and old geometry. Also rename material counts to 'volume' instead of 'sensor'. EDIT: Change TGeo layer thickness back to original. EDIT2: Change Middle layer disc usage to newly added segmentation. * Add full hollow stave geometry functionality * Make Stave layout the standard and remove old kSegmentedMarch26: EDIT 20/04/26: Revert to newly added middle disc layer segmentation. * Remove all instances of old slab geometry and work only with staves. * Remove all log(info) statements, except one which is changed to debug. * Don't create the separation layer for stave layout, since we already get the structural support (in carbon) from the staves * add bools for cutting staves and sensors on staves on nominal radii * merge two if statements with the same if * Add implementations for cutting staves and sensors on nominal radii. Also change kSensorsPerStack to a vector in which order of sensor stack height we will pad the staves. * Fix bug in default y range for staves & sensor placements * Bugfix: Stack correctly by using previous stack height in fill_stave, and move in correct direction when placing sensors later * Remove now stale info statements. TODO: let staves be cut as well on nominal radii * Add splitting of stave in case of strict inner cutoff * Add support to place either a stack gap or single sensor around y=0 in staves that have full +Rout to -Rout coverage * Bugfix: When starting sensor placement around the x-axis you can have a different number of sensor stacks on the positive/negative side of the stave leading to garbage memory access. Fixed now. * Add option to draw reference circles onto the layer -- strictly for visualisation purposes * remove stale info statements * Remove stale overlap argument, and add local offset in z. In contrast to previous layout, to encapsulate the staves with face at local z=0 in air, we need to shift the staves and sensors locally since the mother volume is always around local z=0. Shift the layer volume by the same amount when adding it to get the right global position. * Fix placement issue to get sensor materials inside the volume. This now means that the stave faces are not at local z=0 but instead at z=+-totalSensorMaterialThickness+0.1. Also fix global position bug since movement outwards is directional. * Add OT only segmentation and change defaults * Make stave geometry available with middle layer disks as well. Currently use simple calculated values for stave placements, these are subject to change. Hence the existence of kSegmentedOTOnly * Change default to stave segmentation for outer disks only * Please consider the following formatting changes --------- Co-authored-by: ALICE Action Bot <alibuild@cern.ch>
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
Implement a moderately intricate stave geometry with sensors glued on them. The setup is now fully modular and can very easily be changed with new constants/numbers inside
FT3ModuleConstants.h.This change also adds a few more cuts that the user can add in addition to the numbers given in the aforementioned constants file. It's possible to cut the sensor placement exactly at the nominal radii, or to let them stick out with the given values.
The default settings state that there we cut on the inner radius, and dictate only Stave geometry placement on the outer disks, where there have been more in depth studies on tiling.
Notably as well, this PR maintains full backward compatibility. Using
kSegmented, nothing changes from the previous iteration.To run with the new segmented stave layout set
layoutFT3tokSegmentedStave, and if you would like to only have staves in the OT while keeping the old segmentation in the ML, then run withkSegmentedStaveOTOnly