bug fix for GsfEleEcalDrivenCut #17118
Conversation
|
A new Pull Request was created by @Sam-Harper for CMSSW_9_0_X. It involves the following packages: RecoEgamma/ElectronIdentification @cmsbuild, @cvuosalo, @slava77, @davidlange6 can you please review it and eventually sign? Thanks. cms-bot commands are listed here #13028 |
|
|
||
| bool GsfEleEcalDrivenCut::isValidCutVal(int val) | ||
| { | ||
| if(val==IGNORE) return true; |
There was a problem hiding this comment.
@Sam-Harper use a switch statement here!
There was a problem hiding this comment.
isnt that personal style choice? I personally never really like switch statements.
There was a problem hiding this comment.
The compiler might optimize it out but otherwise they should make very different code (switch statement being much more efficient). I suppose it doesn't matter so much since it isn't called every event.
switch(val) {
case IGNORE:
case PASS:
case FAIL:
return true;
break;
default:
break;
}There was a problem hiding this comment.
well it'll be done twice per object it should be fine. I have an irrational aversion to switch statements :)
| errMsg<<"error in constructing GsfEleEcalDrivenCut"<<std::endl; | ||
| errMsg<<"values of ecalDrivenEB: "<<ecalDrivenEB_<<" and/or ecalDrivenEE: "<<ecalDrivenEE_<<" are invalid "<<std::endl; | ||
| errMsg<<"allowed values are IGNORE:"<<IGNORE<<" FAIL:"<<FAIL<<" PASS:"<<PASS; | ||
| throw edm::Exception(edm::errors::Configuration,errMsg.str()); |
There was a problem hiding this comment.
IIRC, you can just edm::Exception(category)<<"blah" << xyz;
to avoid creation of ostringstream
There was a problem hiding this comment.
ta, I didnt know that. Done.
|
@cmsbuild please test |
|
The tests are being triggered in jenkins. |
|
Comparison job queued. |
cmsbuild
added
fully-signed
reconstruction-approved
and removed
pending-signatures
reconstruction-pending
labels
|
This pull request is fully signed and it will be integrated in one of the next CMSSW_9_0_X IBs (tests are also fine). This pull request requires discussion in the ORP meeting before it's merged. @davidlange6, @smuzaffar |
|
+1 |
Thanks to @lgray, a bug was found where the GsfEleEcalDrivenCut accidentally stores the cut value in a bool rather than an int. This meant that the "ignore" code (-1) would be configured to "require ecal driven" (1).
This has no impact in any official E/g ID as its never set to ignore (only the case when you want it ignored in the barrel and not the endcap or vice versa would have this). Still it should be fixed. No need for any backports.
At the same time, I made the whole thing more robust against user config errors, to the point it will now throw an exception and a clear message if the config file passes in something other -1,0,1 for the cut value.
Out of ~7000 DY events, no changes in the number of electrons passing the HEEP V60 ID (which uses this cut) is observed.