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
Changes to improve GE0 GEMSegments #31480
Conversation
GE0 is now controlled by a separate algorithm in GEMSegmentBuilder.
We want to use only one algorithm for the whole GEM (for now, need to study the different algorithms on the different subdetectors)
Also remove unused timing information, since the GEM detectors keep bunch crossing info (in theBX), not timing.
The code-checks are being triggered in jenkins. |
-code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-31480/18396
Code check has found code style and quality issues which could be resolved by applying following patch(s)
|
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-31480/18397
|
A new Pull Request was created by @watson-ij (Ian J. Watson) for master. It involves the following packages: DataFormats/GEMRecHit @perrotta, @civanch, @Dr15Jones, @makortel, @cvuosalo, @ianna, @mdhildreth, @cmsbuild, @kpedro88, @slava77, @jpata can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test |
The tests are being triggered in jenkins.
|
+1 The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic:
You can see more details here: |
Comparison job queued. |
The tests are being triggered in jenkins.
|
I'm convinced that it could be more conveniently migrated everywhere, thus avoiding type conversions back and forth from |
+1 |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
+upgrade |
+1 |
+1
|
This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @silviodonato, @dpiparo, @qliphy (and backports should be raised in the release meeting by the corresponding L2) |
# defaults for GE0SegAlgoRU | ||
RU_GE0 = cms.PSet( | ||
allowWideSegments = cms.bool(True), | ||
doCollisions = cms.bool(True), | ||
maxChi2Additional = cms.double(100.0), | ||
maxChi2Prune = cms.double(50), | ||
maxChi2GoodSeg = cms.double(50), | ||
maxPhiSeeds = cms.double(0.001096605744), #Assuming 384 strips | ||
maxPhiAdditional = cms.double(0.001096605744), #Assuming 384 strips | ||
maxETASeeds = cms.double(0.1), #Assuming 8 eta partitions | ||
maxTOFDiff = cms.double(25), | ||
requireCentralBX = cms.bool(True), #require that a majority of hits come from central BX | ||
minNumberOfHits = cms.uint32(4), | ||
maxNumberOfHits = cms.uint32(300), | ||
maxNumberOfHitsPerLayer = cms.uint32(100), | ||
) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did you add RU_GE0
in gemSegments_cfi.py
? This file should contain only the default values of gemSegments
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because this is the default for the RU algorithm, which is the default reconstruction for ME0. For GE0, we will have a student check the various segment algorithms and possibly add the option to change algorithm by station, so I wanted to have this here to make it easy for them to switch algorithms.
+1 |
PR description:
These changes allow GE0 GEMSegments in GEM to act the same as the current ME0Segment:
deltaPhi
to GEMSegments to match the ME0Segment@jshlee @dildick Since we are updating the GEMSegment with deltaPhi and therefore changing the GEMSegment interface anyway, I went ahead and removed the timing information from GEMSegments. The GEM only outputs bunch crossing information, and from what I've been told there's no plan to include timing, so I think this info is unused and not planned to be used in the future. Let me know if you prefer to reverse these changes.
PR validation:
I checked runTheMatrix 24821.0 (TenMuE) with the GE0Geometry in Geometry/GEMGeometry up to DIGI + GEM RecoHit/Segment reconstruction. Segments look to be made correctly, all stations (including GE0) are producing them with the current setup.
I also checked the GE0SegAlgRU produces segments, but we should compare the ME0Segments and GE0Segments produced later, once the whole pipeline is working.
if this PR is a backport please specify the original PR and why you need to backport that PR:
Before submitting your pull requests, make sure you followed this checklist: