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

Permanently enabling method 3 #11507

Merged
merged 2 commits into from Oct 1, 2015

Conversation

igv4321
Copy link
Contributor

@igv4321 igv4321 commented Sep 26, 2015

Permanently enabling "Method 3" in HcalSimpleRecAlgo.

Some trivial cleanup of HcalSimpleRecAlgo (e.g., removed unused default constructor, added a buffer vector of doubles so that this vector does not have to be reallocated for every digi, etc).

Require proper initialization of "Method 3" in the HcalHitReconstructor module.

@cmsbuild
Copy link
Contributor

A new Pull Request was created by @igv4321 (Igor Volobouev) for CMSSW_7_6_X.

Permanently enabling method 3

It involves the following packages:

RecoLocalCalo/HcalRecAlgos
RecoLocalCalo/HcalRecProducers

@cmsbuild, @cvuosalo, @slava77 can you please review it and eventually sign? Thanks.
@argiro this is something you requested to watch as well.
You can sign-off by replying to this message having '+1' in the first line of your reply.
You can reject by replying to this message having '-1' in the first line of your reply.
If you are a L2 or a release manager you can ask for tests by saying 'please test' in the first line of a comment.
@Degano you are the release manager for this.
You can merge this pull request by typing 'merge' in the first line of your comment.

// S.Brandt Feb19 : Add a pointer to the HLT algo
std::auto_ptr<HcalDeterministicFit> hltOOTpuCorr_;

// Speed up the code a little bit by not allocating a vector every time
mutable std::vector<double> vectorBuffer_;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the size of the saving from this buffer?
I'd much rather see no mutables.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please remove this.
I don't see much benefit.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The saving does not come from the "size" of the vector. It is instead about not allocating (and then deallocating) the memory from the heap for each calorimeter cell processed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there are several more allocations in the methods called internally.
So, if a fix needs to be done, better do it properly.

Your change with a mutable opens a possibility to pass information between hits.
This is not good.

Cleaning and clearing is apparently done correctly now, but this makes the code much more fragile in the future developments.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is with 25ns hlt in 760pre5
https://slava77sk.web.cern.ch/slava77sk/reco/cgi-bin/igprof-navigator/CMSSW_7_6_0_pre5-orig.256729.step2-hlt.pp/797

i don't see any cpu cost reasons for this buffer

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The allocations internal to "Method 2" and "Method 3" classes are, of course, irrelevant to this discussion. Bug the authors of the corresponding classes if you are so inclined.

The change with a mutable, of course, does not open any possibility to pass information between hits. The vector is cleared any time it is used.

Any code is "fragile" to some degree. I believe, the advantages outweigh the drawbacks in this particular case. The "mutable" keyword is included into the language precisely for the uses similar to this.

The cost reasons are obvious: we avoid allocating the contents of the vector on the heap for every hcal rechit.

@slava77
Copy link
Contributor

slava77 commented Sep 26, 2015

@cmsbuild please test

@cmsbuild
Copy link
Contributor

The tests are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

@cmsbuild
Copy link
Contributor

@slava77
Copy link
Contributor

slava77 commented Sep 27, 2015

-1
pending code review

@fwyzard
Copy link
Contributor

fwyzard commented Sep 27, 2015

I do not understand lines 167 and 172 of RecoLocalCalo/HcalRecProducers/src/HcalHitReconstructor.cc .

@slava77
Copy link
Contributor

slava77 commented Sep 28, 2015

@fwyzard
a good question, actually,
the change was introduced back in #5389 or, originally authored by @FHead #5168
Why was this setPileupCorrection_ = 0; added right after assignment setPileupCorrection_ = &HcalSimpleRecAlgo::set{HF or HO}PileupCorrection;

@slava77
Copy link
Contributor

slava77 commented Sep 28, 2015

@igv4321
Please factor out the technical optimization (mutable vector buffer) into a separate PR.
We need the physics level feature (M3 values stored) in the release.

The optimization made is still questionable to me and it is not time critical.
Also, a more appropriate solution will not include the vector, which makes this improvement only temporary.

Thank you.

@igv4321
Copy link
Contributor Author

igv4321 commented Sep 28, 2015

Do I need to make a comment for the system to see the latest push?

@cmsbuild
Copy link
Contributor

Pull request #11507 was updated. @cmsbuild, @cvuosalo, @slava77 can you please check and sign again.

@slava77
Copy link
Contributor

slava77 commented Sep 28, 2015

Igor,

yes, unfortunately cms-bot doesn't notice a commit from an "old" branch and a message is needed.

Thank you very much for the factorization of the technical performance.

I noticed a change in a follow up to Andrea's comment about
setPileupCorrection_ = 0;
Could you please elaborate a bit on the history of the changes here.

@slava77
Copy link
Contributor

slava77 commented Sep 28, 2015

@cmsbuild please test

@cmsbuild
Copy link
Contributor

The tests are being triggered in jenkins.

@igv4321
Copy link
Contributor Author

igv4321 commented Sep 28, 2015

"setPileupCorrection_" variable is actually configured (as intended) by module parameters "dataOOTCorrectionName", "dataOOTCorrectionCategory", "mcOOTCorrectionName", and "mcOOTCorrectionCategory". Yi Chen, who put those lines in, simply did not realize this.

It is harmless to set this variable to 0 at those points in the code, as "Method 1" was not intended for HF and HO to begin with. While "Method 1" is currently deprecated, I don't want to completely remove this mechanism yet -- perhaps, some other method will be developed, inheriting from AbsOOTPileupCorrection.

@cmsbuild
Copy link
Contributor

@cmsbuild
Copy link
Contributor

@cmsbuild
Copy link
Contributor

@slava77
Copy link
Contributor

slava77 commented Sep 30, 2015

@igv4321
Do you know of the plans to add DQM/Validation plots to monitor the M3 value saved in the aux and also compare the reco (M2) and M3?

Currently, jenkins comparisons show no differences from the change made here (as expected from the lack of the DQM/validation plots)

@slava77
Copy link
Contributor

slava77 commented Oct 1, 2015

+1

for #11507 bb4492a

  • code changes are rather minimal and look OK
  • jenkins test pass and comparisons with baseline show no difference
  • tested locally in CMSSW_7_6_X_2015-09-29-0900. The following numbers are from 134.805 workflow (a 25ns run 254790 from 2015C)
    • event size increases negligibly: hbhe rechit size is up by about 10%, which adds up to 0.5% in RECO, but is a factor of a few smaller in AOD (only reduced rechit collection is stored)
    • CPU time increases negligibly: hbheprereco time is up by about 2% (0.1% of all reco time)
    • the M3 energy now shows in in eaux() and appears to be correlated well with the M2 energy (::energy())
      sign599_wf134p805_hbhe_energy_vs_aux_0to10

@cmsbuild
Copy link
Contributor

cmsbuild commented Oct 1, 2015

This pull request is fully signed and it will be integrated in one of the next CMSSW_7_6_X IBs (tests are also fine). This pull request requires discussion in the ORP meeting before it's merged. @davidlange6, @Degano, @smuzaffar

@abdoulline
Copy link

<...>
Do you know of the plans to add DQM/Validation plots to monitor the M3 value saved in the aux and also compare the reco (M2) and M3?
<...>

The (original) idea was just to have M3 vs M2 right away without manupulation of different input files and DetId matching for on-demand comparisons/tests/checks (like the ones performed for "Early 2015 Physics Commissioning" task force).
But including this kind of comparison (M3 used in HLT vs M2 used in Offline) in Offline data DQM and MC Validation seems to be a good idea.

@davidlange6
Copy link
Contributor

+1

cmsbuild added a commit that referenced this pull request Oct 1, 2015
@cmsbuild cmsbuild merged commit 3cca4f7 into cms-sw:CMSSW_7_6_X Oct 1, 2015
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

6 participants