Notes on DaVinci option files, in alphabetic order.

Other sources of help:

Background Categories (BKGCAT)

The background categories, that are computed by the truth matching on MC and classify the candidates into signal and various backgrounds, are documented here: background category
  • If all candidates are in BKGCAT 60 (ghosts), you maybe forgot to include DaVinci().Simulation = True.
  • BKGCAT.pdf: A flowchart for the background categories (by Vava)


  • Note: This was tested in DaVinci v33r5. PROBABLY OUTDATED in newer versions.
  • Branches are also described in LHCb/DaVinciTutorial7.

DecayTreeTuple writes out an ntuple (TTree) that contains one entry per candidate. Its variables are grouped in 'Branches': the mother particle's variables, the first daughter particle's variables, and so on. Each particle is therefore a Branch. This Branch structure just configures what variables will be in the ntuple, not to be confused with TBranch.

Sometimes, e.g. to save disk space, you may wish to have different TupleTools for each particle in the decay tree. Another use case is to have a few instances of the same TupleTool, but in different configurations. To do that, you can 'add' branches, overriding the existing ones. In the most easy case, each branch consists of one particle. It can be configured like a DecayTreeTuple.

Here is how you define a branch that contains only the K+ particle:

from DecayTreeTuple.Configuration import *
tuple = DecayTreeTuple("tuple")
tuple.addBranches({ "MyBranch" : "B_s0 -> (J/psi(1S) => mu+ mu-) (phi(1020) -> ^K+ K-)" })

The import statement loads DecayTreeTuple/ .

The old way of adding branches used

# not recommended:
from Configurables import DecayTreeTuple
tuple = DecayTreeTuple("tuple")
tuple.Branches = { "MyBranch" : ... , ... }
tuple.addTool(TupleToolDecay, name = 'MyBranch') 
The new addBranches() method provides a wrapper to the bare 'Branches' member, and does a couple of other things. Now, you can configure your branch.

tuple.MyBranch.ToolList = ["TupleToolPropertime"]


  • The branches inherit all TupleTools which were defined directly for the DecayTreeTuple. Since the latter already contains a few TupleTools by default, this might be very confusing. You might have to set its
tuple.ToolList = []
  • Other than in the root tuple, the head particle is not automatically added to the branch. You need a special syntax to add it to the branch. For reference, refer to the "head" branch in the example below.
  • You can not add the same particle to multiple branches (leads to undefined beviour without causing an error).
  • All particles that should be written out via a branch also have to be marked as "write out" ( using the " ^ "-sign), in the decay string of the DecayTreeTuple. Except for the head particle.


  • Use one separate branch for each particle. The extra typing will lead to clearer code that will save you some confusion in the future.
  • Charges in particle names can cause confusion as you probably also write out the cc process. Some people prefer the 'lab0' syntax, where lab0 is the mother particle, etc.

Now let's go down to business and

# divide the tuple into branches:
      "head" : " B_s0 : B_s0 -> (J/psi(1S) => mu+ mu-) (phi(1020) -> K+ K-)", # Notice the weird syntax for the head
      "KMinus" : "B_s0 -> (J/psi(1S) => mu+ mu-) (phi(1020) -> K+ ^K-)",
      "KPlus" : "B_s0 -> (J/psi(1S) => mu+ mu-) (phi(1020) -> ^K+ K-)",
      "Phi" : "B_s0 -> (J/psi(1S) => mu+ mu-) (^phi(1020) -> K+ K-)",
      "JPsi" : "B_s0 -> (^J/psi(1S) => mu+ mu-) (phi(1020) -> K+ K-)",
      "MuMinus" : "B_s0 -> (J/psi(1S) => mu+ ^mu-) (phi(1020) -> K+ K-)",
      "MuPlus" : "B_s0 -> (J/psi(1S) => ^mu+ mu-) (phi(1020) -> K+ K-)"

# add another tool to the KMinus branch with a different name 

LoKi_KMin.Variables = { 
         "PID" : "ID" , 
         "BPVDIRA" : "BPVDIRA" , 
         "MassDiff_Bs0" : "DMASS('B_s0')" , 
         "VSep" : "MINTREE(ABSID=='J/psi(1S)',VFASPF(VZ))-MINTREE(ABSID=='phi(1020)',VFASPF(VZ))"

# Or maybe you want two branches to have their tools configured in the same way. The best way to do this is with your own function:

def mySharedConf(branch): 
   atool.Variables = { "PID" : "ID" , "P2" : "P*P" , "TrChi2" : "TRCHI2DOF" }


Common Particles (StdLoosePions etc)

The selection cuts that were applied to the common particles are defined here:

SetupProject DaVinci
cd $COMMONPARTICLESROOT/python/CommonParticles/

Database tags

The Detector Description Database and the Conditions Database contain information about the actual configuration the data was recorded with. These contain both geometrical and environmental information. The tags always need to be set.

Running on data:

DaVinci.DDDBtag="dddb-20120831" # update to what you need!
DaVinci.CondDBtag="cond-20120831" # update to what you need!

Running on MC:

Also the MC needs proper database tags that correspond to what the MC was simulated with. They can be obtained from the bookkeeping (SetupProject DaVinci; lhcb_bkk). Also, when running on MC, you need DaVinci().Simulation = True.

DaVinci.DDDBtag="MC11-20111102" # update to what you need!
DaVinci.CondDBtag="sim-20111111-vc-md100" # update to what you need!

  • Note: Is it important on MC, that each magnet-up and magnet-down samples get their 'mu' or 'md' versions of the CONDDB tag.

You can get the correct tags

  • from the bookkeeping: SetupProject DaVinci, lhcb_bkk. Then find your MC files, e.g. sort by Event Type, and click all the way down to the last directory above ALLSTREAMS.DST. Then rightclick for 'more information'. The resulting window hopefully doesn't contain too many tabs, and lists consistent CONDDB and DDDB tags.
  • extract the info from the DST file. For this, see "Print the TES" on this page.


Describe when this needs to be set, and how to obtain the correct settings.

DaVinci().DataType = "2012"


Add a comment about cc's and double counting. When does the mother particle need a cc?

Add a comment about the capitalization of cc.

  • See also: DecayTreeTuple, Branches

[[B0]cc -> (^D- => {^K- ^K+ ^pi-, ^K- ^pi+ ^pi-,^pi+ ^pi- ^pi-}) ^K+]cc

Particle names and numbers

The particle names to be used in the DecayDescriptor are found in a big text file, which you can create follows. This will create the ParticleTable.txt file in the subdirectory param of the current directory, which lists all particles and their properties.

SetupProject LHCb  -c sqlite_file:$SQLITEDBPATH/DDDB.db/DDDB  -s /param/ParticleTable.txt -d ./ -v

The particle numbers, that are used in the lab0_ID fields, follow the official PDG numbering scheme. From PDGlive you can find it as "Reviews, Tables, Plots" -> "Mathematical Tools" -> "Monte Carlo Particle Numbering Scheme", or here directly:

Print the TES

To print the TES, one can use the following simple script:

#! /usr/bin/env python
from Configurables import DaVinci
import GaudiPython

## We configure the job
DaVinci().EvtMax = 0
DaVinci().DataType = "2011"
DaVinci().Simulation = True

## For instance, the dst contains the MC in which we have all the relevant information
DaVinci().Input = ['PFN:root://']

DaVinci().DDDBtag = "MC11-20111102"
DaVinci().CondDBtag = "sim-20111111-vc-md100"

gaudi = GaudiPython.AppMgr()

## The TES will give us access to all the event information
TES = gaudi.evtsvc()

Save it as, then call it with python interactively:

SetupProject DaVinci
python -i

Now, on the python prompt, you can do the following: # process 1st event
TES.dump() # print some TES locations
TES["Rec/Header"] # print CONDDB and DDDB tags

Truth matching

  • See also: Background Categories (BKGCAT)
  • See also: DaVinci tutorials 6, 7

To add truth matching variables to your DecayTreeTuple, add the following tools:

from Configurables import DecayTreeTuple
dataTuple = DecayTreeTuple("dataTuple")
dataTuple.ToolList = [ # pay attention to '=' vs. '+='
  "TupleToolMCTruth" ,
Also make sure you tell DaVinci that you run over MC - otherwise all tracks will be categorized as ghosts!
DaVinci().Simulation = True


  • See also: DecayTreeTuple, Branches

dataTuple.lab0.ProtonHypothesisDsConst.daughtersToConstrain = [ "D_s-" ] 
# ^^ gets both charges, you can also write "D_s+" (but not "D_s" or "[D_s-]cc")

Screen sessions to allow Ganga to run over the weekend

The usual linux 'screen' command doesn't work out of the box because the AFS token will expire and the jobs won't have access to AFS anymore. To prevent his, add this alias to your .bashrc:

alias krb5screen="pagsh.krb -c 'kinit && screen'"

Then start screen as


Later you can reattach later using

screen -raAd

Topic attachments
I Attachment History Action Size Date Who Comment
PDFpdf BKGCAT.pdf r1 manage 480.1 K 2013-09-20 - 14:05 TillMoritzKarbach  
Edit | Attach | Watch | Print version | History: r14 < r13 < r12 < r11 < r10 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r14 - 2020-05-26 - MindaugasSarpis
    • 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-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback