If you configure Moore().HltType with Hlt2 in the + separated list, the Hlt2 configuration is invoked after Hlt1 -- so you can specify Hlt1+Hlt2 (the default).


An Hlt2Line follows the concept of a HltLine. That means each Hlt2Line should be self contained, except that
  • It is acceptable for an Hlt2Line to depend on the output of an Hlt1Line.
  • It is acceptable to create prescaled monitoring lines for the intermediate steps of a bigger Hlt2Line, for example to monitor the K* in B->μμK*

Example in Python

from Gaudi.Configuration import *
from HltConf.HltLine import Hlt2Line, Hlt2Member
from Hlt2SharedParticles.Kstar import Kstar2KPi
from Hlt2SharedParticles.DiMuon import DiMuon
from Configurables import CombineParticles, PhysDesktop

# Define the cuts through the new Hlt2Member incantation
# if we have  a 'recipe' (i.e. an Hlt2Member) instead of a concrete instance,
# it can be modified during cloning: every 'clone' will get a
# unique instance made according to the 'recipe', whereas concrete
# instances will be _shared_ amongst clones
combine = Hlt2Member( CombineParticles  # type
                 , "Combine"      # name -- to be bound to the line name: Hlt2LineNameFilter
                 , DecayDescriptor = "[B0 -> K*(892)0 J/psi(1S)]cc"
                 , CombinationCut = "ADAMASS('B0')<500*MeV"
                 , MotherCut = "(VFASPF(VCHI2/VDOF)<6) & (BPVIPCHI2()<1000) & (BPVDIRA>0.9995)"
                 , InputLocations = [ DiMuon, Kstar2KPi ]  # this gets forwarded to PhysDesktop...

# Define the Hlt2 Line
Hlt2Line('Bd2MuMuKstar' ,  prescale = 1. , algos = [ DiMuon, Kstar2KPi , combine ], postscale = 1.)

Definition of an Hlt2Line

In the example above, the line is defined as
Hlt2Line('Bd2MuMuKstar' ,  prescale = 1. , algos = [ DiMuon, Kstar2KPi , combine ], postscale = 1.)
The syntax is
  • Bd2MuMuKstar: The name of the line, with corresponding decision Hlt2Bd2MuMuKstarDecision.
  • prescale: the line prescale factor. Used to reduce processing time by only running the line every Xth event.
  • algos = : the list of algorithms. Remember to include all the Hlt2SharedParticles you need here. The order of the algorithms matters: the algorithms that are used as input to later CombineParticles/FilterDesktop instances should come first in the list. There is a warning at configure time if someone asks for some input that is not configured to run prior to the algorithm which consumes it, i.e., the HLT code checks that all relevant 'producers' are before their 'consumers' in the algos list.
  • postscale: the line postscale factor. Use to control the output rate.

Hlt2Line and Hlt2Member

Hlt2Lines may contain algorithms and sequencers like a normal sequence, however in the majority of cases they should be made from Hlt2Members. An Hlt2Member is either a CombineParticles or a FilterDesktop step, but creating it as an Hlt2Member enforces a naming convention and modifies the behaviour when the Hlt2Line containing it is cloned. In the example above, the Hlt2Member syntax is
  • CombineParticles: the type of Hlt2Member, either CombineParticles or FilterDesktop. These are configurables so this does not go in quotation marks.
  • "Combine": the local name of this Hlt2Member. Its output location for use within the same line is
    in this case Combine.
Some things to note
  • Do not clone Hlt2Members directly, clone the line they belong to.
  • See the paragraphs below for an explanation of the difference under cloning of Hlt2Members and bare CombineParticles/FilterDesktop instances.

What should and shouldn't be an Hlt2Member

The difference between Hlt2Members are set by the behaviour under 'clone', which is actually a special case of the behaviour of algorithms if they appear in more than one 'line', since cloning is 'just' a convenient way of making multiple lines.

First of all, if in a line there is something which is not an HltMember, and thus it is a 'concrete' instance instead of a recipe, then, when cloned, the clone inserts the same instance, so it will run 'at most' once per event. Note that this implies that such a concrete instance must always do the same thing, no matter which line it appears in -- it can thus not depend on the output of a 'member', as when you clone the line, the 'member' potentially changes, and thus the input to the 'concrete' algorithm changes, which would make it depends on 'where' this concrete algorithm runs 'first'.

So a good example of something that should not be a member would be Hlt2SharedParticles such as a 'shared' Ks -- such as 'shared' Ks -- must always give the same answer no matter which line it runs in, hence such a shared Ks AND its input can NEVER be a member.

On the other hand, almost anything else should be 'unique' to line -- if you clone the line, it should become a new, unique instance in the new line.

  • Example: Imagine a common 'dimuon' sequence (which just combines opposite charged muons, and requires only say a vertex) which you then apply a FilterDesktop on to get J/ψ. Now you want to do the same, except move the masswindow to do psi(2S) -- you want to share the dimuon bit in order to only do the combinatorics once, but the psi(2S) clone of the 'original' J/psi FilterDesktop must be different. The 'dimuon' part is a concrete configurable, and the J/psi becomes a member, so that when the J/psi 'line' -- which includes both the dimuon sequence and the J/psi member -- gets cloned-and-modified, the 'dimuon' bit is the same instance (and just run once) and the psi(2S) filter is the cloned-and-modified version of the J/psi original, and has its own name.

Cloning an Hlt2Line

The syntax for cloning an Hlt2Line is
where modifications is the list of properties to be modified. This also includes any properties you wish to modify in Hlt2Members which belong to the line. To give an example, consider cloning the above line to select high mass combinatorics with a 5% prescale factor. The code is
line.clone('Bd2MuMuKstarHighMass',prescale = 0.05, Combine = {"CombinationCut" : "AM>5379.*MeV"})
Notice that the Hlt2Member "Combine" is being cloned together with the line; as discussed above a new instance of it is being created, which inherits all the properties of the instance being cloned and modifies those in the array on the right-hand side of the equals sign. If you wish to modify multiple properties of Hlt2Members, separate them with commas.

Current Hlt2Lines and what they do

NameSorted ascending Description
Hlt2LineB2HH Uses Hlt2Pions to deliberately avoid significance cuts. No "fast-fit" used.
Hlt2LineB2JpsiX_MuMu runs on output of Hlt2LineBiasedDiMuon.
Hlt2LineB2MuTrack Uses Hlt2Muons and Hlt2Pions. No "fast-fit" used.
Hlt2LineB2MuTrackNoPT Same as Hlt2LineB2MuTrack but no PT cuts.
Hlt2LineB2TwoBody Uses almost every shared state there is to inclusively search for '2-body' decays. No "fast-fit" used.
Hlt2LineBd2D0Kstar Uses shared D0 (Hlt2GoodPions/Kaons) and K* (Hlt2GoodPions/Kaons). No "fast-fit" used.
Hlt2LineBd2JpsiK Uses Hlt2Kaons/Pions on purpose to avoid IP cuts on the individual daughers. Also uses SeqHlt2SharedHighPtJpsi2MuMu. No "fast-fit" used.
Hlt2LineBd2JpsiKstar Uses Hlt2Kaons/Pions on purpose to avoid IP cuts on the individual daughers. Also uses SeqHlt2SharedHighPtJpsi2MuMu. No "fast-fit" used.
Hlt2LineBd2JpsiMuMuKsDDBiased Uses output of Hlt2SharedJpsi2MuMu and does the seeding required to make DD Kshorts, but no "fast-fit". The Jpsi part should probably be made common with Hlt2LineBd2JpsiMuMuKsLLBiased.
Hlt2LineBd2JpsiMuMuKsDDUnbiased Same as Hlt2LineBd2JpsiMuMuKsDDBiased except lifetime cuts replaced by harder PT cuts. Same comment about merging Jpsi with that of Hlt2LineBd2JpsiMuMuKsLLUnbiased applies.
Hlt2LineBd2JpsiMuMuKsLLBiased Uses output of Hlt2SharedJpsi2MuMu and Hlt2SharedKsLL. No "fast-fit" used.
Hlt2LineBd2JpsiMuMuKsLLUnbiased Same as Hlt2LineBd2JpsiMuMuKsLLBiased except lifetime cuts replaced by harder PT cuts.
Hlt2LineBd2MuMuKstar uses Hlt2Muons, Hlt2GoodPions/Kaons. No "fast-fit" used.
Hlt2LineBiasedDiMuon uses Hlt2SharedDiMuon, meaning Hlt2Muons. No "fast-fit" used.
Hlt2LineBs2EtacPhi Uses Hlt2SharedRho0 and Hlt2SharedPhi2KK. No "fast-fit" used.
Hlt2LineBs2JpsiEta Uses Hlt2Photons and Hlt2Muons. No "fast-fit" used and cannot work with one at present due to problem with large Z states.
Hlt2LineBs2JpsiEtap Uses Hlt2GoodPions and Hlt2SharedJpsi2MuMu. No "fast-fit" used.
Hlt2LineBs2JpsiPhi Uses Hlt2Kaons on purpose to avoid IP cuts on the individual daughers. Also uses SeqHlt2SharedHighPtJpsi2MuMu. No "fast-fit" used.
Hlt2LineBs2PhiGamma Uses Hlt2Photons and shared Phi2KK (Hlt2GoodKaons). No "fast-fit" used and cannot work with one at present due to problem with large Z states.
Hlt2LineBs2PhiPhi Uses shared Phi2KK (Hlt2GoodKaons). No "fast-fit" used.
Hlt2LineBu2D0K_KPi Uses Hlt2SharedD02KPi and Hlt2GoodKaons. No "fast-fit" used.
Hlt2LineBu2D0K_KsDD Uses Sean's staged method of making the DD Kshorts. Uses Hlt2GoodPions/Kaons and does the seeding required to make DD Kshorts, but no "fast-fit".
Hlt2LineBu2D0K_KsHH Uses shared D02KSXX particles (Hlt2GoodKaons,Hlt2KsLLParticles,Hlt2SharedKsLL). No "fast-fit" used.
Hlt2LineBu2LLK Uses Hlt2GoodKaons, Hlt2Electrons, and Hlt2Muons. No "fast-fit" used. "Mondrian" style selection with four regions: "whole phase space aka paranoia", "signal", "Jpsi", and "HighMass"
Hlt2LineDrellYan Same as Hlt2LineUnbiasedDiMuon and Hlt2LineUnbiasedJPsi but selects DrellYan dimuons.
Hlt2LineDstar uses normal Hlt2Pions/VTTPions for the slow pion, Hlt2GoodPions/Kaons for the D0 daughters. No "fast-fit" used.
Hlt2LineHidValley Uses private code in Hlt2HidValley and PatPV3D. No idea what happens internally.
Hlt2LineInclusivePhi Uses Hlt2Kaons to create a phi with robust cuts, then performs a fast-fit (currently a bidirectional 1-pass Kalman with smoothing resulting in a new container called Hlt/Track/IncPhiTFForward). These tracks are used to create kaons and finally phis using error-based cuts (IP significance, vertex chi2). The RICH information is generated for the tracks of the surviving events, resulting in kaons with RICH PID cut. These are used to create the final phi particles.
Hlt2LineTopological Uses Hlt2Pions and Kaons, selects 2,3, and 4 body combinations of them, then performs a fast-fit (currently a unidirectional 1-pass Kalman with no smoothing), then selects 2,3, and 4 body combinations using the fitted tracks. Copies tracks to a new container called Hlt/Track/TFForwardForTopo before fitting them.
Hlt2LineUnbiasedBs2PhiPhi Uses shared UnibiasedPhi2KK (Hlt2Kaons). No "fast-fit" used.
Hlt2LineUnbiasedDiMuon Uses output of Hlt2SharedDiMuon. No "fast-fit" used.
Hlt2LineUnbiasedJPsi Same as Hlt2LineUnbiasedDiMuon but selects JPsi.
Hlt2LineZ02MuMu Uses output of Hlt2SharedDiMuon. No "fast-fit" used.

-- StephanNies - 12 Apr 2009

This topic: LHCb > LHCbTrigger > Hlt2Line
Topic revision: r6 - 2009-06-18 - GreigCowan
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2022 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