Timon van Dieren

The main idea of my project is to reconstruct bremsstrahlung showers.
So far I have been studying mostly the track reconstruction algorithm.
It seems specific hits used in track reconstruction are not stored.
If they are not used, does the reconstruction not become biased?

Maarten: All hits in a specific road-width are used, so there is no bias.

I have looked at hits within [-10,+10] ns from the Cherenkov hypothesis and subdivided these in direct Cherenkov hits and other hits.
The time residual distribution for hits from all directions still seems skewed to the left.
This might have to do with double counting.

Thijs: Would it work to loop over all hits and project them back unto the track?

Timon: I think it is safer to discretize the track and compute the hit time residual distribution for all bins along the track.

Maarten: This is one event. It would be good to look at multiple events first. Once you have seen the behaviour at higher statistics, you can go back to the single event scenario.
I expect there is something wrong with the red time residual distribution on your slides. Would expect it to peak a lot more around zero.

Thijs: You have background hits as well here, no?

Timon: Yes, that's true.

One complication I currently deal with, is that I cannot straightforwardly calculate the number of shower photons.

Maarten: Be aware: For 10-100 GeV neutrino CC-interactions, you do not expect a huge amount of bremsstrahlung. It would be better to perhaps first look at atmospheric muon MC-files.

Dorothea: Agreed.

Next steps: Look at excess photons for high energy events.

Brían

I have continued studying the behaviour of the combined PDF in cases where I rotate the muon direction or the shower direction, whilst maintaining the relative direction between the shower and the muon.
Currently, I get dips at a time-residual value of zero for both ways of rotating.
In addition, the energies look a bit strange still and need further figuring out.

Some of this might be caused by the shower and muon being colinear in certain scenarios.
Also, I'm mostly evaluating background at the moment.
What I need to start doing is rotate all the tracks separately.
This would result in three rotations in total, one for the incoming neutrino track, one for the outgoing shower and one for the outgoing muon track.

Maarten: Three rotations sounds a little bit dangerous. Try to just do one rotation of the vertex and offset the second track with respect to the first (which is now in the z-direction).

Bouke: Wouldn't you also need to take into account the angle of the second track with respect to the PMT?

Maarten: The orientation of the PMT w.r.t. the tracks should not change a lot. Unless you are really unlucky and the shower and muon go either in very different directions or the PMT is very close.

Timon: Why can a shower and a muon track not be colinear?

Maarten: They can be, as long as the conservation laws are upheld.

Jordan

Worked on toy-MC in the last couple of weeks. Some bugs were fixed:

1.) python pushed hits by reference. Now they are copied.
2.) Now I sample the elongated shower PDF correctly.

The maximum likelihood is found at zero for the vertex x, y and z.
What I want to see is a negative log-likelihood below ~1 around the true minimum.

Plotting the negative log-likelihood distribution of the hit time, we see a couple of hits which are extremely unlikely (high -log(L)). The PMT hit time residuals corresponding to these tracks are very narrowly distributed away from zero.

Maarten: The narrow distribution of the hit times seems to indicate that these hits are just due to extremely bad luck. Could be due to prepulses or due to dispersion. Your code should be made safe against this.

Jordan: Is this really only bad luck? These hits seem to be created consistently.

Maarten: In real data you can get any feature of this kind. So we should find a procedure that safeguards against them.

Jordan: I agree with you that ultimately we want to shield against these. But right now I really want to scrutinize the code and find the bugs.

Maarten: Apparently we have events which occur more frequently than you would expect based on the associated probability from the PDF.

Jordan: It seems as if low-energy events create these unlikely hits much more frequently than the other hits.

When I cut on PMTs that are close, the likelihood distribution looks fine again.

Maarten: The unlikely hits could also be due to a numerical error. It's numerically extremely hard to estimate the first hit time, because the value of the PDF can get below the allowed numerical precision. Nevertheless, the PDF should never truly zero. So try to just add a tiny numerical value as fake background.

Maarten:

I wanted to share this plot that can be found on the ELOG also.
When I first saw it, I was extremely surprised, because, ideally, you want the gradient of the PDF in time to be zero exactly at the distance of closest approach, for all track events.
The fact that we don't see this here, seems to indicate that we are dealing with muon bundles instead of single muons, which the algorithm is clearly not tailored to at the moment.

Jordan: What is the Delta?

Maarten: I also looked at Delta-ray contributions. But this is not able to explain the effect in full.