New pixel RecHit infrastructure for FastSim (for Phases 0, 1, 2, and beyond), backport of ##23799 for 94X #24764
Conversation
…or Phases 0, 1, 2, and beyond))
cmsbuild
added
alca-pending
analysis-pending
code-checks-pending
comparison-pending
core-pending
daq-pending
db-pending
dqm-pending
fastsim-pending
generators-pending
geometry-pending
hlt-pending
l1-pending
new-package-pending
operations-pending
orp-pending
pdmv-pending
pending-signatures
reconstruction-pending
simulation-pending
tests-pending
upgrade-pending
visualization-pending
labels
|
The code-checks are being triggered in jenkins. |
|
@kpedro88, any thoughts on this? I started from your recipe (thanks!), patched it locally, ran test jobs and everything was fine. This is now well above my git ability. |
|
BTW, I can just start from scratch and copy the files by hand (since now we know what they need to be for 94X, as the merging has been done!). But that would seem very un git-ty. |
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-24764/6707 |
|
The tests are being triggered in jenkins. |
|
@pmaksim1 , looks ok now |
|
Comparison job queued. |
|
Comparison is ready Comparison Summary:
|
|
+1 |
|
This pull request is fully signed and it will be integrated in one of the next CMSSW_9_4_X IBs (tests are also fine) and once validation in the development release cycle CMSSW_10_3_X is complete. This pull request will now be reviewed by the release team before it's merged. @davidlange6, @slava77, @smuzaffar, @fabiocos (and backports should be raised in the release meeting by the corresponding L2) |
|
+1 differences are mostly concentrated in FS workflows, apart for spurious PixelPhase1 differences. Differences in the backport wrt to master are justified by unrelated code changes. |
This is a backport of the new pixel RecHit infrastructure (#23799) for 94X. It contains:
pixel RecHit smearing code has been completely rewritten, in order to make it more maintainable, and extensible to other geometries. (The old code assumed a lot of things about the Phase 0 geometry, whereas the new code pushes all physics / geometry issues to pixel template object and the resolution histograms.)
the pixel resolution histograms are now separated for each type of pixel RecHit (regular vs cluster-on-edge vs cluster-with-big-pixel) as well as for each DetUnit with a specific orientation of local B field (since that determines the drift). Thus, a pixel template matches each pixel resolution histogram file. [This is very important for Phase 1 Forward, since the blades are tilted about both axes, and thus the angles are different from Phase 0 geometry.]
pixel templates are loaded from the DB.
the current code is essentially completely generic, and will work for Phase2 as well. (Provided that the proper resolution files are provided.)
Note that the hit merging is still off. Its effects have not been studied well enough to turn it on at this time.