New thresholds for gathering and seeding in PF in EE, and deactivation of SR@PF #21846
Conversation
…n of SRatPF in EB and EE
|
@amassiro, CMSSW_10_0_X branch is closed for direct updates. cms-bot is going to move this PR to master branch. |
|
The code-checks are being triggered in jenkins. |
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-21846/2867 |
|
A new Pull Request was created by @amassiro (Andrea Massironi) for master. It involves the following packages: RecoParticleFlow/PFClusterProducer @perrotta, @cmsbuild, @slava77 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
|
@cmsbuild please test |
|
The tests are being triggered in jenkins. |
| name = cms.string("PFRecHitQTestECALMultiThreshold"), | ||
| thresholds = particle_flow_zero_suppression_ECAL.thresholds | ||
| name = cms.string("PFRecHitQTestThreshold"), | ||
| threshold = cms.double(0.08) |
There was a problem hiding this comment.
I didn't realize that we have an issue in the barrel as well.
In case I missed something, please point me to some plots that quantify degradation in the barrel.
|
SR@PF issues also in the barrel had been raised by Tau POG, see for example the report at the PPD general meeting on the 14th Dec: |
|
Comparison job queued. |
|
Comparison is ready @slava77 comparisons for the following workflows were not done due to missing matrix map:
Comparison Summary:
|
|
@amassiro @crovelli |
| seedingThreshold = cms.double(0.6), | ||
| seedingThresholdPt = cms.double(0.15) | ||
| seedingThreshold = cms.double(0.50), | ||
| seedingThresholdPt = cms.double(0.50) |
There was a problem hiding this comment.
do we have any Z->ee plots to show that this increase is OK?
I can imagine that shower or brem cases can degrade quite a bit.
@Sam-Harper what do you think?
There was a problem hiding this comment.
So we discussed this at length in the ECAL+E/gamma meeting with jetMET. JetMET need these thresholds to control the MET. For E/gamma, they are likely not ideal (although the results could be surprising with PU contributions), for the reasons you say. The plan is to check if it really causes a major (and it has to be major) problem for E/gamma although given the timeline, they may not complete in time for pre4 in which case we'll just go ahead.
If 10_0_0 has slightly worse performance in the endcap at low pt, its no big deal, we'll fix it next release. The samples we will need in 10_0_0 will be for energy regressions and we save the raw for those so in a pinch we can always re-reco them ourselves with new settings.
|
On 1/16/18 6:20 AM, crovelli wrote:
Hi Slava,
the main use case to increase the gathering and seeding thresholds
(see the original PR) is the MET rate,
which was too high at the end of the 2017 data taking with the current
configuration. All the involved
groups agree that increasing the thresholds degrades the resolution,
both of electromagnetic objects and
of jets - so MET is the only use case, basically.
At the moment it seems there is no agreement on the better thresholds
to mitigate the issue without
damaging the resolution, but probably eta-dependent thresholds can
help in this in the future.
So we prepared the code to have
- exactly the same gathering and seeding thresholds as last year
- the rechit thresholds eta-dependent but low (80MeV and 300 MeV
respectively in EB and EE)
In this way, as soon as some thresholds are defined the switch should
be fast and also the further
tests should be easier. The idea is that high thresholds can be
applied at rechits level (if needed)
in the future (even if this is probably not optimal, as commented by
Emanuele and Josh) and this is the
reason to apply the 80/300 MeV cuts on all the rechits and not only to
those in zero suppression.
With this updated PR we go back exactly to the 2016 configuration.
Hi Chiara,
I sort of follow the explanation, but only as long as the cuts on all
the rechits stay at 80/300 MeV level.
Once there is a need to increase these thresholds, I think that the same
logic goes back in place: if ZS threshold is high, the egamma reco in
the high interest regions should keep low thresholds and the remaining
JME objects *not in high interest* to follow the tighter cuts.
So, quite likely the srFlags will be needed again.
… This leaves the MET issue unsolved
for now anyway (~test1 in Yutaro's slide) and to be addressed in the
next futur with updated thresholds,
or solving the issue with changes to the MET algos directly.
We can discuss this further at 5pm, if needed.
On Tue, Jan 16, 2018 at 3:05 PM, Slava Krutelyov ***@***.***>
wrote:
> On 1/16/18 3:00 AM, Andrea Massironi wrote:
> > The new commit has:
> >
> > * ***@***.*** deactivated
> > * gathering and seeding thresholds as in 2016
> >
> > From a technical point of view:
> >
> > * thanks to Slava's suggestion, we have prepared the eta dependent
> > thresholds on the rechits using the ***@***.*** piece of code, but
> > applying the cut on all rechits and not only the ones that are
> > ZeroSuppressed online
>
> Is this well motivated?
> I don't recall issues for the high-interest region areas reported earlier.
> Perhaps I missed something.
>
>
> > * the thresholds vs eta set are currently all the same (effectively no
> > eta dependence), but they can be set eta dependent according to the
> > needs for high level objects performance
> >
|
|
@cmsbuild please test in hope that 136.7611 file I/O error is transient. |
|
The tests are being triggered in jenkins. |
|
Comparison job queued. |
|
Comparison is ready @slava77 comparisons for the following workflows were not done due to missing matrix map:
Comparison Summary:
|
|
@slava77, @fabozzi,
can you please explain in detail what needs to be done ? Examples ? I think no one in Ecal has experience with this task.
… On 16 Jan 2018, at 18:07, Slava Krutelyov ***@***.***> wrote:
@amassiro @crovelli
please prepare a customise_command or a customise method to be able to go back to the previous ***@***.*** selections.
IIUC, this was needed for alternative relval submissions ***@***.*** ).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
On 1/17/18 1:47 AM, argiro wrote:
@slava77, @fabozzi,
can you please explain in detail what needs to be done ? Examples ? I
think no one in Ecal has experience with this task.
we can start with a list of "process.xyz = zyt" python statements needed
to go back to the default.
This is needed only in case the "SR@PF ON" relval will be requested.
…
> On 16 Jan 2018, at 18:07, Slava Krutelyov ***@***.***>
wrote:
>
> @amassiro @crovelli
> please prepare a customise_command or a customise method to be able to
go back to the previous ***@***.*** selections.
> IIUC, this was needed for alternative relval submissions ***@***.*** ).
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or mute the thread.
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#21846 (comment)>, or
mute the thread
<https://github.com/notifications/unsubscribe-auth/AEdcboBUPhmslgwwmEPA4Z-bcXKcgJVlks5tLcGegaJpZM4Rc3P0>.
|
|
The last updates look more healthy for egamma: e.g. 10 GeV photon gun The simulated (~empty detector) ECAL noise seems to stay under control, as seen e.g. in a mu gun 10 GeV Electrons look OK. In ZEE with PU there is some increase at low pt jet response in the flat-pt spectrum also looks OK in the endcap (not much change in the barrel) compare to the initial submission of this PR In my test of ZEE with PU 100 events MET looks OK (stats are low): a comparison with genMET perhaps there is still a remaining issue for the rates with a significant MET as suggested in the previous discussion, but it's not visible in the bulk or in small stat tests. Anyways, we are going back to the "good old" that we have used in 2016. |
|
+1
|
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 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) |
|
Hi Slava,
Cheers, |
|
@crovelli @argiro @slava77 @amassiro Instead, if it is just a matter of changing cfg parameters of the process (i.e. the list of statements "process.xyz = zyt") we can try to do that on the fly, with a customise_command in the cmsDriver of the relval steps. You do not need to commit anything, just list the needed statements. |
|
@fabozzi we need to follow up on this point, but I suggest this is done in a separate PR. I now integrate the present one. |
|
+1 |
Deactivation of SR@PF for 2018.
80 MeV in EB and 300 MeV in EE in ZS regions is applied (negligible given the seeding and gathering thresholds, see below).
Update of PF ECAL cluster thresholds: seeding (500 MeV in E_T) and gathering (500 MeV in E_T) in EE.
EB thresholds for PF ECAL cluster are left untouched.
See the minutes of Fri 12th Jan meeting for details: https://indico.cern.ch/event/662757/attachments/1582189/2500613/EGM-ECAL_Minutes_120118.pdf
@argiro @crovelli