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

Update pixel maps to D110 geometry #51

Open
VourMa opened this issue Jun 26, 2024 · 6 comments
Open

Update pixel maps to D110 geometry #51

VourMa opened this issue Jun 26, 2024 · 6 comments

Comments

@VourMa
Copy link
Collaborator

VourMa commented Jun 26, 2024

With cms-sw#45175, the default Phase 2 geometry has been moved to D110 = T35+C18+M11+I17+O9+F8.
T35 constitutes a significant change in the inner tracker geometry wrt. T32 that we were using before:

  • T35: Same as T33 with the exception of modified Tracker volume so that it touches CALO on the outer side and BeamPipe on the inner side
  • T33: Phase2 tilted tracker. Identical to T32 apart from a more realistic description of the 3D sensors in TBPX layer1.
  • T32: Phase2 tilted tracker. The tracker description is identical to T25. The outer radius of the tracker volume is reduced to avoid a clash with the BTL geometry (same as T31). The positions of the tracker components are not affected. This geometry is intended as a transition step towards a realistic configuration with 3D sensors in TBPX layer1.

As a result, I think that the pixel maps should be rederived for that geometry and tested, before we move to the new default.

@VourMa
Copy link
Collaborator Author

VourMa commented Jun 26, 2024

The conflict in cms-sw#45117 comes from the transition to the new default geometry. Should I resolve the conflict by leaving our workflow in the previously default geometry (D98) and deal with the transition in an upcoming PR?

@slava77
Copy link

slava77 commented Jun 26, 2024

The conflict in cms-sw#45117 comes from the transition to the new default geometry. Should I resolve the conflict by leaving our workflow in the previously default geometry (D98) and deal with the transition in an upcoming PR?

it would be more clear to discuss conflicts inline in #30

@slava77
Copy link

slava77 commented Jun 26, 2024

The conflict in cms-sw#45117 comes from the transition to the new default geometry. Should I resolve the conflict by leaving our workflow in the previously default geometry (D98) and deal with the transition in an upcoming PR?

I'm not sure I follow: in our PR umWFIB.extend([24834.703,24834.704]) #2026D98 is already D98

@slava77
Copy link

slava77 commented Jun 26, 2024

ah, OK, I see; the file was changed to a generic [prefixDet+
the only way that can work is if ±4 lines are identical

@ariostas
Copy link
Member

ariostas commented Jul 5, 2024

Is T35 supposed to appear here soon, or is it the same as T33? I was thinking of looking at this while also addressing SegmentLinking/TrackLooper#329 since that was brought up in the review.

@VourMa
Copy link
Collaborator Author

VourMa commented Jul 5, 2024

Is T35 supposed to appear here soon, or is it the same as T33? I was thinking of looking at this while also addressing SegmentLinking/TrackLooper#329 since that was brought up in the review.

Quoting the Configuration/Geometry/README.md:

T35: Same as T33 with the exception of modified Tracker volume so that it touches CALO on the outer side and BeamPipe on the inner side.

I don't think this is a change in the actual layout, so T33 should be ok to look at at this level.

The problem is that D98 = T32+C17+M10+I16+O9+F8 and T32 -> T33 is a significant change for the IT.

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

No branches or pull requests

3 participants