L1T Consumers Migration from Legacy to Upgrade #156

mulhearn · 2016-02-17T01:42:06Z

This issue will cover the migration of most downstream consumers of L1T output. Three major updates are expected:
v1) Covering Basic Access of Unpacked L1T Data
v2) Covering Access via HLT Trigger Filter Object
v3) Covering Migration for consumers of GtUtils
This is update v1.

The topic branch for this issue is:
https://github.com/cms-l1t-offline/cmssw/tree/l1t-downstream-demo
There's a PR for this topic here:
cms-sw#13319

Currently, using a recent integration build is required. This requirement will disappear once 800 is available later this week.

The recipe for building the demonstration code is:

cmsrel CMSSW_8_0_X_2016-02-15-2300
cd CMSSW_8_0_X_2016-02-15-2300/src
cmsenv
git cms-merge-topic cms-l1t-offline:l1t-downstream-demo
scram b -j 8

To run the demo:
cmsDriver.py L1TBasicDemo -s L1REPACK:Full,RAW2DIGI --era=Run2_2016 --conditions=auto:run2_data -n 10 --data --filein=/store/data/Run2015D/ZeroBias/RAW/v1/000/260/627/00000/00A76FFA-0C82-E511-B441-02163E01450F.root --no_output --customise=L1Trigger/L1TCommon/customiseDemo.L1TBasicDemo --no_exec
cmsRun L1TBasicDemo_L1REPACK_RAW2DIGI.py

If useful, one can use the config file generated above as a starting point for code testing downstream modules.

The useful example code is all contained in this file:
https://github.com/cms-l1t-offline/cmssw/blob/l1t-downstream-demo/L1Trigger/L1TCommon/plugins/L1TBasicDemo.cc

For which we extract the useful pieces.

Includes:

#include "DataFormats/L1Trigger/interface/EGamma.h"
#include "DataFormats/L1Trigger/interface/Tau.h"
#include "DataFormats/L1Trigger/interface/Jet.h"
#include "DataFormats/L1Trigger/interface/Muon.h"
#include "DataFormats/L1Trigger/interface/EtSum.h"
#include "DataFormats/L1Trigger/interface/EtSumHelper.h"

Build Files:

<use name="DataFormats/L1Trigger"/>

Token Definitions:

  edm::EDGetTokenT<l1t::EGammaBxCollection> egToken_;
  edm::EDGetTokenT<l1t::TauBxCollection>    tauToken_;
  edm::EDGetTokenT<l1t::JetBxCollection>    jetToken_;
  edm::EDGetTokenT<l1t::EtSumBxCollection>  sumToken_;
  edm::EDGetTokenT<l1t::MuonBxCollection>   muonToken_;

and Initialization:

  egToken_   = consumes<l1t::EGammaBxCollection> (iConfig.getParameter<edm::InputTag>("EgTag"));
  tauToken_  = consumes<l1t::TauBxCollection>    (iConfig.getParameter<edm::InputTag>("TauTag"));
  jetToken_  = consumes<l1t::JetBxCollection>    (iConfig.getParameter<edm::InputTag>("JetTag"));
  sumToken_  = consumes<l1t::EtSumBxCollection>  (iConfig.getParameter<edm::InputTag>("SumTag"));
  muonToken_ = consumes<l1t::MuonBxCollection>   (iConfig.getParameter<edm::InputTag>("MuonTag"));

and configuration (in python config file for module):

    EgTag            = cms.InputTag("caloStage2Digis"),
    TauTag           = cms.InputTag("caloStage2Digis"),
    JetTag           = cms.InputTag("caloStage2Digis"),
    SumTag           = cms.InputTag("caloStage2Digis"),
    MuonTag          = cms.InputTag("gmtStage2Digis", ""),

and retrieval from the event

  edm::Handle<l1t::EGammaBxCollection> eg;
  iEvent.getByToken(egToken_, eg);
  //...
  edm::Handle<l1t::TauBxCollection> tau;
  iEvent.getByToken(tauToken_, tau);
  //..
  edm::Handle<l1t::JetBxCollection> jet;
  iEvent.getByToken(jetToken_, jet);
  //...
  edm::Handle<l1t::MuonBxCollection> muon;
  iEvent.getByToken(muonToken_, muon);

a typical loop over candidates:

  edm::Handle<l1t::MuonBxCollection> muon;
  iEvent.getByToken(muonToken_, muon);
  if (muon.isValid()){
    for (int ibx = muon->getFirstBX(); ibx <= muon->getLastBX(); ++ibx) {
      if (trigger_bx_only && (ibx != 0)) continue;
      for (auto it=muon->begin(ibx); it!=muon->end(ibx); it++){
        if (it->et() == 0) continue; // if you don't care about L1T candidates with zero ET.                                                                                
        cout << "bx:  " << ibx << "  et:  "  << it->et() << "  eta:  "  << it->eta() << "  phi:  "  << it->phi() << "\n";
      }
    }
  } else {
    edm::LogWarning("MissingProduct") << "L1Upgrade muon bx collection not found." << std::endl;
  }

for convenience energy sums have a helper interpreter class:

  edm::Handle<l1t::EtSumBxCollection> sum;
  iEvent.getByToken(sumToken_, sum);
  if (sum.isValid()){
    l1t::EtSumHelper hsum(sum);
    cout << "met:     " << hsum.MissingEt() << "\n";
    cout << "met phi: " << hsum.MissingEtPhi() << "\n";
    cout << "mht:     " << hsum.MissingHt() << "\n";
    cout << "mht phi: " << hsum.MissingHtPhi() << "\n";
    cout << "sum et:  " << hsum.TotalEt() << "\n";
    cout << "sum ht:  " << hsum.TotalHt() << "\n";
  } else {
    edm::LogWarning("MissingProduct") << "L1Upgrade sum bx collection not found." << std::endl;
  }

The text was updated successfully, but these errors were encountered:

mulhearn · 2016-02-17T01:43:05Z

Need to add examples for additional variables, e.g. Isolation... in the morning.

mulhearn · 2016-02-17T01:50:34Z

@apana @bortigno @fwyzard you are interested in this topic I believe.

bortigno · 2016-02-17T08:00:13Z

yes! thank you Mike! this is great news. I guess Len can advertise it at his talk today?

On 17 Feb 2016, at 02:50, mulhearn [email protected] wrote:

@apana @bortigno @fwyzard you are interested in this topic I believe.

—
Reply to this email directly or view it on GitHub.

mulhearn · 2016-02-17T08:54:22Z

Yes that's fine. Personally, I don't think we should start a Twiki until things settle down more. I prefer github for works in progress.

Martin-Grunewald · 2016-02-19T11:49:53Z

@mulhearn
Can you please specify more details on the l1extra replacement:
the new collections contain all bx, while l1extra contained only a single
set of objects - I assume for the central bx? So IOW, an equivalent
l1extra replacement would be to ONLY access bx=0 objects in the new
scheme?

mulhearn · 2016-02-21T21:45:06Z

Well, L1Extra had the capability to include extra BX as well:
https://github.com/cms-l1t-offline/cmssw/blob/l1t-dev-recipe-CMSSW_8_0_0_pre6/L1Trigger/L1ExtraFromDigis/interface/L1ExtraParticlesProd.h#L75
and to be honest I really don't know if this functionality was ever used outside of L1T...

Martin-Grunewald · 2016-02-24T08:42:37Z

@mulhearn
Indeed - at HLT we used:

process.hltL1extraParticles = cms.EDProducer( "L1ExtraParticlesProd",
    tauJetSource = cms.InputTag( 'hltCaloStage1LegacyFormatDigis','tauJets' ),
    etHadSource = cms.InputTag( "hltCaloStage1LegacyFormatDigis" ),
    isoTauJetSource = cms.InputTag( 'hltCaloStage1LegacyFormatDigis','isoTauJets' ),
    etTotalSource = cms.InputTag( "hltCaloStage1LegacyFormatDigis" ),
    centralBxOnly = cms.bool( True ),
    centralJetSource = cms.InputTag( 'hltCaloStage1LegacyFormatDigis','cenJets' ),
    etMissSource = cms.InputTag( "hltCaloStage1LegacyFormatDigis" ),
    hfRingEtSumsSource = cms.InputTag( "hltCaloStage1LegacyFormatDigis" ),
    produceMuonParticles = cms.bool( True ),
    forwardJetSource = cms.InputTag( 'hltCaloStage1LegacyFormatDigis','forJets' ),
    ignoreHtMiss = cms.bool( False ),
    htMissSource = cms.InputTag( "hltCaloStage1LegacyFormatDigis" ),
    produceCaloParticles = cms.bool( True ),
    muonSource = cms.InputTag( "hltGtDigis" ),
    isolatedEmSource = cms.InputTag( 'hltCaloStage1LegacyFormatDigis','isoEm' ),
    nonIsolatedEmSource = cms.InputTag( 'hltCaloStage1LegacyFormatDigis','nonIsoEm' ),
    hfRingBitCountsSource = cms.InputTag( "hltCaloStage1LegacyFormatDigis" )
)

so ONLY the central BX.

kirschen · 2016-02-24T16:17:29Z

Hi all,

I am trying to port
https://github.com/cms-sw/cmssw/blob/CMSSW_8_1_X/HLTrigger/JetMET/src/HLTJetL1MatchProducer.cc#L23-L25

In the HLT .py-config, the input tags are the following:
L1CenJets = cms.InputTag( 'hltL1extraParticles','Central' ),
L1ForJets = cms.InputTag( 'hltL1extraParticles','Forward' ),
L1TauJets = cms.InputTag( 'hltL1extraParticles','Tau' ),

However, I am not sure how this translates to the new caloStage2Digis... Is there a "translation table" for these beyond the basic list you gave in the initial post?

Cheers,
Henning

Martin-Grunewald · 2016-02-24T16:25:31Z

Central and Forward are combined into Jets.
Taus are still labeled Taus.

edm::EDGetTokenT<l1t::TauBxCollection>    tauToken_;
edm::EDGetTokenT<l1t::JetBxCollection>    jetToken_;

See at the beginning of this issue for more C++ snippets.

kirschen · 2016-02-24T16:43:13Z

Hi Martin,
ok, so while in stage1, the taus were always "jets", they are now "taus" in terms of collection names...

Maybe, if the snippets at the beginning include the old equivalent as well, it would be more straightforward for others as well.

As I understand it now, e.g.
https://github.com/cms-sw/cmssw/blob/CMSSW_8_1_X/HLTrigger/JetMET/src/HLTJetL1MatchProducer.cc#L23
would have to change from
m_theL1TauJetToken = consumesl1extra::L1JetParticleCollection(L1TauJets_);
to
m_theL1TauJetToken = consumesl1t::TauBxCollection(L1TauJets_);
? In the new version I would change the name to remove any "Jet" from everything related to "Tau", then.

Cheers,
Henning

apana · 2016-02-24T16:57:04Z

Hi Henning,

I don't think you should be using the Tau collections in the
HLTJetL1MatchProducer anymore. If I understand correctly, this code is
trying to match HLT jets with L1 jets.

In the past (legacy system), taus were included in the L1 Jet algorithm
(e.g. L1_SingleJetXX), so you needed to include the taujet collection when
doing the matching.

However, in stage2 (and stage1!), taus are no longer included in the L1 Jet
algorithm, and so I don't think the tau collections should be used in the
matching.

Cheers,
Len

On Wed, Feb 24, 2016 at 5:25 PM, Martin Grunewald [email protected]
wrote:

Central and Forward are combined into Jets. Taus are still labeledTaus.

edm::EDGetTokenTl1t::TauBxCollection tauToken_;
edm::EDGetTokenTl1t::JetBxCollection jetToken_;

See at the beginning of this issue for more C++ snippets.

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

kirschen · 2016-02-24T21:29:51Z

Hi Len,

ok, I see. I will simplify the new version to only read in a single L1 jet collection. Actually I am not sure what the matching is really good for in the paths that use it, but anyway...

I managed to change the old module such that it reads in the Stage2Digis and passes. However, another thing that is not straightforward in the snippets of the inital post is that the input tags are NOT "caloStage2Digis", but "hltCaloStage2Digis"!

I will post to the hlt-dev HN next with a quick status summary...

Cheers,
Henning

fwyzard · 2016-02-24T22:04:03Z

On 24 February 2016 at 22:29, kirschen [email protected] wrote:

Actually I am not sure what the matching is really good for in the paths
that use it, but anyway...

The idea is that, if your HLT path is seeded by L1 jets, you want to make
sure that the HLT jets you reconstruct match the L1 jets that are
responsible for selecting the event in the first place.
The reason being that otherwise you get "volunteers" in, which could make
it much harder to estimate the trigger efficiencies.

.A

kirschen · 2016-02-24T22:32:57Z

Hi Andrea,
ok, that sounds like a reasonable approch. However, it seems like not so many paths are actually using this kind of approach?
Cheers,
Henning

fwyzard · 2016-02-25T02:49:11Z

I know... let's discuss this next Wednesday.

Martin-Grunewald · 2016-02-25T17:39:01Z

Beware of the new enums:

    TriggerL1Mu           = -81,
    TriggerL1NoIsoEG      = -82, // legacy and stage1
    TriggerL1IsoEG        = -83, // legacy and stage1
    TriggerL1CenJet       = -84, // legacy and stage1
    TriggerL1ForJet       = -85, // legacy and stage1
    TriggerL1TauJet       = -86, // legacy and stage1
    TriggerL1ETM          = -87,
    TriggerL1ETT          = -88,
    TriggerL1HTT          = -89,
    TriggerL1HTM          = -90,
    TriggerL1JetCounts    = -91, // legacy and stage1
    TriggerL1HfBitCounts  = -92, // legacy and stage1
    TriggerL1HfRingEtSums = -93, // legacy and stage1
    TriggerL1TechTrig     = -94,
    TriggerL1Castor       = -95,
    TriggerL1BPTX         = -96,
    TriggerL1GtExternal   = -97,
    TriggerL1EG           = -98, // stage2
    TriggerL1Jet          = -99, // stage2
    TriggerL1Tau          =-100, // stage2

mulhearn added the URGENT label Feb 18, 2016

Martin-Grunewald mentioned this issue Mar 6, 2016

Hlt hcal movemodulestol1t cms-sw/cmssw#13596

Merged

mulhearn removed the URGENT label May 12, 2016

mulhearn closed this as completed May 12, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

L1T Consumers Migration from Legacy to Upgrade #156

L1T Consumers Migration from Legacy to Upgrade #156

mulhearn commented Feb 17, 2016

mulhearn commented Feb 17, 2016

mulhearn commented Feb 17, 2016

bortigno commented Feb 17, 2016

mulhearn commented Feb 17, 2016

Martin-Grunewald commented Feb 19, 2016

mulhearn commented Feb 21, 2016

Martin-Grunewald commented Feb 24, 2016

kirschen commented Feb 24, 2016

Martin-Grunewald commented Feb 24, 2016

kirschen commented Feb 24, 2016

apana commented Feb 24, 2016

kirschen commented Feb 24, 2016

fwyzard commented Feb 24, 2016

kirschen commented Feb 24, 2016

fwyzard commented Feb 25, 2016 via email

Martin-Grunewald commented Feb 25, 2016

L1T Consumers Migration from Legacy to Upgrade #156

L1T Consumers Migration from Legacy to Upgrade #156

Comments

mulhearn commented Feb 17, 2016

mulhearn commented Feb 17, 2016

mulhearn commented Feb 17, 2016

bortigno commented Feb 17, 2016

mulhearn commented Feb 17, 2016

Martin-Grunewald commented Feb 19, 2016

mulhearn commented Feb 21, 2016

Martin-Grunewald commented Feb 24, 2016

kirschen commented Feb 24, 2016

Martin-Grunewald commented Feb 24, 2016

kirschen commented Feb 24, 2016

apana commented Feb 24, 2016

kirschen commented Feb 24, 2016

fwyzard commented Feb 24, 2016

kirschen commented Feb 24, 2016

fwyzard commented Feb 25, 2016 via email

Martin-Grunewald commented Feb 25, 2016