Added PFDiJetCorrCheckerWithDiTau module to remove overlap between di-tau and di-jet for HLT

[namppl]

We would like to introduce a new EDProducer "PFJetsTauCorrelationCondition" which will be used in VBF+2tau triggers [1]. The function of this module is quite similar to the recent PR for 2tau+1jet triggers [2]. The module looks for a combination of (j1, j2, t1, t2) (j1, j2 from PFJet, t1,t2 from the tau collection) that there is no matching between j1,j2 and t1,t2, i.e. they are 4 independent objects, and store j1 and j2.

[1] https://its.cern.ch/jira/browse/CMSHLT-2224
[2] cms-sw#36828

[mbluj]

Dear proponents,
thank you for this development.

You can find my detailed comments inline. What concerns generalities:

• Could you try to change name of the module to more descriptive, please? This module is a producer of a collection of PFJets now overlapping with pairs of taus and forming pairs with a minimal invariant mass - could it be somehow codded in the name of the module?
• The module produces PFJets, but has "hidden" requirement that there are also at least two (filtered) PFTaus in the event - is it what you want? If so it is indeed not only producer, but also correlation condition checker. Anyway more descriptive name could be usefull.
• Please add description what exactly the module does in its header file
• Is there any reason to use global::EDProducer<> instead of stream::EDProducer<>
• After implementing requested code changes please run scram b code-fromat (you can do it also before)
• Remove unnecessary include files, includes not needed in the header file move to the implementation file

[namppl]

Dear Michal,

Many thanks for the detailed comments and sorry for the late response. I was not available last Friday. Your comments have been all implemented.

Best regards,
Kyungwook

[namppl]

• Could you try to change name of the module to more descriptive, please? This module is a producer of a collection of PFJets now overlapping with pairs of taus and forming pairs with a minimal invariant mass - could it be somehow codded in the name of the module?

I would change the name to "PFDiJetCorrCheckerWithDiTau"

• The module produces PFJets, but has "hidden" requirement that there are also at least two (filtered) PFTaus in the event - is it what you want? If so it is indeed not only producer, but also correlation condition checker. Anyway more descriptive name could be usefull.

Yes, the module makes sense only if there are at least 2 jets and 2 taus. "DiJet" and "DiTau" in the new name hopefully clarify that point.

• Please add description what exactly the module does in its header file

I'll add it asap.

• Is there any reason to use global::EDProducer<> instead of stream::EDProducer<>

No, the module processes event by event so it should be fine with stream. It's now stream::EDProducer.

• After implementing requested code changes please run scram b code-fromat (you can do it also before)

Done

• Remove unnecessary include files, includes not needed in the header file move to the implementation file

Done

[mbluj]

Thank you for implementing my changes. The missing thing is a short description (in header file) what the module does. I also spotted that name of configuration argument in l.80 has not been updated -please fix it too.
Finally, I would like to ask you to provide me a recipe (a cfg file) to run the module - I would like to check that it runs w/o failing, but of course I do not pretend to check if it works correctly.

[namppl]

I've fixed L80 and added a description in the header file. I can get my colleague to provide a working version of HLT configuration but it will require some tedious works (merge PRs and tweaks on L1) to run the configuration. We've tested the code works correctly last week and will double-check the updated code also works fine.

[mbluj]

I've fixed L80 and added a description in the header file. I can get my colleague to provide a working version of HLT configuration but it will require some tedious works (merge PRs and tweaks on L1) to run the configuration. We've tested the code works correctly last week and will double-check the updated code also works fine.

Thank you.

Concerning the test configuration: I think you need dump HLT path from ConfDB to cfg, edit it manually to add the new module and provide me the cfg with instruction how to use it. It should be done to be sure that nothing is messed up, but it does not need any very realistic test scenario.

[mbluj]

For records: test configuration was delivered and tests with it are successful => this PR is going to be merged.