| Age | Commit message (Collapse) | Author |
|---|
|
This commit adds code to read in the PMT response from the PMTR bank from
SNOMAN. This file was used for the grey disk model in SNOMAN and was created
using a full 3D simulation of the PMT and concentrator. Since the PMT response
in SNOMAN included the quantum efficiency of the PMT, we have to divide that
out to get just the PMT response independent of the quantum efficiency.
I also updated the likelihood calculation to use the pmt response. Currently
the energy is being fit too high which I think will improve when we update the
solid angle calculation to use the radius of the concentrator instead of the
PMT.
|
|
This commit adds a fast function to calculate the expected number of PE at a
PMT without numerically integrating over the track. This calculation is *much*
faster than integrating over the track (~30 ms compared to several seconds) and
so we use it during the "quick" minimization phase of the fit to quickly find
the best position.
|
|
This commit fixes a bug in the charge PDF calculation for n > MAX_PE. The
standard deviation should scale like sqrt(n)*qstd where qstd is the standard
deviation of the single PE charge distribution.
|
|
|
|
This commit updates path_eval() to calculate theta0 using the residual
scattering RMS for a truncated KL expansion. Since there isn't a nice closed
form solution for this, we instead compute a rough approximation by evaluating
the residual scattering RMS at the center of the track.
|
|
|
|
|
|
For some reason the fit seems to have trouble with the kinetic energy.
Basically, it seems to "converge" even though when you run the minimization
again it finds a better minimum with a lower energy. I think this is likely due
to the fact that for muons the kinetic energy only really affects the range of
the muon and this is subject to error in the numerical integration.
I also thought that maybe it could be due to roundoff error in the likelihood
calculation, so I implemented the Kahan summation to try and reduce that. No
idea if it's actually improving things, but I should benchmark it later to see.
|
|
This commit updates the initial guess for the energy using a simple heuristic
of ~6 hits/MeV. I also updated the initial phase where we do a bunch of "quick"
minimizations to loop over a series of starting positions and automatically
calculate the approximate direction and t0 for the event.
|
|
|
|
This commit updates the fit_event function to first do a series of "quick"
minimizations to try and find a good set of starting parameters for the "real"
fit.
I also updated the bounds on theta and phi since having hard bounds on these
angle coordinates could prevent the fitter from finding the minimum.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I found when simulating high energy muons that the expected charge for some
PMTs which should be getting hit was zero. The reason for this is that the
integrand was very sharply peaked at the Cerenkov angle which makes it
difficult to integrate for numerical integration routines like cquad. To solve
this I split up the integral at the point when the track was at the Cerenkov
angle from the PMT to make sure that cquad didn't miss the peak. However,
calling cquad twice takes a lot of time so it's not necessarily good to do this
for all fits. Also, it's not obvious if it is necessary any more now that the
angular distribution calculation was fixed.
I think the real reason that cquad was missing those integrals was that for a
high energy muon the range is going to be very large (approximately 40 meters
for a 10 GeV muon). In this case, I should really only integrate up to the edge
of the cavity or PSUP and hopefully cquad picks enough points in there to get a
non zero value.
I also added a check to only compute tmean when at least one PMT has a valid
time. This prevents a divide by zero which causes the likelihood function to
return nan.
|
|
|
|
spaced
|
|
|
|
|
|
|
|
|
|
This commit updates the likelihood fit to use the KL path expansion. Currently,
I'm just using one coefficient for the path in both x and y.
|
|
|
|
refraction
|
|
Previously I had been assuming that a particle undergoing many small angle
Coulomb scatters had a track direction whose polar angle was a Gaussian.
However, this was just due to a misunderstanding of the PDG section "Multiple
scattering through small angles" in the "Passage of particles through matter"
article. In fact, what is described by a Gaussian is the polar angle projected
onto a plane. Therefore the distribution of the polar angle is actually:
(1/(sqrt(2*pi)*theta0**2))*theta*exp(-theta**2/(2*theta0))
This commit updates the code in scattering.c to correctly calculate the
probability that a photon is emitted at a particular angle. I also updated
test-likelihood.c to simulate a track correctly.
|
|
To fit the path of muons and electrons I use the Karhunen-Loeve expansion of a
random 2D walk in the polar angle in x and y. This allows you to decompose the
path into a sum over sine functions whose coefficients become random variables.
The nice thing about fitting the path in this way is that you can capture
*most* of the variation in the path using a small number of variables by only
summing over the first N terms in the expansion and it is easy to calculate the
probability of the coefficients since they are all uncorrelated.
|
|
|
|
|
|
|
|
|
|
|
|
photons
|
|
|
|
The GSL library only has the Nelder Mead Simplex algorithm for doing
multidimensional minimization without gradient information. The nlopt library
has lots of different minimization algorithms so it's easier to switch between
them to see which one works best.
|
|
The RMS scattering angle calculation comes from Equation 33.15 in the PDG
article on the passage of particles through matter. It's not entirely obvious
if this equation is correct for a long track. It seems like it should be
integrated along the track to add up the contributions at different energies,
but it's not obvious how to do that with the log term.
In any case, the way I was previously calculating it (by using the momentum and
velocity at each point along the track) was definitely wrong.
I will try this out and perhaps try to integrate it later.
|
|
|
|
|
|
There was no entry for heavy water at
http://pdg.lbl.gov/2018/AtomicNuclearProperties/index.html, so I emailed Don
Groom who maintains the website. Amazingly he agreed to rerun the code to add
an entry for D2O.
Apparently all of the old Fortran code was not set up to deal with isotopes,
but he updated everything and reran the code for heavy water! The new results
are at http://pdgprod.lbl.gov/~deg/AtomicNuclearProperties/ but they should
make it to the main page soon.
|
|
|
