See the materials from the HF O2 hackathon (includes introduction to O2, O2 HF, tutorials,...) and watch the Zoom recordings of the sessions.

Coordinators: Francesco Prino, Vít Kučera

Mattermost channel: hf-o2-analysis-challenge

• Tasks used by the heavy-flavour analysis framework are in the PWGHF directory.
• Tables produced by skimming and candidate creators are defined in HFSecondaryVertex.h.
• Tables produced by candidate selectors are defined in HFCandidateSelectionTables.h.
• Default parameters used in the selection of single tracks, track-index skims and candidates are defined in HFSelectorCuts.h.
• Secondary-vertex reconstruction algorithms are implemented in the DCAFitterN class.
• Functions for calculations of kinematic quantities and for MC matching are implemented in the RecoDecay class.
• Selection of tracks based on the particle identification (PID) detectors is performed via the TrackSelectorPID class.
• Code for easy running of the HF tasks and output processing can be found in the Run3Analysisvalidation repository.
  • Analysis code for postprocessing of the task output is collected in the FirstAnalysis directory.

JIRA tickets of the HF analyses on AliHyperloop:

Simplified graph of the workflows and tasks involved in a single HF analysis is shown in the following picture. Individual components are described in the next section below.

Tracks and collisions are flagged with selection decisions. Tracks selection is based on reconstruction quality and kinematic criteria. Collisions are selected based on the required triggers.

Double and triple loops over the selected tracks in each selected event are performed to combine tracks into protocandidates. Very loose selection criteria are applied (invariant mass and p_T of the protocandidate) to reject fake candidates before secondary-vertex finding. Secondary vertex is reconstructed for the selected track pairs and triplets and the tracks are propagated to the decay vertex. A first selection at the candidate level is applied (candidate p_T, cosine of pointing angle, product of prong impact parameters).

Indices of the daughter tracks of selected candidates are stored as columns of a new derived table (track index skim table), together with a flag indicating for which decay channel(s) the candidate was selected.

Track indices in the track index skim table are used to build full decay candidates. The secondary-vertex reconstruction is repeated and additional candidate properties, that are needed for the signal selection and cannot be calculated dynamically on-the-fly, are computed (e.g. uncertainties of quantities computed in the vertex reconstruction procedure).

The complete list of quantities needed for the final candidate selection and analysis are stored in a derived table of reconstructed candidates (candidate table).

For simulated data, reconstructed decay candidates are matched with their generated counterparts by checking the correspondence between the candidate prongs and the expected decay tree. The MC matching procedure is performed also for generated MC particles by checking their identity and their decay tree. Particle origin is determined by inspecting the decay tree to identify non-prompt particles, produced from b quarks.

Derived tables with MC flags used for the estimation of the signal efficiencies and the optimisation of the signal and background selections are produced.

In a dedicated selector task, tailored for each decay channel, accurate analysis level selection criteria based on decay topology and PID are applied to the reconstructed candidates.

The selection results are stored in a column of a new dedicated table that is later joined with the candidate table to filter them.

In the user analysis task, histograms needed for the analysis are filled with properties of selected candidates.

For MC events, histograms with quantities of generated MC particles and MC-matched candidates are produced.

Candidate tables and other related derived tables are exported to disk as ROOT trees for post-processing with external tools, e.g. for optimisation with Machine Learning techniques.

• Follow the O2 coding guidelines (especially the naming and commenting rules).
• If your changes consist of several independent steps, keep them separate in several commits.
• Give your commits meaningful titles.
  • If needed, add more details in the commit message (separated by a blank line from the commit title).
• Keep your feature branch up to date with the upstream main branch.
• Test your code before making a pull request.
  • Propagate your changes into the Run3Analysisvalidation configuration.
  • Check that your branch compiles.
  • Check that your code works and runs without errors and warnings.
    • Make sure your code is compatible with the expected input (Run 2/3/5, real/MC data, p–p/Pb–Pb).
    • Check that your changes do not alter unexpectedly the control plots produced by the validation framework.
  • Make sure your tasks can be fully configured from Run3Analysisvalidation and AliHyperloop.

Use the <object><attribute> (or <general><specific>) naming scheme, so that names of the same kind of objects start with same string and the different attributes follow. This scheme makes names more readable, searchable and sortable.

Example:

ptTrackMin, etaTrackMax, trackPos, trackNeg

is more readable and sortable than

minTrackPt, maxTrackEta, posTrack, negTrack

• Names of task configurables follow the same conventions as names of variables.
• Names of histograms start with h and follow the same conventions as names of variables.
  • Names of histograms of MC variables have the following suffixes:
    • Gen - generator level quantity of a signal particle
    • GenSig - generator level quantity of a reconstructed signal candidate
    • RecSig - reconstruction level quantity of a reconstructed signal candidate
    • RecBg - reconstruction level quantity of a reconstructed background candidate

The device name of a task is automatically generated from the name of the corresponding struct by replacing uppercase letters with lowercase letters preceded with a hyphen unless defined explicitly using TaskName, which should be avoided if not necessary.

• Create one PR per feature (i.e. do not mix big unrelated code changes).
• Give your PR a short meaningful title.
  • Add the “PWGHF: ” prefix in the title of your PR. (It allows to search for PWGHF-related PRs in the commit history of the main branch.)
    • Note: If your PR has only one commit, add the prefix also in the commit title (because that is the title that will appear in the history after merging).
• Give further useful details about your changes in the PR description.
  • Add links to all related PRs (e.g. O2Physics, O2, AliPhysics, Run3Analysisvalidation) in the PR description.

• When you implement changes during the review, push them into your branch as new separate commits (with meaningful titles).
• Do not amend, squash or rebase existing commits in the PR. It would break the links between the code and the review comments.
  • If you need to update your branch with the changes in the main branch, use merge instead of rebase to preserve the commit history.
• Fix formatting issues by merging the PRs created automatically by the CI tests in your fork repository.