Closed ktht closed 3 years ago
Regarding VBF jets, I think there's a bug in SL channel. Here the VBF jets are cleaned wrt the W->jj jets as identified by the JPA: https://github.com/HEP-KBFI/hh-bbww/blob/e150814bf5e47401524ac52d2d5a3a75137421c2/bin/analyze2_hh_bb1l.cc#L1948 The AK4 jets that are cleaned wrt the selected H->bb AK8 jet is done here: https://github.com/HEP-KBFI/hh-bbww/blob/e150814bf5e47401524ac52d2d5a3a75137421c2/bin/analyze2_hh_bb1l.cc#L1698 But the jets that enter the cleaning are central jets: https://github.com/HEP-KBFI/hh-bbww/blob/e150814bf5e47401524ac52d2d5a3a75137421c2/bin/analyze2_hh_bb1l.cc#L1314 I believe this is by a mistake. I'll reorganize the code a bit because in the synchronization we agreed to record the number of VBF jets:
Hi Karl,
sorry, I don't understand where you see a problem. The AK4 jets that are selected by the JPA are central AK4 jets (|eta| < 2.4). The VBF jets are cleaned wrt the AK4 jets selected by the JPA in these lines: https://github.com/HEP-KBFI/hh-bbww/blob/e150814bf5e47401524ac52d2d5a3a75137421c2/bin/analyze2_hh_bb1l.cc#L1942-L1957 This looks correct to me.
This part is ok, the problem I think is that cleanedJetsAK4_wrtHbb
originates from
https://github.com/HEP-KBFI/hh-bbww/blob/e150814bf5e47401524ac52d2d5a3a75137421c2/bin/analyze2_hh_bb1l.cc#L1698
where selJetsAK4
are defined here:
https://github.com/HEP-KBFI/hh-bbww/blob/e150814bf5e47401524ac52d2d5a3a75137421c2/bin/analyze2_hh_bb1l.cc#L1314
The jetSelectorAK4_wPileupJetId
selector does not include jets beyond the acceptance region:
https://github.com/HEP-KBFI/hh-bbww/blob/e150814bf5e47401524ac52d2d5a3a75137421c2/bin/analyze2_hh_bb1l.cc#L644-L645
So, if I'm reading the code correctly, it only considers central jets as the VBF jets in the boosted category.
The pT cut on VBF jets was set to 30 GeV in commit 8d614f1f82eb32adf16582e896e15f8b92368e09 but there is no explanation why the pT cut was raised: https://github.com/HEP-KBFI/hh-bbww/blob/e150814bf5e47401524ac52d2d5a3a75137421c2/bin/analyze2_hh_bb2l.cc#L650 Was this cut taken from bbtautau analysis, maybe?
In any case, the pT cut in our gitlab is still at 25 GeV, so I'll change it back to 25 in my PR, too. Other groups have already synchronized in the VBF jet variables, but we're not.
edit: indeed, the pT > 30 GeV cut was mentioned in bbtautau AN (AN2018/121v4, L291)
Hi Karl,
the VBF jet pT > 30 GeV cut was indeed taken from the HH->bbtautau analysis (cf. slide 5 of https://indico.cern.ch/event/963619/contributions/4118889/attachments/2149275/3623492/statusReport_24_11_2020.pdf ). I would prefer if we keep using the 30 GeV cut for VBF jets, if we can convince the Aachen and Louvain groups to switch to 30 GeV, for two reasons: 1) It will make the documentation and combination of datacards easier if we use the same VBF jet cuts as the HH->bbtautau analysis 2) The VBF jets are reconstructed outside of the tracking acceptance, so are more affected by pileup and potential miscalibration and/or noise of the calorimeters. My understanding is that the official JetMET recommendation is to use jets of pT > 30 GeV (for b-jets/jets within the tracking acceptance, we get permission to reduce the pT threshold to 25 GeV, because central jets depend more on the track reconstruction and are less affected by pileup and potential miscalibration and/or noise of the calorimeters)
Thank you, Christian. I had no strong preference before because we already apply PU jet ID cut also on the VBF jets, so reducing the pT cut by 5 GeV shouldn't make much difference. But I take your point that it's best to keep the common definitions across different HH analyses as similar as possible. I'll let the other groups know that we should use pT > 30 GeV cut for the VBF jets.
Before it slips off from my mind: need to include preselected VBF jets when computing the PU jet ID SF. Although it's a bit of an open item as to which jet collection should we use:
I think that 2. is the most accurate choice here because it would be more-or-less on the same footing with the cuts that the central jets are required to pass when entering the SF calculation.