TrkAnaTutorial: Difference between revisions

From Mu2eWiki
Jump to navigation Jump to search
Line 78: Line 78:


=== Exercise 2: Calculating the Ce efficiency ===
=== Exercise 2: Calculating the Ce efficiency ===
Now that we can create a TrkAna tree, let's calculate how efficient we are at reconstructed conversion electrons with some signal cuts. Before starting this exercise, a quick note about '''event counting''', '''event weighting''', and '''reco quality'''.
Now that we can create a TrkAna tree, let's calculate how efficient our reconstruction is for conversion electrons with some signal cuts. There's a lot of concepts introduced in this exercise, so don't worry if it all doesn't make sense at first. I'll start with some quick notes on '''event counting''', '''event weighting''', and '''reco quality'''.


'''Event Counting'''
'''Event Counting'''


In the simulation, we generate a certain number of events. However, in order to save space, we only write out events that will produce a reconstructed tracks. We have various ways of filtering events but the result is the same -- the number of events in the output art files do not correspond to the number of events that were generated, which is what we need to calculate absolute efficiencies. To account for this, we keep track of the number of events that were generated by creating a <code>GenEventCount</code> object. Then we can run the <code>genCountLogger</code> module to read the actual number of generated events.
In the simulation, we generate a certain number of events. However, in order to save space, we only write out events that will produce a reconstructed tracks. We have various ways of filtering events but the result is the same -- the number of events in the output art files do not correspond to the number of events that were generated. We need to know the total number of generated events in order to calculate an absolute efficiency. We keep track of the number of events that were generated by creating a <code>GenEventCount</code> object for each SubRun. Then in our TrkAna job, we run the <code>genCountLogger</code> module to read the actual number of generated events.


'''Event Weighting'''
'''Event Weighting'''


In each "mixed" event, we add a single "primary" particle onto a set of "background frames", which represent the background hits from other processes. We want to simulate the variable intensity of the proton beam at the production target and so we scale the number of background hits when we create the mixed event. However, we still only add a single primary particle and so we record the scale factor used in a <code>ProtonBunchIntensity</code> object for use later. In this exercise, we will add a new module to the trigger path (<code>PBIWeight</code>), which translates the scale factor used for the proton bunch intensity into an <code>EventWeight</code> object. The TrackAnalysisReco then writes out these event weight values to a new branch (<code>evtwt.PBIWeight</code>). Event weighting is explored in more detail in Advanced Exercise 2.
In each "mixed" event, we add a single "primary" particle onto a set of "background frames", which represent the background hits from other processes. We want to simulate the variable intensity of the proton beam at the production target and so we scale the number of background hits when we create the mixed event. However, we still only add a single primary particle and so we record the scale factor used in a <code>ProtonBunchIntensity</code> object for use later. In our TrkAna job, we will add a new module to the trigger path (<code>PBIWeight</code>), which translates the scale factor used for the proton bunch intensity into an <code>EventWeight</code> object. The TrackAnalysisReco module will write out these proton beam scale factors to a new branch (<code>evtwt.PBIWeight</code>). Event weighting is explored in more detail in Advanced Exercise 4.


'''Reco Quality'''
'''Reco Quality'''


We use various algorithms to check the "quality" of a track in some dimension. Currently there are two:
We use various algorithms to check the "quality" of a track in some dimension. Currently there are two we consider:
* track quality -- to determine how will-reconstructed a track is; and
* the track quality (i.e. how will-reconstructed a track is); and
* PID quality -- to determine how closesly a track resembles an electron rather than a muon.
* the particle ID (PID) quality (i.e. how closely a track resembles an electron rather than a muon).


Currently we have two artificial neural network (ANN) based algorithms called TrkQual and TrkCaloHitPID. These are run in separate art modules, which create  that takes various properties of the track and is trained to give each track a trkqual value between 0 (poorly-reconstructed) and 1 (well-reconstructed). In this exercise, we add the TrkQual and TrkCaloHitPID modules to the trigger path and TrkAna writes out the output value to the branch <code>trkqual</code>. There is one TrkQualCollection for each KalSeedCollection. TrkQual is explored in more detail in Advanced Exercise 3.
In our TrkAna job, we will add two artificial neural network (ANN) based algorithms to determine these reco qualities (TrkQual and TrkCaloHitPID). In this exercise, we only care that the output of both of these modules is a <code>RecoQualCollection</code> with one <code>RecoQual</code> object per <code>KalSeed</code>. A <code>RecoQual</code> is essentially a float and, in these two algorithms, is between 0 (poorly-reconstructed, XXX PID) and 1 (well-reconstructed, YYY PID). TrkQual is explored in more detail in Advanced Exercise 3.


'''The Exercise'''
'''The Exercise'''
Line 100: Line 100:
Now onto the exercise:
Now onto the exercise:
<ol style="list-style-type:lower-alpha">
<ol style="list-style-type:lower-alpha">
  <li>Create a TrkAna tree with CeEndpoint-mix tracks and include the <code>genCountLogger</code>, <code>PBIWeight</code> and <code>TrkQual</code> modules</li>
  <li>Create a TrkAna tree with CeEndpoint-mix tracks and include the <code>genCountLogger</code>, <code>PBIWeight</code>, <code>TrkQual</code> and <code>TrkCaloHitPID</code> modules</li>
  <nowiki> mu2e -c $TUTORIAL_BASE/TrkAna/fcl/TrkAnaTutEx02.fcl -S $TUTORIAL_BASE/TrkAna/filelists/mcs.mu2e.CeEndpoint-mix-cat.MDC2018h.1-file.lst</nowiki>
  <nowiki> mu2e -c fcl/TrkAnaTutEx02.fcl -S filelists/mcs.mu2e.CeEndpoint-mix-cat.MDC2018h.1-file.lst</nowiki>
You can read the file to see how the modules are added (Note: some of this hidden away in $MU2E_BASE_RELEASE/TrkDiag/fcl/prolog.fcl).
If you read the file you will see that we have added:
<nowiki>physics.TrkAnaTrigPath : [ @sequence::TrkAnaReco.TrigSequence ]</nowiki>
which adds a standard set of modules including <code>PBIWeight</code> etc. (you can look in $MU2E_BASE_RELEASE/TrkDiag/fcl/prolog.fcl for more details).
<li>Also in TrkAnaTutEx02.fcl, you will see that we have changed the <code>input</code> parameter to just <code>"KFF"</code>and added the <code>suffix</code> parameter:</li>
<nowiki>physics.analyzers.TrkAnaEx02.candidate.input : "KFF"
physics.analyzers.TrkAnaEx02.candidate.branch : "trk"
physics.analyzers.TrkAnaEx02.candidate.suffix : "DeM"</nowiki>
In the Mu2e reconstruction jobs, we keep consistency between our fit hypotheses with standard suffixes to the module labels. If you look in $MU2E_BASE_RELEASE/TrkDiag/fcl/prolog.fcl, you will see that we have TrkQual'''DeM''', TrkQual'''DeP''' etc.
<li>If you open up the ROOT file and print the tree structure, you will notice the following new branches:</li>
<ol style="list-style-type:lower-roman">
  <li><code>evtwt</code>: stores the values of all <code>EventWeight</code> objects in the art event</li>
  <li><code>trkqual</code>: stores the values of all '''relevant''' <code>RecoQual</code> objects in the art event</li>
</ol>
Defining a <code>suffix</code> in the TrkAna configuration allows us to store only the '''relevant''' <code>RecoQual</code> values.
<li>(Optional): Try running without a suffix parameter and set <code>input</code> back to <code>"KFFDeM"</code>. What do you see in the output <code>trkqual</code> branch</li>
  <li>Run this example ROOT macro that plots the track momentum onto a histogram with 0.5 MeV wide bins</li>
  <li>Run this example ROOT macro that plots the track momentum onto a histogram with 0.5 MeV wide bins</li>
  <nowiki> root -l $TUTORIAL_BASE/TrkAna/scripts/TrkAnaTutEx02.C </nowiki>
  <nowiki> root -l scripts/TrkAnaTutEx02.C </nowiki>
  <li>Change the bin width to 0.05 MeV</li>
  <li>Change the bin width to 0.05 MeV</li>
  <li>Add the following signal cuts to the Draw function</li>
  <li>Add the following signal cuts to the Draw function</li>

Revision as of 23:36, 5 June 2019

Under Construction!

This tutorial is currently being written

Session Prerequisites

This tutorial is aimed at anyone starting ntuple analysis.

Before starting this tutorial you should:

  • know about the physics of Mu2e;
  • have the appropriate docker container set up; and,
  • know how to run the Mu2e Offline software and ROOT.

Session Introduction

One of the final outputs of the Mu2e reconstruction are fits to the tracks in the tracker. These are stored as KalSeeds in KalSeedCollections. For each fit hypothesis, we have a different KalSeedCollection (e.g. downstream electrons, downstream muons, upstream positrons).

In order to do analyses with these tracks, we have an art module that creates a ROOT TTree of these KalSeeds called TrkAna. Each entry in the tree corresponds to a single track.

In this tutorial you will:

  • create TrkAna trees using the Mu2e Offline software and MDC2018 datasets; and,
  • analyze them using the ROOT command line and ROOT macros.

Basic Exercises

These exercises are designed to be run on v7_4_1 from $TUTORIAL_BASE/TrkAna

> whatever command to setup in docker
> cd $TUTORIAL_BASE/TrkAna

Exercise 1: Creating the simplest TrkAna tree

In this exercise, we will create the simplest TrkAna tree and investigate it with the ROOT command line.

  1. First, run mu2e on a single CeEndpoint-mix reco art file:
  2. > mu2e -c fcl/TrkAnaTutEx01.fcl -S filelists/mcs.mu2e.CeEndpoint-mix-cat.MDC2018h.1-file.lst
  3. Now let's have a look at the TrkAna tree with the ROOT command line
  4. > root -l trkana-ex01.root root[n]: TrkAnaEx01->cd() root[n]: trkana->Print() You will see the TrkAna tree structure. Here is a brief description of the branches:
    1. evtinfo: event level information (e.g. event ID of the art::Event this track is from)
    2. hcnt: hit count of different types of hit (e.g. number that pass certain selections)
    3. tcnt: track count of different track types
    4. trk: global fit information for the track (e.g. fit status, ranges of validity, number of hits)
    5. trk(ent/mid/xit): local fit information for the track at the enttrance of the tracker, the middle of the tracker and exit of the tracker (e.g. fit momentum, pitch angle)
    6. trktch: calorimeter hit information for the calorimeter function associated to the track (tch = TrkCaloHit)
    7. crvinfo: information of associated hits in the CRV

    Note that the "trk" parts of the branch names are configurable -- you will see this is a minute

  5. Now we can plot some simple things:
    1. the track momentum at the tracker entrance
    2. root[n]: trkana->Draw("trkent.mom")
    3. the calorimeter cluster energy
    4. root[n]: trkana->Draw("trktch.edep")
    5. With this last command you will see some entries at -1000. This means that there is no associated calorimeter cluster for this track. To exclude these we want to want to add a cut on the trktch.active flag (0 = there is no TrkCaloHit, 1 = there is TrkCaloHit):
    6. root[n]: trkana->Draw("trktch.edep", "trktch.active==1")
  6. Let's take a quick look at the fcl file to see how the TrackAnalysisReco module has been configured. Open it up in your favourite text editor and look at these important lines:
  7. TrkAnaEx01 : { @table::TrackAnalysisReco } physics.analyzers.TrkAnaEx01.candidate.input : "KFFDeM" physics.analyzers.TrkAnaEx01.candidate.branch : "trk" physics.analyzers.TrkAnaEx01.diagLevel : 0 physics.analyzers.TrkAnaEx01.FillMCInfo : false In order, these lines:
    1. import an example TrkAna module configuration (you can find it in $MU2E_BASE_RELEASE/TrkDiag/fcl/prolog.fcl);
    2. define the input KalSeedCollection that we want a TrkAna tree for (KFFDeM = KalFinalFit Downstream eMinus);
    3. configure the name of the output branches;
    4. set TrkAna to use the lowest diagnostic level (1 = simple list of tracks, 2 = hit level diagnostics); and,
    5. make sure we are not touching the MC truth

That's the end of this exercise -- you can now create a simple TrkAna tree! Try some of the following optional exercises to explore further:

  1. (Optional): Run on a CeplusEndpoint-mix file (filelist/mcs.mu2e.CeplusEndpoint-mix-cat.MDC2018h.1-file.lst) and get a list of positively-charged tracks. What is the momentum of these tracks?
  2. (Optional): Create a second instance of the TrackAnalysisReco module. Have one instance set to look at negatively-charged tracks and the other set to look at positively charged tracks. Run on muplusgamma-mix (filelist/mcs.mu2e.flatmugamma-mix-cat.MDC2018h.1-file.lst) and count how many tracks of each type are found

Exercise 2: Calculating the Ce efficiency

Now that we can create a TrkAna tree, let's calculate how efficient our reconstruction is for conversion electrons with some signal cuts. There's a lot of concepts introduced in this exercise, so don't worry if it all doesn't make sense at first. I'll start with some quick notes on event counting, event weighting, and reco quality.

Event Counting

In the simulation, we generate a certain number of events. However, in order to save space, we only write out events that will produce a reconstructed tracks. We have various ways of filtering events but the result is the same -- the number of events in the output art files do not correspond to the number of events that were generated. We need to know the total number of generated events in order to calculate an absolute efficiency. We keep track of the number of events that were generated by creating a GenEventCount object for each SubRun. Then in our TrkAna job, we run the genCountLogger module to read the actual number of generated events.

Event Weighting

In each "mixed" event, we add a single "primary" particle onto a set of "background frames", which represent the background hits from other processes. We want to simulate the variable intensity of the proton beam at the production target and so we scale the number of background hits when we create the mixed event. However, we still only add a single primary particle and so we record the scale factor used in a ProtonBunchIntensity object for use later. In our TrkAna job, we will add a new module to the trigger path (PBIWeight), which translates the scale factor used for the proton bunch intensity into an EventWeight object. The TrackAnalysisReco module will write out these proton beam scale factors to a new branch (evtwt.PBIWeight). Event weighting is explored in more detail in Advanced Exercise 4.

Reco Quality

We use various algorithms to check the "quality" of a track in some dimension. Currently there are two we consider:

  • the track quality (i.e. how will-reconstructed a track is); and
  • the particle ID (PID) quality (i.e. how closely a track resembles an electron rather than a muon).

In our TrkAna job, we will add two artificial neural network (ANN) based algorithms to determine these reco qualities (TrkQual and TrkCaloHitPID). In this exercise, we only care that the output of both of these modules is a RecoQualCollection with one RecoQual object per KalSeed. A RecoQual is essentially a float and, in these two algorithms, is between 0 (poorly-reconstructed, XXX PID) and 1 (well-reconstructed, YYY PID). TrkQual is explored in more detail in Advanced Exercise 3.

The Exercise

Now onto the exercise:

  1. Create a TrkAna tree with CeEndpoint-mix tracks and include the genCountLogger, PBIWeight, TrkQual and TrkCaloHitPID modules
  2. mu2e -c fcl/TrkAnaTutEx02.fcl -S filelists/mcs.mu2e.CeEndpoint-mix-cat.MDC2018h.1-file.lst If you read the file you will see that we have added: physics.TrkAnaTrigPath : [ @sequence::TrkAnaReco.TrigSequence ] which adds a standard set of modules including PBIWeight etc. (you can look in $MU2E_BASE_RELEASE/TrkDiag/fcl/prolog.fcl for more details).
  3. Also in TrkAnaTutEx02.fcl, you will see that we have changed the input parameter to just "KFF"and added the suffix parameter:
  4. physics.analyzers.TrkAnaEx02.candidate.input : "KFF" physics.analyzers.TrkAnaEx02.candidate.branch : "trk" physics.analyzers.TrkAnaEx02.candidate.suffix : "DeM" In the Mu2e reconstruction jobs, we keep consistency between our fit hypotheses with standard suffixes to the module labels. If you look in $MU2E_BASE_RELEASE/TrkDiag/fcl/prolog.fcl, you will see that we have TrkQualDeM, TrkQualDeP etc.
  5. If you open up the ROOT file and print the tree structure, you will notice the following new branches:
    1. evtwt: stores the values of all EventWeight objects in the art event
    2. trkqual: stores the values of all relevant RecoQual objects in the art event

    Defining a suffix in the TrkAna configuration allows us to store only the relevant RecoQual values.

  6. (Optional): Try running without a suffix parameter and set input back to "KFFDeM". What do you see in the output trkqual branch
  7. Run this example ROOT macro that plots the track momentum onto a histogram with 0.5 MeV wide bins
  8. root -l scripts/TrkAnaTutEx02.C
  9. Change the bin width to 0.05 MeV
  10. Add the following signal cuts to the Draw function
    1. the fit is successful (trk.status > 0)
    2. the track is in the time window of 700 ns -- 1695 ns (trk.t0)
    3. the tan-dip of the track is consistent with coming from the target: 0.577350 -- 1.000 (trkent.td)
    4. the impact parameter of the track is consistent with coming from the target: -80 mm -- 105 mm (trkent.d0)
    5. the maximum radius of the track is OK: 450 mm -- 680 mm (trkent.d0 + 2./trkent.om)
    6. the track is of good quality (trkqual.TrkQualDeM > 0.8)
  11. Because we simulated each event with a different proton bunch intensity, each track should be weighted by the PBIWeight. To do this you will want to modify the cut command to add the event weighting:
  12. evtwt.PBIWeight*(cuts)
  13. Now we can count the number of tracks that pass all these cuts
  14. hRecoMom->Integral()
  15. We can also integrate in the momentum signal region with the same function. Be careful TH1F::Integral takes bin numbers as its arguments and not x-values. Some hints:
    1. you can find a bin for a given x-value with hist->GetXaxis()->FindBin(x-value)
    2. make sure you aren't off by one bin by checking the bin low edges and bin high edges with TAxis::GetBinLowEdge() and TAxis::GetBinUpEdge().
  16. To calculate the efficiency you need to know the number of events generated for this simulation. This is stored in the output of the genCountLogger module
  17. TH1F* hNumEvents = (TH1F*) file->Get("genCountLogger/numEvents"); double n_generated_events = hNumEvents->GetBinContent(1);
  18. Now you can calculate the absolute Ce efficiency. What's the answer?

Now that you can calculate the Ce efficiency, try some of the following exercises:

  1. (Optional): Make the plot prettier by:
    1. adding appropriate axis labels
    2. writing the Ce efficiency on the plot with a TLatex
    3. adding dashed lines to show the momentum window with TLines (extra bonus: have the lines move when the momentum window values change)
  2. (Optional): Add a second momentum plot but with a higher track quality cut and include a TLegend.

Exercise 3: Adding MC truth

In this exercise, we will add MC truth information to the TrkAna tree and see how close our reconstruction matches the truth.

  1. Create a TrkAna tree with CeEndpoint-mix tracks and include the MC truth information:
  2. mu2e -c $TUTORIAL_BASE/TrkAna/fcl/TrkAnaTutEx03.fcl -S $TUTORIAL_BASE/TrkAna/filelists/mcs.mu2e.CeEndpoint-mix-cat.MDC2018h.1-file.lst If you look in the fcl file, you will notice that there is a global switch fillMCInfo and a local switch for the candidate track candidate.fillMC. This will be important when we add supplemental tracks in Exercise 5.
  3. You can open up the file and Print the tree structure. For this exercise, we will focus on the trkmcent, which contains the MC information for the step that crossed the entrance into the tracker. The other trkmc* branches will be the focuse of Exercise 4.
  4. Run this example ROOT macro that plots the intrinsic tracker momentum for tracks that pass our signal cuts except for the trkqual and momentum window cuts
  5. root -l $TUTORIAL_BASE/TrkAna/scripts/TrkAnaTutEx03.C
  6. Add the following line to the start of the macro:
  7. gStyle->SetOptStat(111111); This will add the "Overflow" and "Underflow" values of the histogram to the stats box. This shows the number of events that fall outside of the axis range of the histogram. In ROOT the overflow bin is at bin number n_bins+1 and the underflow bin is bun number 0.
  8. Using what you learned in Exercise 2, count the number of events above +3 MeV, including the events in the overflow bin
  9. Add the trkqual cut and play with it. How does the number of events above +3 MeV change?
  10. (Optional): Do the same comparison at the middle or exit of the tracker
  11. (Optional): Perform a fit to a double-sided crystal ball function. This function is a Gaussian with polynomial tails. The function can be found here: $TUTORIAL_BASE/TrkAna/scripts/dscb.h. You will need to create your own TF1 (hint) and use the TH1::Fit() function (hint). What is the core resolution?

Exercise 4: Following genealogy

With TrkAna, we also have access to important steps in the genealogy of the track (i.e. which particles produced the track). Before looking at the branches themselves, we need to discuss a little about the simulation.

For each event in the simulation we instantiate a GenParticle, which represents the particle we want to start the simulation with. For some of our samples, we create more than one of these per event (e.g. for cosmic rays, we take all the particles created in the shower at a certain altitude). We then pass these GenParticles to the physics simulation and create a SimParticle for each one. We then let Geant4 simulate these SimParticles and create more SimParticles until we end up with StepPointMCs in the detectors. For the tracker, there will be many different StepPointMCs from different SimParticles in every straw. We assign a SimParticle to be responsible each straw hit if it had the most StepPointMCs in that hit.

Now here is a description of the branches we have in TrkAna:

trkmc
contains information about the SimParticle that produced the most hits on the track
trkmcpri
contains information about the primary particle that produced the trkmc particle (e.g. for cosmic rays, this will correspond to the cosmic ray that produced the shower (i.e. the proton))
trkmcgen
contains information about the actual GenParticle in our simulation that ultimately produced the track (e.g. for cosmic rays, this will be the particle in the shower that ultimately produced the track)

For most of our samples, these are all the same particle. In order to explore the differences, we will run on a sample of cosmic rays made by the CRY generator.

  1. Create a TrkAna tree with CRY-cosmic-general-mix tracks and include the MC truth information:
  2. mu2e -c $TUTORIAL_BASE/TrkAna/fcl/TrkAnaTutEx04.fcl -S $TUTORIAL_BASE/TrkAna/filelists/mcs.mu2e.CRY-cosmic-general-mix-cat.MDC2018h.1-file.lst
  3. Open the ROOT file and look at the PDG ID codes of the MC particles (defined here but some important ones are 11 = electron, -11 = positron, 13 = muon, -13 = positive muon, 2212 = proton).
  4. root -l trkana-ex04.root root[n]: TrkAnaEx04->cd() root[n]: trkana->Scan("trkmc.pdg:trkmcgen.pdg:trkmcgen.pdg") Here are the first few rows: ************************************************ * Row * trkmc.pdg * trkmcgen. * trkmcpri. * ************************************************ * 0 * 13 * 13 * 2212 * * 1 * 13 * 13 * 2212 * * 2 * 11 * 13 * 2212 * * 3 * 13 * 13 * 2212 * * 4 * -13 * -13 * 2212 * * 5 * 11 * -13 * 2212 * So the "primary" particle is a proton, this is the cosmic ray proton and doesn't actually appear in our simulation. The GenParticles that started our simulation are either positive or negative muons. The particles that are responsible for the tracks are either muons or electrons.
  5. However just because we have two particles of the same type at the different stage, does not mean that they are the same particle. We need look at the trkmc.prel, which encodes the relationship between the track particle and the GenParticle:
  6. root[n]: trkana->Scan("trkmc.pdg:trkmc.prel:trkmcgen.pdg:trkmcgen.pdg") You can look in $MU2E_BASE_RELEASE/MCDataProducts/inc/MCRelationship.hh for the definitions (0 = same, 1 = direct child, -1 = unrelated).
  7. (Optional): Run on the flatmugamma-mix (internalRMC would be better...) file list and look at the genealogy of those tracks

As you can tell, this isn't an exhaustive genealogy tree so if you need to look at something more complex, then you can run in the full Offline framework where we (currently) store every step in the genealogy for saved tracks.

Exercise 5: Adding supplemental tracks

From the last exercise, we can see that we get muon tracks. But we were only looking at the result of the electron fit. We can have TrkAna write out the results of supplemental fits (e.g. downstream muon track)

  1. Create a TrkAna tree with CRY-cosmic-general-mix tracks and include the result of downstream mu-minus fits:
  2. mu2e -c $TUTORIAL_BASE/TrkAna/fcl/TrkAnaTutEx05.fcl -S $TUTORIAL_BASE/TrkAna/filelists/mcs.mu2e.CRY-cosmic-general-mix-cat.MDC2018h.1-file.lst
  3. Look at the tree
  4. Can see that we have renamed the "trk" branch to "de" and to "dm"
  5. Compare de.trkqual and dm.trkqual

Exercise 6: TrkAnaReco

Run TrkAnaReco.fcl and explain branches. The detrkqual and detrkpid branches will be exaplained in an advanced exercise.

  1. Run TrkAnaReco.fcl
  2. mu2e -c $MU2E_BASE_RELEASE/TrkDiag/fcl/TrkAnaReco.fcl -S filelists/mcs.mu2e.CRY-cosmic-general-mix-cat.MDC2018h.1-file.lst
  3. look for reflected tracks? compare DeM to DmuM?
  4. check for CRV coincidence?

Advanced Exercises

These exercises are designed to be run on v7_4_1 from $TUTORIAL_BASE/TrkAna

> whatever command to setup in docker
> cd $TUTORIAL_BASE/TrkAna

Exercise 1: Looking at the hits in the track

With TrkAna we can get information about the individual hits by setting diagLevel to 2

This #includes TrkAnaReco.fcl and then edits the diagLevel

Exercise 2: Analyzing a TrkAna tree with a compiled macro

Write a compiled macro that loops through each event and uses the TrkInfo branches. This can just run TrkAnaReco.fcl

Exercise 3: Retraining TrkQual

This can just run TrkAnaReco.fcl but want to highlight that the TrkQualInfo is written out with the candidate.trkqual Write out trkqual branch and retrain with a different background weight expression (or a different sample?) Run in parallel with original TrkQual

Exercise 4: Estimating the DIO background (with event weighting)

Run on flateminus-mix with DIO weights and plot that

Exercise 5: Creating your own "TrkAna" tree using InfoStructs

For this exercise, you should know how to write an art module.

Explain info structs and info struct helper to create a new module to create a simple tree (need to know module writing)?

Reference Materials

  • Use this place to add links to reference materials.
  • TrkAna wiki page

A Useful Glossary

ROOT
data analysis framework developed at CERN
KalSeed
data product that represents a track
CeEndpoint-mix
dataset name for CeEndpoint (i.e. mono-energetic electrons) with background frames mixed in
CeplusEndpoint-mix
dataset name for CeplusEndpoint (i.e. mono-energetic positrons) with background frames mixed in
flatmugamma-mix
dataset name for flatmugamma (i.e. flate energy photons generated at muon stopping positions) with background frames mixed in
KalFinalFit
the module name for the final stage of the Kalman filter fit for the track
TrkQual
an artificial neural network (ANN) that takes parameters from the track and outputs a value between 0 (poorly reconstructed) and 1 (well-reconstructed)