• MET = vector sum of Et
  • sumEt = scaler sum of Et
  • HT = scalar sum of jet Et (sumEt of jets)
  • MHT = vector sum of jet Et (jetMET)

  • EDM = Event Data Model

  • hypo = hypothesis; handles the actual decision if an event is kept or not. Defined in Trigger/TrigHypothesis packages
  • fex = feature extraction. Defined in Trigger/TrigAlgorithms packages
  • FEB = Front End Board

  • BS = Bytestream: The ‘raw’ data stream from the front end electronics.
  • RDO = Raw Data Object: Collections of data related to the layout of the front-end electronics and readout systems.
  • PRD = Prepared Raw Data: Collections of data related to the geometric layout of ATLAS.


(Comment from TJ)
I want to stress that we never use the raw PFOs for HLT jets, offline jets or offline MET. I would hope that HLT MET is also not using the bare PFOs but that is more for you to comment on.

Instead, we create the “CHSParticleFlowObjects” shallow copy collection (offline is actually moving to a new type called FlowElement which functions similarly) which have a variety of important corrections and/or decorations applied, and whose four-vectors are “final” i.e. ready to use for calculations w/o further operations. This comprises the following operations:
  • Origin correction for neutral PFOs
  • Weighting to emulate smoothly turning off energy subtraction (improves JES for EM-scale PFOs)
  • Weighting to switch off subtraction in dense environments (the envWeight decoration you note)
  • Decoration with PVMatched flag to indicate if the PFO should be used in jet-finding

An example of this being set up in master (old-style jobOptions) is here:
with the underlying config being here:
The CorrectPFOTool applies the first three, while the matching is handled by the ChargedHadronSubtraction tool.

It’s also worth noting that if constituent modifiers are applied to the PFOs, these are “sandwiched” between the CorrectPFOTool (always applied first) and the ChargedHadronSubtractionTool (always last). Any such modifiers that are used for pileup suppression (e.g. CS, SK) should be set to only operate on neutral PFOs.

Trigger chain execution

This is an order of a trigger chain execution.
Take HLT_xe120_trkmht_xe50_L1XE50 (PS=100) as an example:
  1. All Events
  2. L1_XE50
  3. HLT Prescale
  4. cell FEX
  5. cell>50 Hypo
  6. trkmht FEX (plus creation of all inputs such as full scan fast tracks)
  7. trkmht > 120 Hypo

The HLT trackmht xAOD container is filled at step 6.

Trigger Tower

   If an L1A is received, we read out the L1Calo subsystems (PPM, CPM, JEM etc) which provide various informations. The trigger towers are usually provided by the PPMs. For each of the 7168 towers (well, actually more because also spare towers are read out) you will get 5 ADC values (can also be more if we are in special run configuration), two LUT values (these are the towers energies sent to the CP and JEP systems), a pedestal correction value and various BCID bits. 

   Above quantities do not include any additional thresholds, and for the most towers in an event your Et values (i.e. the LUTs) will be zero and the ADC values close to the pedestal of 32, i.e. not containing a pulse. However, for our derivations we do indeed apply thinning, i.e. remove towers from the collection which are below a certain ADC value. So indeed, your second phrasing is correct.

I can add some code to Martin's nice explanation. I think for what you want to do, you need to loop over the TriggerTowerContainer (aka DataVector) you retrieve from the storegate and then use the elements of the vector, which are of the xAOD::TriggerTower_v2 class. You can find all methods of this class here .

If you want to check which TriggerTowers passed a given energy threshold you can access the lut information Martin mentioned using ->cpET() and ->jepET(). If you are interested in the ADCs you can use ->adc() which will give you a vector containing the 5 ADC values. The BCID bits can be accessed ->bcidVec() and the pedestalCorrection with ->correction(). If you want to identify the tower you are looking at you can use ->coolId() to retrieve the unique ID each tower has.

And just for clarity, if cpET() or jepET() are non-zero that means that in the triggered bunch-crossing the tower (a) passed the noise threshold and (b) passed the BCID condition.

If you want to know which passed the noise cut irrespective of whether they passed BCID that's much harder (and not of much practical use).

Although we read out all towers to the RAW, it's possible that the tower collection in the ESD is zero-suppressed to save space, i.e. towers with both cpET() and jepET() equal to zero are removed (we've also used other criteria in the past, such as in addition including towers where the ADC sample in the triggered crossing was above some minimum), though we've often included the full collection in a random sample of events in these cases. It's easy to tell: if the number of towers in the event is 7168 then there is no zero suppression. If it's a fraction of that, the collection is zero-suppressed.

Trigger Bias

ZeroBias events: e_ZB
Events passed L1XE50: e_L1XE50_ZB
Events passed any L1 trigger: e_L1ALL_ZB
Events passed HLT MET P chain seeded by L1XE50: e_HLTxeP_L1XE50_L1ALL_ZB
Since e_L1XE50_L1ALL_ZB = e_L1XE50_ZB, this is equivalent to
Events passed HLT MET P chain seeded by L1XE50: e_HLTxeP_L1XE50_ZB

L1_XE50 rate is the rate of e_L1XE50_ZB ~5k Hz
HLT MET P rate is the rate of e_HLTxeP_L1XE50_ZB ~50 Hz
So, the pass rate is r1 = e_HLTxeP_L1XE50_ZB/e_L1XE50_ZB ~1e-2

If we analyze Physics_Main data:
Events in the Physics_Main is: e_HLTALL_L1ALL_ZB
Events passed L1_XE50: e_L1XE50_HLTALL_L1ALL_ZB
Events passed HTL MET P chain seeded by L1XE50: e_HLTxeP_L1XE50_HLTALL_L1ALL_ZB
Since e_L1XE50_L1ALL_ZB = e_L1XE50_ZB,
Events passed L1_XE50: e_L1XE50_HLTALL_ZB
Events passed HTL MET P chain seeded by L1XE50: e_HLTxeP_L1XE50_HLTALL_ZB
Similarly, e_HLTxeP_HLTALL_ZB = e_HLTxeP_ZB. This gives
Events passed HTL MET P chain seeded by L1XE50: e_HLTxeP_L1XE50_ZB
So, the pass rate is r2 = e_HLTxeP_L1XE50_ZB/e_HLTALL_L1XE50_ZB
As you can see, the ratio r2 is different form r1 because of the extra HLTALL requirement in the denominator.
The r2 is larger than r1 because of this.

If we analyze JETM10 data:
Events in JETM10 is: e_HLTnoalgL1XEALL_HLTALL_L1ALL_ZB
where ALL include the ones with threshold lower than or equal to 50.
Events passed L1_XE50: e_L1XE50_HLTnoalgL1XEALL_HLTALL_L1ALL_ZB
Events passed HTL MET P chain seeded by L1XE50: e_HLTxeP_L1XE50_HLTnoalgL1XEALL_HLTALL_L1ALL_ZB
Since e_L1XE50_L1ALL_ZB = e_L1XE50_ZB and e_HLTnoalgL1XEALL_HLTALL_ZB = e_HLTnoalgL1XEALL_ZB,
Events passed L1_XE50: e_L1XE50_HLTnoalgL1XEALL_ZB
Events passed HTL MET P chain seeded by L1XE50: e_HLTxeP_L1XE50_HLTnoalgL1XEALL_ZB
The L1XE50_HLTnoalgL1XEALL is a subset of the L1XE50 depending on the prescale of the HLTnoalgL1XE chains. If we let k be the scale factor,
Events passed L1_XE50: k * e_L1XE50_ZB
Events passed HTL MET P chain seeded by L1XE50: k * e_HLTxeP_L1XE50_ZB

The pass rate is given by the ratio of these two and equal to r1. So, we recover r1.

Now, consider HLT without L1 case:
HLT rate without L1 is given by R1 = e_HLTxeP_ZB/e_ZB

If we don’t require L1XE50 on JETM10
Events in JETM10 is: e_HLTnoalgL1XEALL_HLTALL_L1ALL_ZB
Events passed HTL MET P chain: e_HLTxeP_HLTnoalgL1XEALL_HLTALL_L1ALL_ZB
These are equal to
Events in JETM10: e_HLTnoalgL1XEALL_L1ALL_ZB
Events passed HTL MET P chain: e_HLTxeP_HLTnoalgL1XEALL_L1ALL_ZB
The pass rate is

Since the MET shape of e_HLTnoalgL1XEALL_L1ALL_ZB is quite different from ZB (biased by L1 and HLTnoalgL1X), the R2 is different from R1.

ZeroBias trigger

There are HLT_noalg_L1ZB and HLT_j40_L1ZB.
Both have the same L1 trigger: Find a bunch that has an electron trigger above some Pt (I don't remember which electron trigger off hand) and use this same number bunch crossing the next time it comes around. This provides a luminosity dependent but random trigger.
HLT_noalg has no HLT trigger requirements. HLT_j40 requires a 40 GeV jet at HLT.
The events selected with each of these triggers is sent to the zero-bias stream.

One has to have the correct luminosity weighting. But this is already wrong for MET regardless of prescale. Let me explain: The ZB trigger uses an electron with some Pt cut to select a bunch crossing, and then the next time this bunch crossing happens the data is selected for the ZB trigger. This weighting makes sense for triggers that are linearly proportional to instantaneous luminosity. But the dependence is much stronger for MET, so that linear weighting is wrong. If one wants to correctly luminosity weight ZB triggers for MET the only way to do so is to do a luminosity dependent analysis and then to sum them according to integrated luminosity. I suggest that we forget trying this and just use the ZB events as they are. But in that case the prescales can be ignored. In the little playing I have done with this for the variables I am interested in the prescale weighting makes a difference, but not a tremendous one.

EnhancedBias (EB) trigger

MinimumBias trigger

Various MET

xAOD trigger MET containers

  • CELL: HLT_xAOD__TrigMissingETContainer_TrigEFMissingET
  • TC: HLT_xAOD__TrigMissingETContainer_TrigEFMissingET_topocl
  • TC PS: HLT_xAOD__TrigMissingETContainer_TrigEFMissingET_topocl_PS
  • TC PuFit: HLT_xAOD__TrigMissingETContainer_TrigEFMissingET_topocl_PUC
  • MHT: HLT_xAOD__TrigMissingETContainer_TrigEFMissingET_mht
  • FEB: HLT_xAOD__TrigMissingETContainer_TrigEFMissingET_FEB (currently empty)
  • FEB: HLT_xAOD__TrigMissingETContainer_TrigL2MissingET_FEB
There are 9 components in ex and ey:
  • TCLCWB1: hadronic calibrated topocluster in Barrel eta>0 region
  • TCLCWB2: hadronic calibrated topocluster in Barrel eta<0 region
  • TCLCWE1: hadronic calibrated topocluster in End cap eta>0 region
  • TCLCWE2: hadronic calibrated topocluster in End cap eta<0 region
  • TCEMB1: EM calibrated topocluster in Barrel eta>0 region
  • TCEMB2: EM calibrated topocluster in Barrel eta<0 region
  • TCEME1: EM calibrated topocluster in End cap eta>0 region
  • TCEME2: EM calibrated topocluster in End cap eta<0 region
  • Muons

D3PD Trigger level MET variables

  • trig_L1_esum_* -> L1 MET if the event was triggered at L1
  • trig_L2_met_* -> L1 MET if the event was rerun
  • trig_L2_feb_met_* -> Actual L2 FEB MET if the event was triggered at L2
  • trig_EF_met_* -> EF cell met
  • trig_EF_feb_met_* -> L2 FEB MET if the event was rerun
  • trig_EF_topocl_met_* -> EF tclcw MET, the EM version can be constructed from the components

So we should use trig_L2_met for L1, trig_EF_feb_met for L2 FEB, and trig_EF_topocl_met for EF Tclcw.

Trigger level MET

  • TCLCW = trig_EF_topocl_met : EF trigger level MET based on topo cluster with local weight = hadronic calibration
  • TCMC = EM Cluster : EF trigger level MET based on topo cluster with em calibration
= sqrt((trig_EF_topocl_met_MExComponent[4]+trig_EF_topocl_met_MExComponent[5] +trig_EF_topocl_met_MExComponent[6]+trig_EF_topocl_met_MExComponent[7])**2 +(trig_EF_topocl_met_MEyComponent[4]+trig_EF_topocl_met_MEyComponent[5] +trig_EF_topocl_met_MEyComponent[6]+trig_EF_topocl_met_MEyComponent[7])**2)/1000
  • FEB = trig_EF_feb_met : 2012 default L2 algorithm, as calculated at the EF stage for rerun.
  • FEB Calib : calibrated version of FEB using a simple set of layer-by-layer calibration constants (using Andrew's constants determined from some MC12 sample)
tree_AS->Draw("sqrt((2.36*Trig_efmetx_FEB_presamplB+2.74*Trig_efmetx_FEB_emb1 +2.64*Trig_efmetx_FEB_emb2+3.24*Trig_efmetx_FEB_emb3+3.40*Trig_efmetx_FEB_presamplE +2.18*Trig_efmetx_FEB_eme1+2.78*Trig_efmetx_FEB_eme2+4.08*Trig_efmetx_FEB_eme3 +1.73*Trig_efmetx_FEB_hec+1.96*Trig_efmetx_FEB_TileBar+0.36*Trig_efmetx_FEB_TileExt +2.08*Trig_efmetx_FEB_FCalEM+2.48*Trig_efmetx_FEB_FCalHad1+2.88*Trig_efmetx_FEB_FCalHad2)*(2.36*Trig_efmetx_FEB_presamplB+2.74*Trig_efmetx_FEB_emb1+2.64*Trig_efmetx_FEB_emb2 +3.24*Trig_efmetx_FEB_emb3+3.40*Trig_efmetx_FEB_presamplE+2.18*Trig_efmetx_FEB_eme1 +2.78*Trig_efmetx_FEB_eme2+4.08*Trig_efmetx_FEB_eme3+1.73*Trig_efmetx_FEB_hec +1.96*Trig_efmetx_FEB_TileBar+0.36*Trig_efmetx_FEB_TileExt+2.08*Trig_efmetx_FEB_FCalEM +2.48*Trig_efmetx_FEB_FCalHad1+2.88*Trig_efmetx_FEB_FCalHad2)+(2.36*Trig_efmety_FEB_presamplB+2.74*Trig_efmety_FEB_emb1+2.64*Trig_efmety_FEB_emb2 +3.24*Trig_efmety_FEB_emb3+3.40*Trig_efmety_FEB_presamplE+2.18*Trig_efmety_FEB_eme1 +2.78*Trig_efmety_FEB_eme2+4.08*Trig_efmety_FEB_eme3+1.73*Trig_efmety_FEB_hec +1.96*Trig_efmety_FEB_TileBar+0.36*Trig_efmety_FEB_TileExt+2.08*Trig_efmety_FEB_FCalEM +2.48*Trig_efmety_FEB_FCalHad1+2.88*Trig_efmety_FEB_FCalHad2)*(2.36*Trig_efmety_FEB_presamplB+2.74*Trig_efmety_FEB_emb1+2.64*Trig_efmety_FEB_emb2 +3.24*Trig_efmety_FEB_emb3+3.40*Trig_efmety_FEB_presamplE+2.18*Trig_efmety_FEB_eme1 +2.78*Trig_efmety_FEB_eme2+4.08*Trig_efmety_FEB_eme3+1.73*Trig_efmety_FEB_hec +1.96*Trig_efmety_FEB_TileBar+0.36*Trig_efmety_FEB_TileExt+2.08*Trig_efmety_FEB_FCalEM +2.48*Trig_efmety_FEB_FCalHad1+2.88*Trig_efmety_FEB_FCalHad2))/1000.>>l2metfebcalib",BG7CUT);

  • EF Cell : EF algorithms based on summing the ~200k calorimeter cells. This is what we had in 2011 before we used clustering.

Offline MET

  • LocHadTopo = MET_LocHadTopo : offline version of TCLCW
  • RefFinal
  • RefFinal Caro parts : RefFinal minus muons

XS trigger

  • Trigger on MET significance
  • MET significance = MET/[a + b*sqrt(SumET) + c*(SumET)]
    because resolution σ = a + b*sqrt(SumET) + c*(SumET)
  • At 2015 Oct 06, a = 4.93182, b = 0.442864, c = 0

TE trigger

  • te = total energy
  • L1_MBTS_1_1: MBTS triggers are minbias indeed. They correspond to very forward scintillators, two on the left side of the detector, two on the right side. 1_1 means that at least one on each side saw a signal in sync with the other side, to trigger out non-collision bkg. This is minbias, because it fires on any activity, but it nevertheless has a small eta-dependence, so it is not zero bias.
  • L1_TE_0ETA24: only the energy with eta<2.4 is accounted for in the energy sum.

-- KenjiHamano - 22 Aug 2014

Edit | Attach | Watch | Print version | History: r20 < r19 < r18 < r17 < r16 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r20 - 2021-04-02 - KenjiHamano
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Main All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright &© 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback