Using K_μ2 as a normalisation sample

The overall aim of NA62 if to measure the branching fraction (using BR as the canonical shorthand from here) of the decay K⁺→π⁺νν. In order to do so, we must account for errors both statistical and systematic. Therefore, if we measure the BR and normalise the number of events we observe by dividing it by one of the primary kaon decays (μ⁺ν or π⁺π⁰) we can cancel many of the major systematics. If we use both primary decays for a normalisation sample and compare the value, we can check if we are properly accounting for all systematics, as both should provide the same result. First we use the number of observed events of decay i:

N_i = f_K x t x [BR(K→i)] x A x E_i

where f_K is the frequency of kaons in the beam, t is the time period of data taking, A is the "acceptance" or number of decays in the detector's fiducial region and E_i is the product of efficiencies ∏_rε_r for the efficiencies r relating to the trigger, reconstruction, kaon ID, daughter ID, track matching and all other processes used in the analysis (this should cover all contributions, even things like the possibility of events being incorrectly tagged as the decay you are measuring).

From this we can construct an equation for:

BR(K⁺→π⁺νν) = BR(K⁺→μ⁺ν) ⋅ ^N_π+νν/_Nμ⁺ν ⋅ ^A_μ+ν/_Aπ⁺νν ⋅ ^E_μ+ν/_Eπ⁺νν
where the f_K and t terms cancel, along with many of the ε_r efficiencies and BR(K⁺→μ⁺ν) can be taken from the PDG listings as it has been thoroughly measured by previous experiments.

• Start by generating a sample of K_μ2 data with PNN like cuts from one burst (current file) and organise some output histograms [in progress]
  • Write a new analyser and tree to group useful output [done]
  • Apply PNN like cuts [done]
  • Add a timing based MUV3 cut to select muon events [in progress]

Step 3: Run on as much 2016 data as possible with HTCondor to calculate a value for "N_μ⁺ν".

Step 4: Start looking at the efficiencies "ε_r".

• first, look at the pion ID efficiency

• Everything works as expected if you comment out the OLD_SPECIALTRIGGER block as described in the analysisbuild.txt readme file and replace it manually with whichever trigger you want to use (either works or complains that you're using the wrong one at runtime). However, you then have a dependency on a framework file.
• When using the flag, it seems that the "#define OLD_SPECIALTRIGGER" line in NA62AnalysisBuilder.py causes this definition to become stuck in the pre-processor, such that it continues to be defined if you try to build without the flag at a later stage
  • Solution 1: run a CleanAll command with NA62AnalysisBuilder.py then re-source the env.sh file
  • Solution 2: CleanAll then log out of your ssh session and log back in, source then build