Fix r45Fraction_ calculation

[dertexaner]

This is a simple bug-fix for the noisy hit fraction (r45Fraction_ ) calculation in CommonHcalNoiseRBXData.

[cmsbuild]

A new Pull Request was created by @dertexaner for CMSSW_7_6_X.

Fix r45Fraction_ calculation

It involves the following packages:

RecoMET/METAlgorithms

@cmsbuild, @cvuosalo, @slava77 can you please review it and eventually sign? Thanks.
@TaiSakuma, @ahinzmann, @mmarionncern, @jdolen, @nhanvtran, @schoef, @mariadalfonso 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.

[slava77]

@cmsbuild please test

[cmsbuild]

The tests are being triggered in jenkins.

[slava77]

@dertexaner if I understand correctly, this resolves issues with uninitialized values and nans from divisions by zero, which are typically not happening.
Is this correct?

[dertexaner]

@slava77 Yes, this makes initializations cleaner and fixes the division of ints as it wasn't working properly.

[cmsbuild]

+1
Tested at: a4e08f8
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-10726/7199/summary.html

[cmsbuild]

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-10726/7199/summary.html

[cvuosalo]

+1

For #10726 a4e08f8

Correcting a coding mistake to properly calculate the RBX HCAL noisy hits fraction. #10724, the 74X version of this PR, contains additional information about this fix. #10725, the 75X version, has already been approved by Reco.

The code change is correct and necessary, and Jenkins tests against baseline CMSSW_7_6_X_2015-08-12-1100 show no significant differences, since the fix covers a case that rarely occurs in standard workflows. The message in this thread that "All checks have failed" is spurious since it refers to #10724 and not this PR.

[cmsbuild]

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

[davidlange6]

+1

[cvuosalo]

In a future PR, a useless block of code flagged by the static analyzer around line 85 in HcalNoiseAlgo.cc
needs to be deleted:

  for(std::vector<reco::HcalNoiseHPD>::const_iterator it1=rbx.HPDsBegin(); it1!=rbx.HPDsEnd(); ++it1) {
    double eme=it1->caloTowerEmE();
    double hade=it1->recHitEnergy(minRecHitE);
    double emf=(eme+hade)==0 ? 999 : eme/(eme+hade);
    if(HPDEMF_ > emf) emf = HPDEMF_;
  }

Unless this code has some side effect I'm missing, it performs a bunch of iterations and calculations for nothing. If there is some important side effect, a comment explaining it should be added.

Sorry I forgot to mention this issue earlier.

[slava77]

this looks like a bug, actually (a = b; flip with b = a;)

[cvuosalo]

@Slava:

Yes, it looks like the code should be:

 if (HPDEMF_ > emf)
      HPDEMF_ = emf;

This value is the minimum electromagnetic fraction found in an HPD in the RBX, which is returned by the HPDEMF() method. With this bug, the noise filtering may not be working quite right.

[dertexaner]

@slava77 @cvuosalo Indeed this calculation doesn't do anything. But I think this parameter is used for the RBXEMF which is then used at least in noise cleaning in HLT (http://cmslxr.fnal.gov/lxr/ident?v=CMSSW_7_4_6&_i=RBXEMF&_remember=1). Shall I submit another PR for this now?

[slava77]

yes, if the code is used and the fix is needed, a separate PR is needed.
If the effect is significant for analysis and data taking, this will need to be made in 3 releases 74/5/6X,

[dertexaner]

@slava77 Upon closer inspection, I think this parameter is only used in HPDEMF() which is not used anywhere but it is stored in hcal noise summary anyway. Would it be more appropriate to submit the PR only for 75X and 76X ?

[slava77]

yes, makes sense for just 75X/76X