Upward-going muons analysis Q&A » History » Version 11
Upward-going muons analysis Q&A¶
Questions from Maury, Thur 9/27/2018:
Questions from docdb-32814 : https://nova-docdb.fnal.gov/cgi-bin/private/RetrieveFile?docid=32814&filename=UPMU_Collab_Completeversion_sep2018.pdf&version=3¶
- Slide 5 – I don’t understand this plot. If I fit a track, there will be many hits with many different numbers of PE. The time resolution will depend on the angles and length. But why do you plot it versus PE?
This is the single hit timing resolution, not the timing resolution of the fitted track. The time is extracted from the pulse shape recorded by the FEB, and has a dependence on the size of the pulse and the noise envelope of the board/apd.
The way we calculate this is by starting with a sample of cosmic rays and for hits that occur within a DCM :
a) We take the time for each hit in a track
b) We correct that time based on the distance from the readout and the time of flight, such that all the hits in a track should occur at the same time.
c) For each PE bin (25 PE), we calculate the difference between the corrected hit time
d) The spread of this difference, in each PE bin, gives us the single hit time resolution, as you can see in this plot
- Slide 6 – When you plot angle differences, it is a good idea to plot versus Dq2, instead of Dq, so that the statistics and errors are the same in each bin.
Agree. But this plot was made and blessed two years ago, not sure Leo or someone for him will be able to remake.
- Slide 8 – Is the overlap due to nearly horizontal tracks, or something else? (I see these get cut in slide 33. Is this plot before or after that cut?)
The overlap is primarily due to "poorly" reconstructed tracks with a low number of hits. Some of those are near horizontal or near vertical or going through the corner of the detector. The algorithm works well as long as there are plenty of hits in the x and y view in the tracks.
PLOT TO MAKE LLR vs Track Length (or # hits) and we need the LLR vs track angle.
- Slide 13 – There is no evidence of data and MC diverging at a c2 of 1.5. I don’t see any justification for that cut. Presumably, the MC is 100% cosmic ray single tracks, and the goal would be to cut out events that are something other than a single track.
This cut is to suppress track reconstruction failures.
We have 10^10 downward going tracks per day. We need to look at the chi2 background tracks passing directionality cuts to make a decision about where to cut. The rate of misreconstructed tracks that pass the timing cut has a high dependence on the quality of the timing fit.
The data/MC agreement we show is just a statement about the bulk of the ditribution for well-reconstructed muon tracks.
PLOT TO MAKE n-1 plot for the control region with ddupmu sample with/without and with loose Chi2 cut
- Slide 20 – What are “tight tracks”? If “trigger initial” and “offline initial” is 99% single track muons, the overall efficiency is under 5%, which seems low. (Or I don’ understand the slide.) The overall signal efficiency (slide 22) seems higher than that.
“tight tracks” are tracks that pass all your offline good track requirements (like length, num of hits, track linearity etc..)
So after you select those as the denominator, you are looking at the trigger efficiency associated specifically with the timing LLR cut.
NB: For this simulation (10GeV DM sample), there will be many tracks that are not long enough or have enough hits to pass the “tight” tracking requirements of the analysis (this is analysis is based on the through-going or long-track version of the trigger so that we can use cosmic-ray muons to check everything). So, the efficiency is somewhat low and would be much lower for a lower-mass hypothesis.
- Slide 23 – Since the sun does not go overhead, it would be good to see the fraction of events in each sample for our exposure.
In principle, there could be some signal events in the twilight and background samples, but the way we do our simulation does not allow us to calculate that (in the very first stage of WIMPSIM we cut the downward going muon). Even if we did not cut them, we use a generation plane below the detector, so we effectively restrict our signal simulation to the times when the sun is below the detector.
<!--- We have the full ephemeris for the sun and we have the exposure for each region mapped out by day. We also have the different paths taken accounted for the in normalization and we have a simulation method that mimics that path (selects against it).
We describe it here in details: https://nova-docdb.fnal.gov/cgi-bin/private/ShowDocument?docid=15860 -->
- Slide 33 – Are you using both triggers referred to in 24151?
Only the crossing. We think it is easier to start with that because you have a large sample of entering/through-going muons that can be used for control.
- Slide 35 – Rather than using the day, shouldn’t you use the night for the anti-sun? Given the angle cut, I don’t understand the relevance of the twilight sample.
The samples are based on the sun position - not the track angles. We should make sure that is clear. Basically, we are using the position of the sun at night to “fake” the position during the day so that we get the right angular distributions.
A better explanation of what’s actually being done can be found here: https://nova-docdb.fnal.gov/cgi-bin/private/ShowDocument?docid=15860
- Slide 39 – Do the events come from throughout the sun, the center of the sun, or something in between? For solar neutrinos, it is in between.
Generated at the center of the sun. Propagated out to 1AU. This gives the spectrum. Then spectrum is simulated at the flux plane below the detector.
- Slide 43 – I’m not sure I understand these plots, but it seems to me that every simulated neutrino-induced muon could be aimed at the detector
This is a brute force method for the simulation. It uses a flux plane that is much bigger than detector size to ensure coverage. It’s not optimal from a simulation/generation standpoint but works for how Wimpsim passed off the spectra and how we want to simulate full coverage of the detector volume.