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
Memory reduction of the Cluster Charge Histogram used in SiStrip gain calibration #20010
Conversation
A new Pull Request was created by @dimattia for master. It involves the following packages: CalibTracker/SiStripChannelGain @ghellwig, @vazzolini, @kmaeshima, @arunhep, @cerminar, @dmitrijus, @cmsbuild, @franzoni, @vanbesien, @lpernie can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
@cmsbuild 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: |
Comparison job queued. |
@@ -267,6 +267,9 @@ void SiStripGainsPCLWorker::processEvent(const TrackerTopology* topo) { | |||
if(Validation) {ClusterChargeOverPath/=(*gainused)[i];} | |||
if(OldGainRemoving){ClusterChargeOverPath*=(*gainused)[i];} | |||
} | |||
|
|||
// keep processing of pixel cluster charge until here | |||
if(APV->SubDet<=2) continue; |
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.
hi @dimattia , Question : can't we get rid completely of the pixel part ? there are have checks and computation for the pixel above this line like here
https://github.com/dimattia/cmssw/blob/8bdcb4372e22de2ac5112b37575b3bead83546a5/CalibTracker/SiStripChannelGain/src/SiStripGainsPCLWorker.cc#L262
or here :
https://github.com/dimattia/cmssw/blob/8bdcb4372e22de2ac5112b37575b3bead83546a5/CalibTracker/SiStripChannelGain/src/SiStripGainsPCLWorker.cc#L238
which are eventually not used - Same comments for SiStripGainFromCalibTree.cc .
What do you think ? thanks
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.
Ciao @boudoul in principle yes because the pixel cluster charge is neither collected in the AlCARECO histograms nor used. Anyway, I would like to keep the Pixel hit processing for a while because we may discover that, with the new Pixel detector readout, filtering the statistic according to the quality of the pixel hits in the track helps the quality of the dE/dx estimation for the Strip.
Comparison is ready Comparison Summary:
|
Hello @dimattia, @boudoul |
Hi @mmusich thank you for the measurement which are an independent confirmation of the improvements. Anyway I want to stress that the reduction seen at peak level is not in line with the reduction of the memory that this implementation provides. Indeed we achieve a reduction of a factor of 4 in memory (moving from 89000x2000 bins to 72500x687 bins); now the ClusterCharge histogram takes 25 MBytes while before it needed 100 MBytes. Therefore your measurements simply point out that the huge increase in memory consumption is not only due to the Histogram size. I think it also comes from some weird feature in the framework. |
@dimattia (commenting on how to read the plot)
|
float* binYarray = new float[688]; | ||
double p0 = 5.445; | ||
double p1 = 0.002113; | ||
double p2 = 69.01576; |
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.
maybe there is a better place for these magic numbers in CalibTracker/SiStripChannelGain/interface/APVGainHelpers.h
since they are used here and in SiStripGainsPCLWorker.cc
as well?
Also do we ever expect to change them again? Maybe can be passed as tracked arguments.
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.
@mmusich these magic numbers are the result of the optimization work pointed out in the PR description. They are not supposed to be changed.
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.
@dimattia thanks, do you really need 5 decimals to describe the function? anyway moving them in a single place is a good idea.
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.
@mmusich concerning the place of the "magic numbers". These numbers concerns the binning of histograms which - for the time being - are duplicated among the PCWorker and the SiStripGainFromCalibTree. The re-engineering of SiStripGainFromCalibTree.cc will happen later and is not a subject of this PR.
Note that 72500*687 shorts should be ~95MB (down from 340MB)... (multiplied by n threads and other factors in the dqm end job processing)
… On Aug 2, 2017, at 12:03 PM, dimattia ***@***.***> wrote:
Hi @mmusich thank you for the measurement which are an independent confirmation of the improvements. Anyway I want to stress that the reduction seen at peak level is not in line with the reduction of the memory that this implementation provides.
Indeed we achieve a reduction of a factor of 4 in memory (moving from 89000x2000 bins to 72500x687 bins); now the ClusterCharge histogram takes 25 MBytes while before it needed 100 MBytes. Therefore your measurements simply point out that the huge increase in memory consumption is not only due to the Histogram size. I think it also comes from some weird feature in the framework.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
The tests are being triggered in jenkins. |
-1 Tested at: 841ec1b The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic: You can see the results of the tests here: I found follow errors while testing this PR Failed tests: RelVals
When I ran the RelVals I found an error in the following worklfows: runTheMatrix-results/1306.0_SingleMuPt1_UP15+SingleMuPt1_UP15+DIGIUP15+RECOUP15+HARVESTUP15/step4_SingleMuPt1_UP15+SingleMuPt1_UP15+DIGIUP15+RECOUP15+HARVESTUP15.log The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic: |
Comparison not run due to runTheMatrix errors (RelVals and Igprof tests were also skipped) |
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: |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
@dimattia in the interest of trying to converge with this PR, can you apply the code-checks patch suggested above: |
@lpernie @arunhep @dmitrijus |
+1 |
This pull requests implements the code needed to reduce the number of bins of the cluster charge histogram. The implementation requires to book a TH2S histogram with variable bin size, which was incidentally not supported by the DQMStore. The fix for this is delivered within the pull request under the DQMservice package.
The motivation of this change has been already presented here
https://indico.cern.ch/event/649344/contributions/2672267/attachments/1498323/2332518/OptimizeChHisto.pdf