Return the the main analysis page.

# Analysis Timeline

### 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 π+π0) 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:

Ni = fK ⋅ t ⋅ [BR(K→i)] ⋅ A ⋅ Ei

where fK 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 Ei 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 fK 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.

### Currently working on:

Step 1: Generate a Kμ2 normalisation sample.

• 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 [done but needs testing]
• Confirm compatibility of Pnn cuts, comment cuts as muon or Pnn, generally tidy up the code to finalise the cuts [not started yet]
Step 2: Calculate the acceptance "Aμ+ν" using all the muon MC with HTCondor.

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

### Possible future work:

Parallel MC work: [no further information on this as of yet]

• Altering the Geant4 setup to change the hadronic interaction probability in GTK3 to 1
• Generating on the order of 100M events
• Comparing with data
• Aim: to make an estimation of this background for the PNN errors

### Finished:

build flag issue with --old-specialtrigger, causing a dependency on the framaework's UserMethods.cc file.

• 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

Generating a Pnn sample from the Kaon code given to me by Giuseppe.

• Build fails due to class conflict in the public directory files
• Solution: fixed manually by Giuseppe in the codes, largely by replacing the conflicting "Particle" class with "MyParticle"
• Further run fails due to a special trigger issue not dependent on the build flag
• Solution: a special trigger element of the code needs changing when swapping between MC and data files
• Now working on afs and should be able to set up on any other system (copy placed in: userDir2)
A test analyser, to understand how to generate an analyser from scratch and plot variables in the data files, using the framework as a basis.
• This analyser is now setup such that it builds and begins to run with the current setup, designed to record the number of spectrometer candidates, but it fails at runtime due to an issue with a special trigger which is not specifically used in the code.
• Solution: frameworks are not yet completely backwards compatible, I need to use the --old-specialtrigger flag after "build" to get this to work *
Edit | Attach | Watch | Print version |  | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r5 - 2017-12-07 - ConnorGraham

Copyright © 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback