Low pT electrons (up to GsfTracks) for 10_5_X

[bainbrid]

This PR is equivalent to the open #25455 PR, but rebased to 10_5_X using a very recent IB.

This PR was opened in response to this instruction.

[cmsbuild]

@bainbrid, CMSSW_10_5_X branch is closed for direct updates. cms-bot is going to move this PR to master branch.
In future, please use cmssw master branch to submit your changes.

[cmsbuild]

+1
Tested at: f6a640b
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-25679/32752/summary.html

[cmsbuild]

Comparison job queued.

[cmsbuild]

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

Comparison Summary:

• No significant changes to the logs found
• ROOTFileChecks: Some differences in event products or their sizes found
• Reco comparison results: 12 differences found in the comparisons
• DQMHistoTests: Total files compared: 32
• DQMHistoTests: Total histograms compared: 3097440
• DQMHistoTests: Total failures: 3
• DQMHistoTests: Total nulls: 0
• DQMHistoTests: Total successes: 3097240
• DQMHistoTests: Total skipped: 197
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 0.0 KiB( 31 files compared)
• Checked 133 log files, 14 edm output root files, 32 DQM output files

[perrotta]

+1

• Changes since Low pT electrons (up to GsfTracks) for 10_5_X #25679 (comment) only consist in using the full ecal recHits, instead of the reduced ones in the config
• New gsf electrons, with higher efficiency expected at low pt, are defined here to be used in the reco-ing of the parked b dataset
• The extra product will be just added to the Event, but it is not used to build any further higher level object (e.g PF) at the moment
• According to Low pT electrons (up to GsfTracks) for 10_5_X #25679 (comment) the same comments on performance as reported in Low pT electrons (up to GsfTracks) for 10_5_X #25679 (comment), and are copied here for convenience:
  • The loose working point to be used for the parked dataset implies a rather heavy usage of cpu (it amounts to ~12.4% time of the overall reco + miniAOD time). For the normal workflows a tighter working point was defined, whose cpu usage corresponds to ~4.3% of the total reco + miniAOD processing time: the efficiency for low pt photons get reduced by some 25% with respect to the looser working point, though.
  • The tests show that only the new objects are added in output, while nothing else show differences in reco or miniAOD: jenkins tests report about 12 differences in the reco comparisons from the Phase2 workflows, and they all correspond to the additional warning messages issued by the PFTrackProducer:lowPtGsfElePfTracks module in step3 on top of the same warnings coming from the already existing PFTrackProducer:pfTrack and PFTrackProducer:uncleanedOnlyPfTrack, already present also in the baseline.

[perrotta]

@fabiocos , maybe you want to squash before merging, to get rid of the extra 100 k added to the git repository, see #25679 (comment)

[fabiocos]

+operations

confirming previous signature

[fabiocos]

@ssekmen the update posterior to your signature looks transparent to fastsim to me, could you please verify and sign it again or comment in case?

[ssekmen]

+1

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @davidlange6, @slava77, @smuzaffar, @fabiocos (and backports should be raised in the release meeting by the corresponding L2)

[fabiocos]

+1

[perrotta]

Is this "rho_" ever needed? It doesn't seem so.
This introduces a circular dependency, because you claim consuming some product which is only produced later in the chain

[perrotta]

This also seems not to be used.
Please check this, and all other parameters