Tau fixes to mini-to-mini #49318
Tau fixes to mini-to-mini #49318
Conversation
…ctly from the original mini
|
cms-bot internal usage |
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-49318/46680 |
|
A new Pull Request was created by @mbluj for master. It involves the following packages:
@battibass, @cmsbuild, @ftorrresd, @jfernan2, @mandrenguyen, @srimanob can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
|
enable nano |
|
please test |
|
@cms-sw/btv-pog-l2 -- would you mind to please check? Thanks |
|
Adding @AlexDeMoor and @acalandr as the new BTV L2 |
Thanks! I believe it has to be updated at: https://github.com/cms-sw/cms-bot/blob/0b1fbd423aa0e6246c85eb986728c997c8226dd8/categories.py |
|
+1 Size: This PR adds an extra 28KB to repository Comparison SummarySummary:
Nano size comparison Summary:
NANO Comparison SummarySummary:
|
|
To follow on the question related to BTV @mbluj , "Question for BTV experts: In the proposed setup all deep-flavour taggers are added to the CHS AK4 jets (DeepBTag, DeepFlavour, ParticleNet, RobustParTAK4, and UnifiedParTAK4). Is it fine, or should only a subset be kept? Should it be era dependent? Note that for taus only ParticleNet (central) is necessary." Why do you want to continue running on CHS jets at all ? We discontinued it for most of the taggers in BTV since the beginning of Run3 and JME also discontinued its calibration so they are out of usage at all from my understanding (pinging @nurfikri89 to have some JME expertise on the question). Then my question extends about how the hybrid tau collection is built. Don't you start from puppi jets for this now ? Are CHS needed at all ? A last point on the taggers, if you need only 1 specific tagger please run only this one (here PNET) because nobody will use the prediction results of the others anyway. This will spare runtime during the mini-step |
Trying to answer one by one, starting from TAU perspective and then going to more general picture:
|
|
Are there any comments or questions to this PR? For me the only remaining one is which "deep" jet-taggers should be produced and embedded to CHS-jets in re-mini-v6 ( It could be that there are also some technical comments about implementation. |
|
+1 |
|
@ftorrresd, is there something missing in this PR? |
|
@mbluj -- I believe keeping the compatibility among the different ways to produce MiniAODv6 samples is the driving factor at this moment. Your PR is already aligned with this, right?! |
@ftorrresd, thank you for confirmation that the compatibility with genuine MINIv6 is a goal here. I believe that the compatibility is preserved by this PR, but it will be good to get confirmation about jet-taggers for CHS jets from BVTV @cms-sw/btv-pog-l2. Please let me also know if you want me to clean the configuration, for instance to remove the "FIXME" comments. |
|
For compatibility reasons I agree to keep CHS in the mini-to-mini. However, I want to give my honest opinion about CHS in the context of Run3 here. As it is not maintained anymore by either JME or BTV in term of physics properties (jet pt, JEC/JES, etc) nor tagger, I would strongly advice to move forward to a single CHS+PUPPI collection in the future. In particular, we could discuss the jet tau efficiency in the incoming month as, from my understanding, is still a key element of why CHS remains 'superior' to PUPPI (the jet tau reconstruction efficiency is about 95% for CHS jets of 20-30 GeV vs 85-97% for PUPPI v18 iirc). This is beyond this PR ofc, but I want to leave a trace of this discussion for future |
I totally agree even though I don't understand well what is a CHS+PUPPI collection :) Obviously to be discussed towards Run3 NANO v16 (which could happen) and beyond. |
|
+xpog |
cmsbuild
added
fully-signed
xpog-approved
and removed
pending-signatures
xpog-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. @ftenchini, @mandrenguyen, @sextonkennedy (and backports should be raised in the release meeting by the corresponding L2) |
|
+1 |
7 participants
PR description:
This is a followup development to the mini-v2/v4 to mini-v6 (#49098), which fixes issues related to (boosted)taus.
These issue were spot when comparing the outputs of the nano-v15 produced using two different workflows: one based on the mini-v6 from the mini-v2/v4 (re-mini wf) and the other produced directly from the mini-v2/v4 (direct wf), as documented here.
There were two types of issue:
The first issue was caused by the use of different collections of pf-candidates with different puppi tunes in the DeepTauID input: in the direct wf pf-candidates with "original" puppi weights were used while in the re-mini wf pf-candidates with with updated puppi were used. These two approaches lead to comparable, but not identical DeepTauID responses, the differences are especially important for jet-like tau candidates (low vsjet scores). The fix was to use pf-candidates with "original" puppi weights.
Fixing the former issue required the addition of "hybrid" taus, i.e. a mixture of taus reconstructed by HPS reconstruction and taus tagged by unified jet taggers. Modern deep-flavour taggers were added to the CHS AK4 jet collection (slimmedJets) to make this work. These taggers are anyway present in the "genuine" mini v6 with CMSSW_15_0 (Summer24 production) therefore adding them makes re-mini v6 more similar to the "genuine" version, although they are not necessary for nano v15 where CHS jets are not stored.
Question for BTV experts: In the proposed setup all deep-flavour taggers are added to the CHS AK4 jets (DeepBTag, DeepFlavour, ParticleNet, RobustParTAK4, and UnifiedParTAK4). Is it fine, or should only a subset be kept? Should it be era dependent? Note that for taus only ParticleNet (central) is necessary.
PR validation:
Checked with private wfs as set this tool and with the standard wfs 2500.0401-4 and 2500.0501-3 as follows:
runTheMatrix.py -l 2500.0401,2500.0402,2500.0403,2500.0404,2500.0501,2500.0502,2500.0503 -i all --ibeosIf this PR is a backport please specify the original PR and why you need to backport that PR. If this PR will be backported please specify to which release cycle the backport is meant for:
To be backported to whichever release it is needed - probably all down to 15_0. Experts please comment!