-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Phase2 digitizer updated to exclude badchannel in Strip like detectors #37576
Phase2 digitizer updated to exclude badchannel in Strip like detectors #37576
Conversation
…he Condition Database for Strip-like detectors, namely PSS and SS types. Also updated the framework to be able to treat BadChannels independently for each type of subdetectors. For Inner Pixel detectors BadChannel implementation is done in PixelDigitizerAlgorithm. 3D-Pixel and Bricked-Pixel algorithms inherit from PixelDigitizerAlgorithm. Also changed the variable/method names dead->bad as the name Bad signifies both dead and noisy.
…he Condition Database for Strip-like detectors, namely PSS and SS types. Also updated the framework to be able to treat BadChannels independently for each type of subdetectors. For Inner Pixel detectors BadChannel implementation is done in PixelDigitizerAlgorithm. 3D-Pixel and Bricked-Pixel algorithms inherit from PixelDigitizerAlgorithm. Also changed the variable/method names dead->bad as the name Bad signifies both dead and noisy.
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-37576/29328
|
A new Pull Request was created by @suchandradutta (Suchandra Dutta) for master. It involves the following packages:
@cmsbuild, @AdrianoDee, @srimanob, @civanch, @mdhildreth can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
@cmsbuild, please test |
-1 Failed Tests: RelVals-INPUT RelVals-INPUTThe relvals timed out after 4 hours. Comparison SummarySummary:
|
@cmsbuild, please test
|
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-6adfd4/23958/summary.html Comparison SummarySummary:
|
@@ -23,10 +23,10 @@ | |||
#include "DataFormats/DetId/interface/DetId.h" | |||
#include "CondFormats/SiPixelObjects/interface/GlobalPixel.h" | |||
#include "CondFormats/SiPixelObjects/interface/SiPixelLorentzAngle.h" | |||
#include "CondFormats/SiPixelObjects/interface/SiPixelQuality.h" | |||
#include "CondFormats/SiPixelObjects/interface/PixelROC.h" | |||
//#include "CondFormats/SiPixelObjects/interface/SiPixelQuality.h" |
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.
It would be good not to keep commented headers.
@suchandradutta , there is a general recommendation: in plugin directory do not have separate *.h files but include them into *.cc; it may be not a strong requirement but when you already working with some modifications it may be worse implementing. |
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.
if the PR is touched anyway here's a couple of other comments.
for (auto const& p : path) { | ||
const PixelROC* myroc = fedCablingMap_->findItem(p); | ||
if (myroc->idInDetUnit() == j) { | ||
LocalPixel::RocRowCol local = {39, 25}; //corresponding to center of ROC row, col |
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.
Is this true also for the phase2 sensors?
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.
I do not think so. This is basically from PhaseI. Should I make it dummy for the moment? As it is the case fpr PSP sensors?
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.
As the functionality is not used, I think it's fine as it is. Let's revisit this after the PR is merged.
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.
These hardcoded bad modules should better get taken from a DB or configuration file.
It is easy to forget them hardcoded here otherwise.
If the experts keep agreeing on merging this PR as such, we will mergi it as it is: please at least open a github issue in that case, so that it will remain track of it.
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.
@perrotta these are NOT hardcoded bad modules, this is just a cheap way of getting the center of the ROC in local pixel coordinates. My point was that 39,25 is the middle of the ROC for the phase-1 pixel, but not necessarily also for the phase-2 one.
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.
Ah, ok. As such it makes more sense.
In any case, this could also get made customizable via python config, if it has to eventually support a different geometry for the Phase2 modules.
for (size_t id = 0; id < disabledModules.size(); id++) { | ||
if (detID == disabledModules[id].DetID) { | ||
isbad = true; | ||
badmodule = disabledModules[id]; | ||
break; | ||
} | ||
} |
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.
for (size_t id = 0; id < disabledModules.size(); id++) { | |
if (detID == disabledModules[id].DetID) { | |
isbad = true; | |
badmodule = disabledModules[id]; | |
break; | |
} | |
} | |
for (const auto& mod : disabledModules) { | |
if (detID == mod.DetID) { | |
isbad = true; | |
badmodule = mod; | |
break; | |
} | |
} |
this could be a range-based loop.
@civanch In the main driver class Phase2Digitizer.cc requires all the header files of individual algorithms. Also the inheritance will fail if the individual header files are removed. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-37576/29360
|
Pull request #37576 was updated. @cmsbuild, @AdrianoDee, @srimanob, @civanch, @mdhildreth can you please check and sign again. |
please test |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-6adfd4/23977/summary.html Comparison SummarySummary:
|
urgent
|
+1 |
+Upgrade This PR introduce the method to exclude bad channels using information from the DB. This PR has no effect in the current workflow, no change has been seen in PR test as expected. |
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. @perrotta, @dpiparo, @qliphy (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
PR description:
Implemented code to exclude BadChannels by reading information from the Condition Database for Strip-like detectors, namely PSS and SS types. Also updated the framework to be able to treat BadChannels independently for each type of subdetectors. For Inner Pixel detectors BadChannel implementation is done in PixelDigitizerAlgorithm. 3D-Pixel and Bricked-Pixel algorithms inherit from PixelDigitizerAlgorithm. Also changed the variable/method names dead->bad as the name Bad signifies both dead and noisy
Changes expected
Depends on the PR #37463 (already integrated)
PR validation:
Validation is done using
runTheMatrix.py --what upgrade -ne -l 35010.0
The description and the plots are attached below
@emiglior @mmusich
Phase2Digitizer_BadChannelStudy_15042022.pdf