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
Improvements to the SiStripHitEfficiencyHarvester
for Run 3 data-taking
#38592
Improvements to the SiStripHitEfficiencyHarvester
for Run 3 data-taking
#38592
Conversation
hold
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-38592/30848
|
Pull request has been put on hold by @mmusich |
A new Pull Request was created by @mmusich (Marco Musich) for master. It involves the following packages:
@malbouis, @yuanchao, @cmsbuild, @ggovi, @francescobrivio, @ChrisMisan, @tvami can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
tkMapBad.fillc(det, 255, 255, 255); | ||
// use only the "good" modules | ||
if (stripQuality_->getBadApvs(det) == 0) { | ||
const auto eff = num / denom; |
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 auto
for the num
and denom
is an uint
, will the auto
for the eff
somehow take care of the integer division?
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.
The code was already like that before, and as far as I can tell does the right thing.
CalibTracker/SiStripHitEfficiency/plugins/SiStripHitEfficiencyHarvester.cc
Outdated
Show resolved
Hide resolved
CalibTracker/SiStripHitEfficiency/plugins/SiStripHitEfficiencyWorker.cc
Outdated
Show resolved
Hide resolved
please test |
I see this in the logs
|
-1 Failed Tests: HeaderConsistency RelVals-INPUT RelVals-INPUTThe relvals timed out after 4 hours. Comparison SummarySummary:
|
78fdf32
to
9b82ea6
Compare
Pull request #38592 was updated. @malbouis, @yuanchao, @cmsbuild, @ggovi, @francescobrivio, @ChrisMisan, @tvami can you please check and sign again. |
please test |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-05d064/25987/summary.html Comparison SummarySummary:
|
unhold
|
+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. @perrotta, @dpiparo, @qliphy, @rappoccio (and backports should be raised in the release meeting by the corresponding L2) |
Does this deserve an |
I wouldn't say it's urgent, as far as I know the hit efficiency measurement is still being done with calibration trees anyway, so this will become relevant once the switchover is done in the shifter tools. |
Ok, so not necessarily needed for 12_4_3 |
+1 |
PR description:
As per request of the SiStrip offline group, I apply few improvement for the harvesting step:
isAtPCL
set to false) produce the final good module/ bad moduleTGraphError
plot for the hit efficiency;isAtPCL
set to false) produce aTTree
to store per-DetId information for further post-processing from experts / shifters;SiStripHitEffData
struct to store the per eventFEDError
s and some events statistics;SiStripHitEffFromCalibTree
: used lower case to name methods and useusesResource(TFileService::kSharedResource)
for threading efficiency.PR validation:
Run the following commands:
cmsDriver.py stepReAlCa -s ALCA:PromptCalibProdSiStripHitEff --conditions 123X_dataRun2_v2 --scenario pp --data --era Run2_2018 --datatier ALCARECO --eventcontent ALCARECO --processName=ReAlCa -n 100000 --dasquery='file dataset=/StreamExpress/Run2018D-SiStripCalMinBias-Express-v1/ALCARECO run=325172' --nThreads=4
followed by:
cmsDriver.py stepHarvest -s ALCAHARVEST:SiStripHitEff --conditions 123X_dataRun2_v2 --scenario pp --data --era Run2_2018 --filein file:PromptCalibProdSiStripHitEfficiency.root -n -1
and obtained the following plot:
If this PR is a backport please specify the original PR and why you need to backport that PR. If this PR will be backported please specify to which release cycle the backport is meant for:
Not a backport but needs to be backported for the data-taking.