HLT single tracker muon trig code

[olivito]

Changes and additions needed to implement a single tracker muon trigger at the HLT. Two plugins are added and HLTTrackWithHits is modified preserving the previous behavior as default.

These changes affect only the HLT and don't touch anything used by offline reco.

[cmsbuild]

A new Pull Request was created by @olivito (Dominick Olivito) for CMSSW_7_1_X.

HLT single tracker muon trig code

It involves the following packages:

HLTrigger/Muon
HLTrigger/special
RecoMuon/TrackerSeedGenerator

@perrotta, @cmsbuild, @nclopezo, @fwyzard, @Martin-Grunewald, @StoyanStoynev, @slava77, @Degano can you please review it and eventually sign? Thanks.
@bachtis, @rociovilar this is something you requested to watch as well.
You can sign-off by replying to this message having '+1' in the first line of your reply.
You can reject by replying to this message having '-1' in the first line of your reply.
@nclopezo, @ktf you are the release manager for this.
You can merge this pull request by typing 'merge' in the first line of your comment.

[Martin-Grunewald]

+1

No changes to physics, only backward-preserving additional features.

[slava77]

Why is this in RecoMuon package?
It reads a L1 trigger object and it writes an L1 trigger object collection.

The functionality seems to be the same as in HLTrigger/Muon/src/HLTMuonL1Filter.cc
Why not use that instead?

[olivito]

Hi Slava,

HLTMuonL1Filter is an HLTFilter while this L1MuonSelector module is an
EDProducer.

The L1 muon candidates are used to create tracking regions. There's a
module CandidateSeededTrackingRegionsProducer which can take in a
collection of candidates to produce the tracking regions. But to select a
subset of the L1 muon candidates to use for tracking regions, I needed to
either (1) produce a filtered collection of L1 muon candidates or (2)
modify the CandidateSeededTrackingRegionsProducer code to be aware of the
HLTFilter decisions. I chose (1) because it seemed simpler.

As for the code location, this package was suggested by the muon HLT
conveners. But I'm fine moving it wherever you think is appropriate.

Thanks,
Dominick

On Wed, Jun 4, 2014 at 12:01 AM, Slava Krutelyov notifications@github.com
wrote:

In RecoMuon/TrackerSeedGenerator/plugins/L1MuonSelector.h:

@@ -0,0 +1,62 @@
+#ifndef RecoMuon_L1MuonSelector_L1MuonSelector_H

Why is this in RecoMuon package?
It reads a L1 trigger object and it writes an L1 trigger object collection.

The functionality seems to be the same as in
HLTrigger/Muon/src/HLTMuonL1Filter.cc
Why not use that instead?

—
Reply to this email directly or view it on GitHub
https://github.com/cms-sw/cmssw/pull/4098/files#r13361802.

[HuguesBrun]

Hello Slava and Dominick,

About the code location, we choose this place as the HLTrigger/Muon package contains for now only filters for HLT. The new producer from Dominick is somehow used to seed the tracking, that is why we though that RecoMuon/TrackerSeedGenerator was the best directory to place it.

Thank you,
Hugues

[fwyzard]

Hi Hugues and Carlo,
unless you suspect that the same module might be used offline, I'd prefer
it to go in the HLTrigger/Muon package: in this way avoid bugging the
Reconstruction conveners for changes to HLT-only code.

.A

On 4 June 2014 10:24, Hugues BRUN notifications@github.com wrote:

Hello Slava and Dominick,

About the code location, we choose this place as the HLTrigger/Muon
package contains for now only filters for HLT. The new producer from
Dominick is somehow used to seed the tracking, that is why we though that
RecoMuon/TrackerSeedGenerator was the best directory to place it.

Thank you,
Hugues

Reply to this email directly or view it on GitHub
#4098 (comment).

[Martin-Grunewald]

If it moves to HLTrigger. then the class name must start with HLT, especially as it
derives from HLTFilter; our naming convention.

[olivito]

Just to clarify, it derives from EDProducer and not from HLTFilter. I can
change the name and move packages if Hugues/Carlo agree.

Dominick

On Wed, Jun 4, 2014 at 10:51 AM, Martin Grunewald notifications@github.com
wrote:

If it moves to HLTrigger. then the class name must start with HLT,
especially as it
derives from HLTFilter; our naming convention.

—
Reply to this email directly or view it on GitHub
#4098 (comment).

[HuguesBrun]

No we don't expect to use it offline, so we don't see any problem to move it in the HLTrigger/Muon package...

Carlo and Hugues

[olivito]

I've moved it to HLTrigger/Muon and renamed it to HLTL1MuonSelector. Now there are no net changes to the RecoMuon area.

[cmsbuild]

Pull request #4098 was updated. @perrotta, @cmsbuild, @nclopezo, @Martin-Grunewald, @fwyzard, @Degano can you please check and sign again.

[cmsbuild]

+1
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-4098/1654/summary.html

[perrotta]

+1
(No changes wrt the already approved one, but the different location of the new module)

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next CMSSW_7_1_X IBs unless changes (tests are also fine). @nclopezo, @ktf can you please take care of it?

[slava77]

my signature is not needed anymore, nice

Regarding using filter objects, we have some other areas (https://cmssdt.cern.ch/SDT/lxr/search?v=CMSSW_7_1_0_pre8&filestring=Reco&string=TriggerFilterObjectWithRefs) where TriggerFilterObjectWithRefs are used directly by producers of seeds.
You would avoid duplication of code to make selections that are done on trigger object inputs and may even benefit from flexibility available in TriggerFilterObjectWithRefs to seed from something else as well.

[cmsbuild]

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-4098/1654/summary.html