Tau customization for Phase2 #19788
Tau customization for Phase2 #19788
Conversation
|
A new Pull Request was created by @mbluj for master. It involves the following packages: RecoTauTag/RecoTau @perrotta, @cmsbuild, @slava77, @davidlange6 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
|
please test |
|
The tests are being triggered in jenkins. |
|
assign upgrade |
|
New categories assigned: upgrade @kpedro88 you have been requested to review this Pull request/Issue and eventually sign? Thanks |
|
+1 The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic: |
|
Comparison job queued. |
|
Comparison is ready Comparison Summary:
|
|
+1 |
|
@mbluj : when applying this PR a larger nr of combinatoricRecoTaus is visible (see for example below the event size of those branches in wf 20034.0_TTbar_14TeV+TTbar_14TeV_TuneCUETP8M1_2023D17) or, B new, B delta, B delta, % deltaJ, % branch 8757.7 -> 11607.1 2849 28.0 0.32 recoPFTaus_combinatoricRecoTausBoosted__RECO. 893860 -> 903921 10061 1.1 ALL BRANCHES This is also visible in the jenkins outputs, e.g.:
Is it compatible with the reduced number of fake taus that you claim in the description? |
|
Hello,
@mbluj <https://github.com/mbluj> : when applying this PR a larger nr of
combinatoricRecoTaus is visible (see for example below the event size of
those branches in wf 20034.0_TTbar_14TeV+TTbar_14TeV_TuneCUETP8M1_2023D17)
------------------------------
or, B new, B delta, B delta, % deltaJ, % branch
------------------------------
8757.7 -> 11607.1 2849 28.0 0.32 recoPFTaus_combinatoricRecoTausBoosted__
RECO.
1136.3 -> 1091.2 -45 -4.0 -0.01 recoPFTaus_hpsPFTauProducerSansRefs__RECO.
1171.9 -> 1149.5 -22 -1.9 -0.00 recoPFTaus_hpsPFTauProducer__RECO.
24962.2 -> 32230.0 7268 25.4 0.81 recoPFTaus_combinatoricRecoTaus__RECO.
------------------------------
893860 -> 903921 10061 1.1 ALL BRANCHES
This is also visible in the jenkins outputs, e.g.:
[image: image]
<https://user-images.githubusercontent.com/4069749/28584420-f2b97b34-716c-11e7-98ec-147abba0f3ae.png>
Is it compatible with the reduced number of fake taus that you claim in
the description?
Hmm... This question touches a few related issues rather than unique one. I
will try to explain them below.
1. Technically HPS PFTaus are built in several stages
a) Firstly all possible (and sensible) combinations of charged hadron and
pizero (strips) candidates corresponding with a given seeding jet are built
and stored as combinatoricRecoTaus. "Sensible combination" means such a
combination which has at least one charged hadron.
b) In the second step (so called cleaning step) the best combination is
selected (one per seeding jet) and stored as hpsPFTauProducerSansRefs. Then
PiZeros embedded into the PFtau candidate are replaced by Refs to PiZeros
stored in a separate product forming hpsPFTauProducer (PFTaus) and
hpsPFTauProducer_pizeros (RecoTauPiZeros)
c) The third step is identification (usually applied at analysis level)
when a set of discriminants is applied, like constraints at tau decay mode
products (so-called decay-mode finding) and isolation, to discriminate
against fakes.
2. Figure of merit in tuning of the tau reco&id is performance, i.e. signal
efficiency vs fake rate at the stage c), i.e. with at least some loose Id
criteria applied rather than number of combinatoric taus (number of
possible ch. hadron - pi0 combinations). In this particular fix, size of
strips (pi0's) is fixed which prevent that they eat too much neutral PU
energy. In a consequence, final taus have better energy scale and number of
fakes is reduced as it is more difficult to build a sensible tau candidate.
On the other hand, it is possible to build more strips (they are smaller)
hence number of combinations (combinatoricTaus) increases. This is what can
be seen in the printout above: number of combinatoricRecoTaus increases
while number of hpsPFTauProducer[SansRefs] decreases. Number of slimmedTaus
in MiniAOD passing loose-Id (decay mode finding with new decay modes) decreases even
more. The effect was not checked earlier, but it is in fact expected.
3. Intermediate products, i.e. combinatoricRecoTaus and
hpsPFTauProducerSansRefs should not be stored and it looks it is the case
(see RecoTauTag/Configuration/python/RecoTauTag_EventContent_cff.py).
4. BoostedTaus (represented by combinatoricRecoTausBoosted in the listing
above): they are built in the same manner as above, but are seeded by
sub-jets of fat-jets rather than by jets itself. In addition, they belong to
(pre)MiniAOD sequences rather than to regular RECO sequences and their
non-PAT products are not supposed to be stored.
I hope it answers the question.
Best,
Michał
|
|
Thank you Michal of confirming that the effect of this PR is the one expected. |
|
+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 requires discussion in the ORP meeting before it's merged. @davidlange6, @smuzaffar |
|
merge |
As title says: it is customization for Phase2 upgrade studies at high-PU. It consists of two modifications compared to the Run-2 baseline:
The modifications do not affect standard workflows, while for Phase2 ones at high-PU a lower number of fake-taus (with e.g. QCD, ttbar samples) esp. at lower-Pt is expected.
Some further details in slides here:
Backport to 92X and 91X will follow shortly.