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

Add full5x5 shower shape block to non-GED photons producer #12085

Merged

Conversation

harmonicoscillator
Copy link
Contributor

HI noticed that for photons produced with the "standard" photon producer, the full5x5 shower shape info was missing.

HI absolutely needs this info for photon ID purposes in run2 analyses, as we plan on using "standard" photons for run2 analyses.

@ttrk @mandrenguyen @yetkinyilmaz

We would like to request that this be included in the release used for HI data taking, potentially 7_5_3_patch2 or something similar. Apologies for not catching this error earlier.

@cmsbuild
Copy link
Contributor

A new Pull Request was created by @richard-cms (R. Alex Barbieri) for CMSSW_8_0_X.

Add full5x5 shower shape block to non-GED photons producer

It involves the following packages:

RecoEgamma/EgammaPhotonProducers

@cmsbuild, @cvuosalo, @slava77 can you please review it and eventually sign? Thanks.
@Sam-Harper, @lgray 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.

@lgray
Copy link
Contributor

lgray commented Oct 24, 2015

Are there non-ged photons that are based off of particle flow clusters? If
not then this PR is not necessary (since full5x5 and 'regular' shower
shapes are the same if there are no fractions)

(Sent from my Nexus 6)
On Oct 24, 2015 10:41 PM, "cmsbuild" notifications@github.com wrote:

A new Pull Request was created by @richard-cms
https://github.com/richard-cms (R. Alex Barbieri) for CMSSW_8_0_X.

Add full5x5 shower shape block to non-GED photons producer

It involves the following packages:

RecoEgamma/EgammaPhotonProducers

@cmsbuild https://github.com/cmsbuild, @cvuosalo
https://github.com/cvuosalo, @slava77 https://github.com/slava77 can
you please review it and eventually sign? Thanks.
@Sam-Harper https://github.com/Sam-Harper, @lgray
https://github.com/lgray 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 https://github.com/degano you are the release manager for this.
You can merge this pull request by typing 'merge' in the first line of
your comment.


Reply to this email directly or view it on GitHub
#12085 (comment).

@harmonicoscillator
Copy link
Contributor Author

There were no errors reported during workflows 140.2 or 33.0.

The actual patch is simply copying the relevant block from PhotonProducerGED, which was added in this commit: 934681b

@harmonicoscillator
Copy link
Contributor Author

@lgray
We saw a significant difference between new sigmaIetatIeta and full5x5 sigmaIetaIeta when testing this patch. We are running two photon reconstructions in HI RECO, one "standard" which is not PF cluster based, and the other which is GED. I think that the new sigmaIetaIeta calculation still attempts to account for the energy fraction (using the GED photon info) during the standard photon RECO.

@lgray
Copy link
Contributor

lgray commented Oct 24, 2015

Non-pfcluster-based photons do not use fractions, there is no way to even know about or reconcile with them. Pf and other dedicated em clusterings are incredibly different.

The difference you saw comes from something else, or your explanation of the workflow is incorrect. It's likely inconsistent RecHit flagging or something similar. I encourage that you understand this a bit more before filling these variables with something unknown.

@harmonicoscillator
Copy link
Contributor Author

@lgray, okay we'll try to track down what's actually going on here.

@harmonicoscillator
Copy link
Contributor Author

@lgray
I'm getting very mystified trying to find out how this is happening. We're using identical RecHit flagging for both full5x5 and new sigmaIetaIeta:
https://github.com/richard-cms/cmssw/blob/Full5x5ShowerShapes_76X/RecoEgamma/EgammaPhotonProducers/src/PhotonProducer.cc#L356
https://github.com/richard-cms/cmssw/blob/Full5x5ShowerShapes_76X/RecoEgamma/EgammaPhotonProducers/src/PhotonProducer.cc#L370

However, we really do a difference in the sigmaIetaIeta values. Here's a short comparison on 5 events:


  • Row * Instance * full5x5_sigmaIetaIeta * sigmaIetaIeta *

  •    0 \*        0 \* 0.0095054 \* 0.0094380 *
    
  •    0 \*        1 \* 0.0240499 \* 0.0240378 *
    
  •    1 \*        0 \* 0.0087834 \* 0.0090450 *
    
  •    2 \*        0 \* 0.0094981 \* 0.0095428 *
    
  •    2 \*        1 \* 0.0085439 \* 0.0069553 *
    
  •    3 \*        0 \* 0.0088339 \* 0.0086395 *
    
  •    3 \*        1 \* 0.0188216 \* 0.0099303 *
    
  •    3 \*        2 \* 0.0240541 \* 0.0242143 *
    
  •    4 \*        0 \* 0.0098860 \* 0.0100173 *
    

If I take a look in the bowels of the island clustering algorithm, I see lines like this one:
https://github.com/cms-sw/cmssw/blob/CMSSW_8_0_X/RecoEcal/EgammaClusterAlgos/src/IslandClusterAlgo.cc#L139
which explicitly set the fraction to 1 for the island basic clusters, as you said.

What could possibly be different between these two sigmaIetaIeta calculations to cause this difference?

@slava77
Copy link
Contributor

slava77 commented Oct 25, 2015

@cmsbuild please test

@cmsbuild
Copy link
Contributor

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-any-integration/9180/console

@cmsbuild
Copy link
Contributor

@cmsbuild
Copy link
Contributor

@@ -359,6 +359,19 @@ void PhotonProducer::fillPhotonCollection(edm::Event& evt,
float sigmaIetaIeta = sqrt(locCov[0]);
float r9 =e3x3/(scRef->rawEnergy());

float full5x5_maxXtal = noZS::EcalClusterTools::eMax( *(scRef->seed()), &(*hits) );
Copy link
Contributor

Choose a reason for hiding this comment

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

Before dereferencing hits, please check it is non-null. There is a possibility that hits would equal 0.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So this code was copied directly from https://github.com/CmsHI/cmssw/blob/forest_CMSSW_7_5_3_patch1/RecoEgamma/EgammaPhotonProducers/src/GEDPhotonProducer.cc#L502 which also does not checkout for null so I didn't think about this too hard.

I can add a non-null check to this file, but I'm loathe to change anything in GEDProducer to prevent PR creep.

@cvuosalo
Copy link
Contributor

@lgray :
Could you please give feedback about whether you are satisfied with this PR or still have questions about it?

@harmonicoscillator
Copy link
Contributor Author

We spoke with Lindsey/Matteo some offline and are currently attempting some tests to get to the bottom of why the full5x5 and non-full5x5 calculations have differences. We will hopefully have some answers this week.

@harmonicoscillator
Copy link
Contributor Author

Okay, I believe I have found the source of the discrepancy between the noZS (full5x5) and ZS (non-full5x5) results, and it is in the "getFraction" EcalClusterTools function: https://github.com/cms-sw/cmssw/blob/CMSSW_8_0_X/RecoEcal/EgammaCoreTools/interface/EcalClusterTools.h#L257

If noZS is false (non-full5x5), then the getFraction function returns '0' for rechits that it cannot find. The noZS version returns 1.0 in those cases (is this a bug, or intended?). 'getFraction' is called by matrixEnergy, and matrixEnergy is in turn called by e5x5, and the difference in e5x5 causes the difference in sigmaIetaIeta. If I force getFraction to return 1.0 always (the noZS behavior) the noZS and ZS results are the same.

Unfortunately, I do not know if this behavior is a bug or is intended. @lgray or @matteosan1 do you have any ideas on:

  1. What are these rechits that return a fraction 0? They must come from outside the basiccluster?
  2. Is this different behavior for ZS and noZS when the rechit cannot be found intended?

Any thoughts are appreciated. @yenjie, and @ttrk are also interested.

@cmsbuild
Copy link
Contributor

cmsbuild commented Nov 4, 2015

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

@cvuosalo
Copy link
Contributor

cvuosalo commented Nov 4, 2015

@cmsbuild please test

@cmsbuild
Copy link
Contributor

cmsbuild commented Nov 4, 2015

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-any-integration/9465/console

}
if(!hits) continue;
Copy link
Contributor

Choose a reason for hiding this comment

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

@richard-cms: Better style would be if (hits == 0), since hits is not a boolean, but this way is OK, too.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay I switched it to hits == 0.

@cmsbuild
Copy link
Contributor

cmsbuild commented Nov 4, 2015

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

@cmsbuild
Copy link
Contributor

cmsbuild commented Nov 4, 2015

@cmsbuild
Copy link
Contributor

cmsbuild commented Nov 4, 2015

@cvuosalo
Copy link
Contributor

cvuosalo commented Nov 4, 2015

+1

For #12085 3986852

For Heavy Ions, adding full5x5 shower shape to non-GED photons. #12086 and #12087 are the 75X and 76X versions of this PR, and the former has already been approved by Reco.

The code changes are satisfactory, and Jenkins tests against baseline CMSSW_8_0_X_2015-11-04-1100 show no significant differences, except for the expected addition of the shower shapes.

@cmsbuild
Copy link
Contributor

cmsbuild commented Nov 4, 2015

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

@davidlange6
Copy link
Contributor

+1

cmsbuild added a commit that referenced this pull request Nov 5, 2015
Add full5x5 shower shape block to non-GED photons producer
@cmsbuild cmsbuild merged commit 94484af into cms-sw:CMSSW_8_0_X Nov 5, 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

7 participants