FT3 Tiling: Stave Geometry#15339
Open
JustusRudolph wants to merge 29 commits intoAliceO2Group:devfrom
Open
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
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
1 participant
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.