SegmentLinking / cmssw

CMS Offline Software
http://cms-sw.github.io/
Apache License 2.0
1 stars 1 forks source link

Update pixel maps to D110 geometry #51

Open VourMa opened 3 days ago

VourMa commented 3 days ago

With cms-sw/cmssw#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 commented 3 days ago

The conflict in cms-sw/cmssw#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 commented 2 days ago

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 commented 2 days ago

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 commented 2 days ago

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