-
Notifications
You must be signed in to change notification settings - Fork 2
Reconstruction Validation
At the highest level, the TMS exists to measure muons from LAr. So it needs to do 4 things:
- Separate muons from other junk
- Match to LAr exiting tracks
- Measure the momentum
- Measure the charge
A track is well reconstructed if it does all four things (more requirements can be added for other analyses). I'm going to go over the four things in detail, but I'll skip 1 for now. Its requirements make more sense when all the other items are explained.
The LAr and TMS have individual reconstructions. Each reconstruction creates list of track candidates. The LAr tracks are not sorted in time because the timing resolution is very poor. The TMS has fast timing resolution so we can first separate the hits in time and then perform tracking on them. The track matching looks at all the TMS track candidates in the first two planes and projects them back. If a LAr track is within 40cm in x in the back face of the LAr, and has an angle difference below some small angle, then the two are matched. In theory, we can add y information to get better tracking.
To reduce false positive rates, we try to prune the TMS tracks with some cuts. These will need to be tuned but the basic idea is to separate reconstructed tracks that started in the TMS vs LAr-starting tracks. The simplest technique is to remove all tracks that aren't in the first two planes. We might also add a cut that removes tracks from time slices that have too much energy that isn't on the track. This could indicate that the track is from a TMS-starting event, and that additional energy is from hadronic activity.
Presumably we also have cuts for LAr candidates. Currently we simply make sure the LAr candidate track is close enough to the end of the LAr.
We throw out TMS tracks that are beyond the first two planes. So if reconstruction misses the first several hits of a LAr-entering muon, then it will likely not be matched to the LAr.
We use the starting position and direction to match to LAr. So if the reconstruction has the wrong start position, or a bad angle, then it may cause the matching to go wrong.
We throw out tracks in slices with a lot of non-track energy. So if the track reco cuts off a track too early and doesn't find its end, then all that energy would be included as non-track energy. This might cause the track to be rejected.
Currently the momentum is measured using the areal density. Areal density is defined as the density times distance of each segment of the track. This is roughly proportional to the length, which is why it's called length in the code. A muon loses energy in proportion to the amount of material it travels through. So if we measure the material using the areal density, then we can measure the momentum by scaling by a constant.
We can also measure the momentum by curvature. This is because the curvature is proportional to q/p (charge / momentum), and that is measured by the kalman filter. But it is about 3x less accurate. But we may need to use it for some tracks that exit the TMS. But keep in mind that most of the curvature happens at the end of the track where its lost most of its momentum. TMS-exiting muons may have too much energy and will look mostly straight. For particles other than muons, we mostly measure energy by adding up the total visible energy, and multiplying by constant. This is far less accurate but needed for most hadrons. For muons, we can also look at multiple scattering. In some detector configurations, this can be used to detect large differences in muon energy, but it's very inaccurate.
Measuring the track areal density requires knowing the path of the muon in 3d space. We can get close to the right answer if we ignore y, but that causes about a 6% drop in energy resolution. With our setup, the u and v views can also cause some jumping of the track when they were treated as x planes. This previously made our track length too long, but we fixed it by only adding up the u views. Currently, the y position has large jumps. This is inaccurate for the purposes of calculating the path length because of the large vertical drops. So instead, we add up the track length in the u view only and again in v view only, and then average that number. So this is a version of ignoring y. I was hoping the kalman filter would smooth out y to make it match a realistic 3d path but that doesn't seem to be the case
On top of that, if the track is cut short, then the momentum reco will be too small. This can happen if reco ends too early. It can also happen if the particle leaves the TMS through the top or bottom. So good reco would be able to detect muons exiting with a good y resolution.
We currently measure charge by drawing a line from the start to the end of the track. Then we add up the number of hits on the top or bottom of that line
Charge is currently very depenedent on the starting and ending position of the particle. So those need to be most correct. But we also need to make sure to get all the hits from the track, and reject hits that are from other activity. If too many hits are skipped, or too many hits from other particles are included, that can tip the balance and cause the charge id to be incorrect. And the x positions of the hits need to be correct, or else too many will be on the wrong side of the start-end line, and the charge id will be incorrect.
Junk is a catch-all term. For the TMS's primary purpose, junk includes TMS-originating particles (including muons), rock muons, hadrons, muons which are poorly reconstructed, and muons that exit the TMS. But junk is relative: Exiting muons have an unknown track length (therefore unknown momentum), but we may be able to use them in a single 5+ GeV bin, for example.
If we find a match from the track matching, it's very likely a muon because of the overall track length. Other particles, like pions, could make long tracks too, but we haven't studied this in detail. There are additional things we can look at. For example, we can check the energy along the track looks like it's from a muon, or look for bragg peak at the end of the track, or look for michel electrons. We haven't studies those ideas in detail.
We mostly separate junk using the same requirements as LAr matching, including the non-track energy cut. A track that was matched from LAr is very likely a muon. Pileup studies are still needed to prove this. We also would like to check the y position to make sure it's contained to the TMS.
We need a good idea of starting and ending location of the muon. We also want the starting direction to be accurate. We also want to measure its areal density as accurately as possible. We'd like to measure the y position well enough to reject exiting muons. We also need to get the x positions of the hits correct for purposes of charge reco. And finally, we'd like to reject tms-starting events using non-track energy so we'd like to include all hits from the true muon on the reconstructed track. This is just Jeffrey's opinion, and I welcome corrections.
I've started work on some validation plots. See Tracking_Validation.cpp. But it written before writing this explainer: I think I'll update it to have a similar flow with high level plots relating to charge ID, muon momentum, good vs junk, and LAr matching.
Assuming you've run on some test files from Validating Changes, you can run like this. Output plots will be in /exp/dune/data/users/${USER}/dune-tms/Validation/Tracking_Validation
./Tracking_Validation ../../MiniProdN1p2_NDLAr_1E19_RHC.spill.00049.EDEPSIM_SPILLS_TMS_RecoCandidates_Hough_Cluster1_50k.root && python simply_draw_everything.py /exp/dune/data/users/${USER}/dune-tms/Validation/Tracking_Validation/MiniProdN1p2_NDLAr_1E19_RHC.spill.00049.EDEPSIM_SPILLS_TMS_RecoCandidates_Hough_Cluster1_50k.root
./Tracking_Validation ../../antineutrino.0_1715654453.edep_TMS_RecoCandidates_Hough_Cluster1.root && python simply_draw_everything.py /exp/dune/data/users/${USER}/dune-tms/Validation/Tracking_Validation/antineutrino.0_1715654453.edep_TMS_RecoCandidates_Hough_Cluster1.root
./Tracking_Validation ../../antineutrino.0_1713482441.edep_TMS_RecoCandidates_Hough_Cluster1.root && python simply_draw_everything.py /exp/dune/data/users/${USER}/dune-tms/Validation/Tracking_Validation/antineutrino.0_1713482441.edep_TMS_RecoCandidates_Hough_Cluster1.root
See my plots in /exp/dune/data/users/kleykamp/dune-tms/Validation/Tracking_Validation