Difference: ConnorsAnalysis-AnalysisTimeline (19 vs. 20)

Revision 202018-08-07 - ConnorGraham

Line: 1 to 1
 
META TOPICPARENT name="ConnorsAnalysis"
Return the the main analysis page.

Analysis Timeline

Changed:
<
<

Run the (updated) 2016 cuts based analysis on the 2017 data [started]

>
>

Upstream backgrounds study

Contributions to beam (with percentages at the start of the decay vessel):

  1. pions (71%) cause the majority of dangerous upstream backgrounds due to the one pion final state of the signal
  2. protons (23%) don't cause much of an issue due to the differences in properties with both the upstream kaon and downstream pion signal requirements
  3. kaons (6%) cause issues due to interactions and pileup and the signal requirement of an upstream kaon
Halo muons from beam particle decays can pass through upstream elements and contribute by pileup and downstream miss ID.

Type 1: Snakes and Mambas

The largest contribution to upstream backgrounds are the events that are in time with the RICH-KTAG, but out of time with GTK-KTAG. This type of event suggests that the downstream particle does originate from the beam kaon, but the GTK track is from a pileup particle. This can occur when the kaon decays within the several meter range of the GTK, most likely between GTK2 and 3, as earlier decays are more likely to be swept out of acceptance by the acromat magnets due to their lower than beam momentum.

The final dipole magnet of the acromat allows particles to exit in a narrow vertical band, however the final upstream elements will either absorb (colimator and quadrupole yoke) or veto (CHANTI) these events in a square frame around the beam axis. Therefore the only early-decay pions that can pass into the decay vessel are those that pass very close to the beam axis to avoid the CHANTI (standard Snakes), or those that sweep above and below the final elements (mambas). Standard Snakes are the majority of type 1 events before PNN cuts are applied, but Mambas are more dangerous, as a higher percentage of Mamba events pass the PNN cuts.

Type 2: pion interactions

The second largest contribution to upstream backgrounds are the events that are in time with the GTK-KTAG, but out of time with RICH-KTAG. This type of event suggests that the downstream particle does not originate from the beam kaon. Therefore, the downstream pion has to originate from an interacting, non-kaon, beam particle that produces a low momentum pion (therefore most likely from a beam pion). This interaction is most likely to occur in GTK3 due to it's positioning with respect to the beam.

Type 3: kaon interactions

Theoretically, if pions are interacting with the upstream equipment, so should the kaons. This has not yet been observed as the GTK-KTAG and RICH-KTAG would both be in time for such events

Halo muons

Both kaons and pions can decay upstream into muons with lower-than-beam momentum, a more dispersed distribution with respect to the beam axis and the ability to pass through upstream beam equipment and cause backgrounds in unexpected locations.

The upstream background region in missing mass

In the negative missing mass region, below the muon band, the only good decays should be positronic decays or semileptonic decays with a single neutral pion. Therefore, due to the branching ratio of such decays, combined with the rejection of positrons, muons and neutral pions, no such events should remain. However, a region with a clear dependence on momentum is seen in the data, this should correspond to contamination by upstream events. Therefore, this region offers an upstream-background-enriched sample that can be used for testing.

Run the (updated) 2016 cuts based analysis on the 2017 data [paused for processing]

  Summary:
  1. Finish updating the user directory files (specifically CHODAnalysis) so that KaonEventAnalysis.cc runs correctly on 2017 data (check files are the correct versions)
Line: 19 to 48
 1. Update the version of the user directory files and start testing [in progress]

Copied over a recent version of Giuseppe's codes (after a full backup), we need to check that these all work as intended with 2017 data and check that these are the most recent versions of the codes (and check for any missing, new codes).

Changed:
<
<
  • Critical codes to check: status of the framework revision you are using [updated but not checked for bug reports], status of the user directory background files [done by building a new user directory and starting from scratch], fullanalysis.conf and .settingsna62 files [in progress], HTCondor revision and file specifics [not started], any pre-analyzers required [just using GTK code for now], !TwoPhotonAnalysis.cc(.hh) [Giuseppe checking this], TrackAnalysis.cc(.hh) [Done timing and spacial plots look good], !OneTrackEventAnalysis.cc(.hh) [next], !KaonEventAnalysis.cc(.hh) [final step].
>
>
  • Critical codes to check: status of the framework revision you are using [updated but not checked for bug reports], status of the user directory background files [done by building a new user directory and starting from scratch], fullanalysis.conf and .settingsna62 files [in progress], HTCondor revision and file specifics [not started], any pre-analyzers required [just using GTK code for now], TwoPhotonAnalysis.cc(.hh) [Giuseppe checking this], TrackAnalysis.cc(.hh) [Done timing and spacial plots look good], OneTrackEventAnalysis.cc(.hh) [next], KaonEventAnalysis.cc(.hh) [final step].
 
  • Starting with a test run on just TrackAnalysis (responsible for track to sub-detector matching, but no cuts) and TwoPhotonAnalysis (responsible for the pi0 variables), with just GigaTrackerEvtReco as a pre-analyzer and with the usual dependency libraries. This was done with a single, reprocessed, 2017, golden run file; specifically run 8252, filtered for Pnn, bursts 13-15. Files may be reprocessed again after the release of v0.11.2 (is CVMFS a better choce for final 2017 analysis?).
    • Initial results suggest timing issues in the CHOD as expected
    • After correcting CHODAnalysis.cc with the path to the newest light correction files this issue was resolved
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback