A collection of tools for emulating tracker responses. This is a partial reimplementation of the trigger emulation methods described in LHCb-INT-2019-025.
The original implementation are available at B02DplusTauNu.
This repository aims at fully self-containing. Both the BDT training ntuple and a sample ntuple for trigger emulation are provided.
If you want to try out the trigger emulation:
make install
make test-all
Note that you should have Python 3.8+ and ROOT 6.22+ installed.
Currently we have 4 scripts in the scripts folder:
run2-rdx-hlt1.py: Cut-based HLT1Track/TwoTrackMVA emulation. Requires extra branches from DaVincirun2-rdx-l0_global_tis.py: Weight-based L0Global TIS emulation, data-drivenrun2-rdx-l0_hadron_tos.py: Weight-based L0Hadron TOS emulation, with a XGB regressorrun2-rdx-trg_emu.py: Emulate all RDX run 2 triggers in a single script
We supply the following sample ntuples in the samples folder:
run2-rdx-sample.root: FullSim sample for RDX run 2 for testing trigger applicationrun2-rdx-train_bdt.root: Input to train a BDT for L0Hadron TOS (obsolete method)run2-rdx-train_xgb.root: Input to train a XGB for L0Hadron TOS (default method)
This project uses a wrapper to RDataFrame to make definition of process
sequence easier. It also tries to separate C++ code from Python code by
defining C++ functions in separate headers then load them in Python.
The directory structures of this project is:
.
├── davinci # add-on to DaVinci to produce required branches
├── gen # non-saved outputs of scripts
├── nix # nix overlay, currently unused
├── samples # sample input ntuples
├── scripts # actual emulation scripts
└── TrackerOnlyEmu # some Python files
├── emulation # emulation code for analyses, currently just for RDX run 2
└── triggers
├── hlt1 # HLT1 emulation C++ code
└── l0 # L0 emulation C++ code, input ntuples (e.g. HCAL response), and exported BDT/XGBFor the Python module:
-
The
RDataFramewrapper (which is very thin) is defined inTrackerOnlyEmu/executor.py. -
A generic file loader is defined in
TrackerOnlyEmu/loader.py-
This is needed because we also INSTALL C++ code, input ntuples and exported BDT together with the Python package, so we need to be able to load them without knowing their relative location to the emulation scripts.
-
The C++ files are typically loaded with:
load_cpp('<triggers/l0/run2-L0Hadron.h>')
-
If you want to load a file relative to your current script, just drop the
<>:load_cpp('../TrackerOnlyEmu/triggers/l0/run2-L0Hadron.h')
-
We've tested the code work with DaVinci/v45r6. The instructions are adapted from the
original README.md
# Create a new DaVinci dev project
lb-dev DaVinci/<dv_version> # <dv_version> -> v45r6
cd DaVinciDev_<dv_version>
# Checkout the correct version of Phys so we can override our changes later
git lb-use Phys
git lb-checkout Phys/<phys_version> Phys/LoKiPhys # <phys_version> -> v26r6 for DaVinci/v45r6
git lb-checkout Phys/<phys_version> Phys/DaVinciTypes
git lb-checkout Phys/<phys_version> Phys/RelatedInfoTools
# Override our changes
cp -r ./davinci/Phys DaVinciDev_<dv_version>
# Compile
make # Tested to at least work with DaVinci/v45r6After that, add TupleToolL0Calo to your DaVinci script.
It extracts all stable daughter particles starting from top reconstructed particle. It traverses the whole decay tree from the mother and if a daughter is not stable, it will skip that daughter and keep recursing.
In run2-Hlt1GEC.h,
we have the following efficiency correction factor:
const double EFF_CORRECTION = 0.042;This factor is obtained in the following way:
-
Go to LHCb-PUB-2015-024
-
Locate Table 2. Note the Velo-Forward and VeloTT-Forward efficiencies are:
93.15% and 89.23%
-
Go to Appendix B, locate Eq. 14, efficiency loss:
$$ \text{efficiency loss} = \left( 1 - \frac{N_\text{VeloTT-Forward}}{N_\text{Velo-Forward}} \right) $$ -
Now compute the correction factor:
$$ \text{correction} = \left( 1 - \frac{0.8923}{0.9315} \right) = 0.042 $$
Most of the source code are shamelessly stolen from B02DplusTauNu analysis,
with minor changes from us.