Project

General

Profile

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
    Single Hit timing resolution as function of PE.
  • 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.

    In the plot, you can see the MC Cosmic distribution in blue and the WIMPSIM distribution in red
  • 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 distribution for well-reconstructed muon tracks.
    In this plot we show the Chi2 distribution for the DDUpmu background sample:
    No cuts
    Good track cuts only
    Good track cuts and LLR 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 (basically it is an anti-sun).
    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 (we should double check this - but it does not matter very much because the muon angle relative to the parent neutrino is large compared to the angular size 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.

Questions from Aris, Thur 10/4/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 14 - You show the difference between data and MC for the old gain. Then in slide 19, you show the difference between WIMPs sim and old gain and it seems that WIMPs sim is towards the direction of the data. Do you expect then a smaller systematic from timing tuning that the one that you showed on slide 14?
    Yes, in principle the systematic is smaller. For simplicity, we will use the same systematic. This systematic is small and does not limit the sensitivity in any significant way.
  • Slide 17 - Can you also show the “New gain (140), old track value (0.99)” as you show for the data?
    TABLE TO MAKE=New gain (140), old track value (0.99)
    Yes, we should do this. In the meantime, to be conservative, we are taking the difference between the “New gain” new linearity value (.95) MC and the “New gain” old linearity value (.99) as the systematic derived from this study.
    So, about a 20% uncertainty on trigger uncertainty in the MC. The MC predicts that the total efficiency of the analysis is reduced by 5% when the trigger is included (slide 22). So, this 5% is 20% uncertain, yielding a 1% uncertainty on the signal yield due to this effect. So, even taking 20%, the effect is small on the analysis.
  • Slide 20 - In the first row that you get 71% efficiency from the trigger, can you elaborate more? This is WIMPs simulated events you actually pass from the online trigger and you get this value? If I compare this with slide 22 the trigger has an effect of ~32% (4550/14039) efficiency. So maybe I didn’t understand the procedure here.
    Slide 20 is trying to give a feeling for the efficiency of the timing cuts in the trigger for the analysis (chi^2, prob, and LLR). The chi^2 is tight, and it reduces the number of events significantly. What the table shows is that if you apply the trigger track quality you remove lots of events (mostly lower energy signal that have shorter tracks or fewer hits). The trigger timing cuts reduce the signal acceptance by 30%, but they reduce the background (not shown on this slide) by many orders of magnitude. On slide 22 we are showing the effect of adding the trigger simulation module in addition to the offline “tight” selection. You can’t really extract the same information here. The takeaway is that if we use the trigger in addition to all of the tight offline selection it reduces the efficiency of the analysis by only about 5%.
    "4550/14039" are raw event in one case with the trigger, and in the other case without. I think it is difficult to compare anything with the “trigger initial” or the “number of entries” numbers because are before any cuts and depend on how we cut out events that we have no chance of detecting in the simulation chain. Better to use numbers after basic track quality is applied.
  • Slide 21 - I assume the different kinematic cut values between the trigger and offline are because of different reconstruction algorithms between the two. Can you elaborate on how you chose the different numbers? Is it related to page 16 and 17 to match the efficiencies?
    The cuts are tighter offline to avoid issues with the trigger turn on. We don’t want to be very sensitive to how well we estimate the trigger efficiency. The offline cuts can’t be exactly the same because, as you suggest, the algorithms are different in the trigger. The results are similar, but we cut tighter offline both avoid issues with trigger efficiency and reduce background.
  • Slide 43 - I assume the top row are generated events and the bottom row is passing from Geant and include the geometry (any maybe FLSHit module?). Maybe you explained this but I missed it, why the Y position is fixed? Also what are the red lines in the top histograms?
    The top row is the location the neutrinos are started to propagate on a plane below the detector. The bottom row is the location of the neutrino interaction vertex that produced a muon. This is a check to make sure that none of the vertices are near the edges of the production plane. That proves that the plane was large enough to sample all of the neutrinos that contribute to our acceptance.