How to add a selection (preselection, offline selection)


This page explains how to register a preselection to be run in the stripping. It is assumed you are familiar with the concept of stripping and preselection. Else see the stripping how-to page.

The same applies if you want to add an offline selection for the trigger tuning. Or to train the tagging, or anything else. We encourage anyone to release the offline selection. There are a lot of people developing tools that need to be optimised with respect to a given offline selection.

The page first lists the requirements your preselection must meet in order to be considered and then details the procedure.


There are about 50 preselections run in parallel in a job. This imposes constraints on cpu time, memory usage and naming. You can run an algorithm called Presel in your own DaVinci job. That will not work when there are 50 other algorithms.


The preselection must be written in options using released code. We want to avoid running user code in the stripping as much as possible. Of course there will be exceptions. Here two cases have to be considered
  • You are missing a functionality in DaVinci. Inform the DaVinci mailing list about it. If no workaround is provided write a tool or algorithm that does what you need in such a way that it could be used by other users in the future. I.e. extend the functionality! Typical examples are missing FilterCriteria.
  • Your channel is so special that the standard algorithms don't work. In such a case a dedicated algorithm is acceptable. There are a few examples. Here again, try to write it in such a way that it could be configured to do other similar selections.
  • You are encouraged to use the new CombineParticles and LoKi::Hybrid syntaxes. See LoKiHybridFilters for more details.

I already have working code, why would I bother translating it to a syntax I don't like? Because you are not maintaining DaVinci and hence you don't have to deal with portability, robustness...


You typically write a selection doing B -> X Y [...], where B, X, Y stand for any particles and then X -> U V [...]. X is likely to be needed in another preselection, and we ask you to share intermediate and final states among preselections.
  • This minimises CPU by avoiding to remake the same particles several time.
  • It generates discussion between people interested in the same particles, allowing less experienced physicists to learn how not to select some particles (although it looked so clean in the nTuple...)
  • It maximises the compatibility between signal and control channels sharing some intermediate state.
  • It maximises the correlation between the preselection and the trigger where intermediate states will be shared.

For preselections

Hence the preselection must use standard particles as provided in the CommonParticles package. If something is missing, provide it. If you don't like what's in there, start a discussion in the physics WGs.

It is clear that some preselections need to be tighter than others. That some care about lifetime biases and others don't. There are thus loose and tight standard particles in most cases. There may also be biased and unbiased ones.

For offline selections

For offline selections, you have more freedom. But still you probably want to make sure that you apply the same cuts for your signal and control channels. We thus encourage you to make your intermediate state particles standard and provide a StdTightXXX selection.

Naming convention

Let's say you want to write a selection for B -> X Y with X -> U V. A typical name for the channel would be B2XY_X2UV. But sometimes X2UV is implicit, like all K* go to K+pi- as we probably won't ever see a K* to K0pi0. Examples are Bd2MuMuKstar, Bs2JpsiPhi, Dstar2D0Pi_D02HHHH. Make sure your channel name is unique.


Assume your channel name is B2XY_X2UV, then
  • The final preselection algorithm must be called PreselB2XY_X2UV,
  • It is recommended to put it in a sequencer. In such a case, the sequencer must be called SeqPreselB2XY_X2UV.
  • *All your selection should be in a file called * DoPreselB2XY_X2UV.opts. You can include subfiles from there.
    • This is the file users who want to use your selection as a reference will include. It should just add a sequence to the work flow but not override anything (hence the naming conventions).
  • The main preselection option file must be called DVPreselB2XY_X2UV.opts. It should include DaVinciCommon.opts, DoPreselB2XY_X2UV.opts and some test data. * This is the file users who just want to run your selection will use as main file.

Offline selections

The same as above applies. Just replace Presel by DC06Sel (whatever appropriate). The best way to make sure you only look at events that are preselected is to start from your preselection and refine. As an example here's the B+ -> eeK selection file DoDC06SelBu2eeK.opts:

#include "$B2DILEPTONROOT/options/DoPreselBu2LLK.opts"
 * refine
SeqPreselBu2LLK.Members += { "FilterDesktop/DC06SelBu2eeK",
   "PrintHeader/PrintDC06SelBu2eeK" };
DC06SelBu2eeK.PhysDesktop.InputLocations  = {"Phys/PreselBu2LLK" };
DC06SelBu2eeK.FilterCriterion = "LoKi::Hybrid::FilterCriterion" ;
/** Offline cuts
 *  B+ : Vertex chi2 < 20 / (3 DoF)
 *       Flight distance > 10 sigma
 *       IP < 5 sigma
 *       Flight angle < 0.81 degrees (cos>0.9999)
 *  ee : Mass^2 < 6 GeV^2
 *       Flight distance > 5 sigma
 *       IP > 2 sigma
 *  e  : PT > 1 GeV
 *       ID DLL > 6
 *  K  : PT > 1.4 GeV

DC06SelBu2eeK.Filter.Code = "(VFASPF(VCHI2/VDOF)<6.67)
                           & (MINTREE(ABSID=='K+',PT)>1400)
                           & ( 2 == NINTREE( (ABSID=='e-') & (PT>1000) & (PIDe>6)& (MIPCHI2DV(PRIMARY)>4) ))
                           & (INTREE( (ID=='J/psi(1S)') & (MM<2449) & (BPVVDCHI2>25) ) )
                           & (BPVVDCHI2>100)
                           & (BPVIPCHI2()<25)
                           & (BPVDIRA>0.9999)" ;


The best package into which to put your preselection depends on the intermediate states. Discuss it with the preselection managers.


Presently preselections have to accept less than 1/1000 on BB inclusive events. This is very loose. In the real world it will be closer to 1/10000. Typically each WG will get a few Hz output rate of the stripping on real data.

For offline selections you mostly care about B/S. Anything beyond 1 Hz on MB (i.e. 1 event in a million on L0-accepted MB) is unreasonable.


There is no strict timing constraint, but the most time consuming preselections are likely to be asked to reduce their time. The best way of avoiding the problem is to apply Pt and IP cuts before making vertices.


Once you preselection is ready. Follow the steps to get it into a release:
  1. Test it and make sure the rate is correct.
  2. Present it in a WG and get it approved by the working group.
  3. Give it to the working group preselection coordinator who will check it is compliant and put it in cvs.

The preselection coordinators are, as far as they have been defined:

WG Coordinator
CP Patrick Spradlin
Rare Decays Ulrik & Andrey
TPM Adlčne Hicheur
Jets Victor Coco
Production Eric Conte

Don't send options to the coordinators which have not been approved in a meeting. Don't even think about sending options to Juan or Patrick.

-- PatrickKoppenburg - 01 Aug 2007 -- PatrickKoppenburg - 16 Aug 2007 -- PatrickKoppenburg - 03 Apr 2008

Edit | Attach | Watch | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r6 - 2008-04-03 - unknown
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LHCb 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