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

Changes to improve GE0 GEMSegments #31480

Merged
merged 13 commits into from Sep 25, 2020
Merged

Conversation

watson-ij
Copy link
Contributor

PR description:

These changes allow GE0 GEMSegments in GEM to act the same as the current ME0Segment:

  • Add deltaPhi to GEMSegments to match the ME0Segment
  • Copied the deltaPhi calculator to GEMSuperChamber from ME0Chamber (which is actually the equivalent of GEMSuperChamber)
  • Adapted ME0SegAlgRU to GE0SegAlgRU so the RU segment finder can run from GEM RecHits (for now, keep default GEMSegmentBuilder, but we may later want to switch to GE0SegAlgRU, or split the algorithm used for GE0 and GE[12]/1)

@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:

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.
@cmsbuild
Copy link
Contributor

The code-checks are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

-code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-31480/18396

  • This PR adds an extra 40KB to repository

Code check has found code style and quality issues which could be resolved by applying following patch(s)

@cmsbuild
Copy link
Contributor

The code-checks are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-31480/18397

  • This PR adds an extra 40KB to repository

@cmsbuild
Copy link
Contributor

A new Pull Request was created by @watson-ij (Ian J. Watson) for master.

It involves the following packages:

DataFormats/GEMRecHit
Geometry/GEMGeometry
RecoLocalMuon/GEMSegment

@perrotta, @civanch, @Dr15Jones, @makortel, @cvuosalo, @ianna, @mdhildreth, @cmsbuild, @kpedro88, @slava77, @jpata can you please review it and eventually sign? Thanks.
@bellan, @folguera, @abbiendi, @Fedespring, @jshlee, @calderona, @HuguesBrun, @jhgoh, @dildick, @cericeci, @rovere, @trocino, @fabiocos, @slomeo this is something you requested to watch as well.
@silviodonato, @dpiparo, @qliphy you are the release manager for this.

cms-bot commands are listed here

@perrotta
Copy link
Contributor

please test

@cmsbuild
Copy link
Contributor

cmsbuild commented Sep 16, 2020

The tests are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

@cmsbuild
Copy link
Contributor

Comparison job queued.

@cmsbuild
Copy link
Contributor

cmsbuild commented Sep 22, 2020

The tests are being triggered in jenkins.

@perrotta
Copy link
Contributor

perrotta commented Sep 22, 2020

Actually, no, I spoke too soon, the reason we are using double there is that we inherit from RecSegment which requires double chi2 in the interface. I've reverted the changes

I'm convinced that it could be more conveniently migrated everywhere, thus avoiding type conversions back and forth from float to double... But I agree that it is not something that has to be dealt with in this PR

@cmsbuild
Copy link
Contributor

+1
Tested at: 593bea0
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-4783c0/9485/summary.html
CMSSW: CMSSW_11_2_X_2020-09-21-2300
SCRAM_ARCH: slc7_amd64_gcc820

@cmsbuild
Copy link
Contributor

Comparison job queued.

@cmsbuild
Copy link
Contributor

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-4783c0/9485/summary.html

Comparison Summary:

  • No significant changes to the logs found
  • Reco comparison results: 11 differences found in the comparisons
  • DQMHistoTests: Total files compared: 35
  • DQMHistoTests: Total histograms compared: 2540471
  • DQMHistoTests: Total failures: 1
  • DQMHistoTests: Total nulls: 0
  • DQMHistoTests: Total successes: 2540448
  • DQMHistoTests: Total skipped: 22
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 0.0 KiB( 34 files compared)
  • Checked 149 log files, 22 edm output root files, 35 DQM output files

@kpedro88
Copy link
Contributor

+upgrade

@cvuosalo
Copy link
Contributor

+1

@perrotta
Copy link
Contributor

+1

  • It adapts GEMSegments to allow GE0 in them
  • A new GE0SegAlgRU plugin is also introduced here: it will eventually replace the ME0SegAlgRU one, but it is not yet inserted by default in the Phase2 pipeline
    • Some code overlap with ME0SegAlgRU is unavoidable: it will become irrelevant once ME0SegAlgRU will be dropped
  • Jenkins tests pass and show only differences for the removed time variable that was still there in the previous GEMSegment
  • GE0SegAlgRU not tested with the central tests because not yet included in the default reco: a validation has been performed by the authors, and reported in the PR description

@cmsbuild
Copy link
Contributor

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)

Comment on lines +3 to +19
# 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),
)

Copy link
Contributor

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

Copy link
Contributor Author

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.

@silviodonato
Copy link
Contributor

+1

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

Successfully merging this pull request may close these issues.

None yet

8 participants