Difference: ConnorsAnalysis-AnalysisTimeline (10 vs. 11)

Revision 112018-01-29 - ConnorGraham

  META TOPICPARENT 
 name="ConnorsAnalysis" 

Return the the main analysis page. 
 Switch to event timeline
- META TOPICPARENT
+ name="ConnorsAnalysis"
 Summary: 
 The events occur in the detector
  Detector information is processed in the triggers and stored on Castor
-<
<
+ Raw data is reconstructed by the framework
  Reconstructed data is filtered to purpose then stored on EOS
->
>
+ Raw data is reconstructed by the framework then the reconstructed data is filtered to purpose and stored on EOS
  Filtered data is then processed by the user directory files
  KaonEventAnalysis.cc then processes the data in stages
 
1: The events occur in the detector
 The L0TP processes the L0 trigger decision from the detector signals, then the PC farm processes L1 and auto-passes L2 (assuming all signals present). The Mergers then buffer the events and write to Castor.
-<
<
+: Raw data is reconstructed by the framework
->
>
+: Raw data is reconstructed by the framework then the reconstructed data is filtered to purpose and stored on EOS
 The data is reconstructed using a version or revision of the framework that is dependent on the time the data was taken, reco efficiency is important at this stage.
-<
<
+: Reconstructed data is filtered to purpose then stored on EOS
 The Pnn filtering code or others are used to reduce the file sizes and separate the events based on the analysis group that will use them.
-<
<
+: Filtered data is then processed by the user directory files
->
>
+: Filtered data is then processed by the user directory files
-<
<
+User directory pre-analysing files: GigaTrackerEvtReco, AccidentalAnalysis.cc, TwoPhotonAnalysis.cc, TrackAnalysis.cc and OneTrackEventAnalysis.cc.
->
>
+User directory pre-analysing files: GigaTrackerEvtReco, TwoPhotonAnalysis.cc, TrackAnalysis.cc and OneTrackEventAnalysis.cc.
-<
<
+: KaonEventAnalysis.cc then processes the data in stages
->
>
+: KaonEventAnalysis.cc then processes the data in stages
  The main function containing the base analysis
-<
<
+ Start of Job, Run then Burst
  Initialise histograms, trees and output
->
>
+ Start of Job, Run then Burst; Initialise histograms, trees and output
  Process each event and call the relevant analysis functions
  Run the specific analysis function on each event that passed the previous stages
  Post-processing with: PostProcess; End of Burst, Run, Job; DrawPlot
 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 ⋅ t ⋅ [BR(K→i)] ⋅ A_i ⋅ E_i
->
>
+N_i = f_K ⋅ t ⋅ [BR(K→i)] ⋅ A_i
-<
<
+where f_K is the frequency of kaons in the beam, t is the time period of data taking, A_i 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).
->
>
+where f_K is the frequency of kaons in the beam, t is the time period of data taking and A_i is the "acceptance" or number of decays in the detector's fiducial region (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.
->
>
+BR(K⁺→π⁺νν) = BR(K⁺→μ⁺ν) ⋅ ^N_π⁺νν/_{N_μ⁺ν} ⋅ ^A_μ⁺ν/_{A_π⁺νν}
 where the f_K and t terms cancel, along with many of the efficiencies included in the acceptance and BR(K⁺→μ⁺ν) can be taken from the PDG listings as it has been thoroughly measured by previous experiments.
 Step 1: Generate a K_μ2 normalisation sample. [done] 
 Start by generating a sample of K_μ2 data with Pnn like cuts from one burst (current file) and organise some output histograms
  Select muon events at MC truth level [starting]
  Take basic acceptance cut of 105 (possibly 115) to 165m
  Bin "passed" events by momentum as has been done in previous studies (15-20, 20-25, 25-30, 30-35 GeV)
-<
<
+ Calculate binned acceptance by dividing by all events, recorded using the same binning system
->
>
+ Calculate binned acceptance by dividing by all events that pass Kmu2 cuts, recorded using the same binning system, by the geometric acceptance binned numbers
 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
->
>
+ Run selection on run number 6431 (large, good quality run) to start with
  Run on Giuseppe's list of all good runs of 2016
 
Step 4: Start looking at the efficiencies that don't cancel in the acceptances fraction "ε_r". 
 Pion ID efficiency.  
  Matter interaction differences of muon and pion.  
  Anything we missed?
  Run the (updated) 2016 cuts based analysis on the 2017 data [future] 
 
 Finish updating the user directory files (specifically CHODAnalysis) so that KaonEventAnalysis.cc runs correctly on 2017 data (check you are using the correct framework revision)
  Run on one file to check functionality

View topic | History: r20 < r19 < r18 < r17 | More topic actions...