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
Monitoring of SiPixelQuality PCL using tracker offline DQM and bugfix for the SiPixelQuality tag for PromptReco #23616
Conversation
The code-checks are being triggered in jenkins. |
-code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-23616/5240 Code check has found code style and quality issues which could be resolved by applying a patch in https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-23616/5240/git-diff.patch You can run |
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-23616/5242 |
A new Pull Request was created by @tocheng (Tongguang) for master. It involves the following packages: CalibTracker/SiPixelQuality @arunhep, @cerminar, @cmsbuild, @franzoni, @pohsun, @lpernie, @fabiocos, @davidlange6 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test |
The tests are being triggered in jenkins. |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
Comparison job queued. |
Comparison is ready Comparison Summary:
|
Comparison job queued. |
Comparison is ready Comparison Summary:
|
+1 |
@@ -225,7 +225,7 @@ | |||
EcalPedestals = cms.Path(ALCAHARVESTEcalPedestals) | |||
SiStripGainsAAG = cms.Path(ALCAHARVESTSiStripGainsAAG) | |||
LumiPCC = cms.Path(ALCAHARVESTLumiPCC) | |||
SiPixelQuality = cms.Path(ALCAHARVESTSiPixelQuality) | |||
SiPixelQuality = cms.Path(ALCAHARVESTSiPixelQuality)#+siPixelPhase1DQMHarvester) |
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.
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.
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.
@fabiocos The original plan is to use the SiPixel Phase-I DQM Harvester class (as a template) to normalize the bincontent of the track map plots (in tracker DQM output) by the total number of lumi sections. So the bin content will represent the fraction of time that the ROC is bad in a run. (Then it will be easier to identify new ROCs that are bad for during whole run)
But I realize it needs a lot of customization as the functionalities I need is protected/guarded by the SiPixel DQM framework. I contacted the tracker DQM conveners but they are too busy to work on this special request.
So I decide to put this development for the future. The plots with binconent as the absolute number of lumi section is still good enough to monitor the payloads and identify new bad ROCs.
Currently siPixelPhase1DQMHarvester is dummy for the SiPixelQuality DQM production.
I commented it to prevent the impact from potential central SiPixel DQM development in the future.
I will discuss with the tracker DQM experts when the they have more time on it.
I don't think this development is very urgent or needed for this year.
Hopefully this clarifies the change.
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.
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.
@fabiocos
I think I misunderstood your questions. "siPixelPhase1DQMHarvester" is dummy.
BUT The PR is NOT dummy. The implementation of ALCAHARVESTSiPixelQuality is bug-fixed and updated.
I think it is very critical for this PR to be merged into CMSSW_10_2_0.
Because it fixes a bug for the SiPixelQuality conditions to be used for prompt reconstruction : see da9f6e2
The DQM monitoring in the PR provides the feature to monitor the SiPixelQuality conditions produced by PCL and also to help offline tracker DQM shifter to find new bad components,
especially new bad components from DCDC converter breakdown.
They are both very critical for the data taking and processing in CMSSW_10_2_0 release.
@fabiocos The motivation of this whole project is automation of lumibased pixel quality for prompt reco and monitoring of bad components due to DCDC converter breaking. Without the PR merged, neither of them can be realized. |
@tocheng, ok sorry for misinterpreting your answer. |
+operations the update of StandardSequences is for the time being dummy, a placeholder for future deployment |
+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 be automatically merged. |
Hello, the PR is meant to monitor the PCL payloads of SiPixelQuality using tracker offline DQM.
The harvester is changed to a DQMEDAnalyzer to produce the payloads and DQM IO in one CMSSW module.
The continuous payloads are replace by one payload if they are identical. This will clean the redundant payloads in the tags.
And with the help of the DQM plots, I found a bug in the tag for prompt-reco from the SiPixelQuality production; only the low DIGI ROCs in the permanent bad components were added to the tag for prompt-reco, while all the components that were low efficient (due to 2017 DCDC damage) were not included. So this bug was fixed in the later commit of the PR.
More details can be seen in the pixel offline meeting this week.
https://indico.cern.ch/event/688868/contributions/3062848/attachments/1680102/2698910/PixelQualityPCL_July3rd_2018_pixeloffline.pdf
Sorry for pending the PR for quite some time. I was trying to find way to normalize the DQM plots in the way that they can be easily compared between different runs regardless the length of the run. But the simple way led to the crash of all TProfile plots for tracker DQM. There are other solutions, but from my point of view, too complicated to be done in a reasonable time.
So I keep the plots as what they are and they are still good enough to use without the normalization.