aboutsummaryrefslogtreecommitdiff
path: root/src/fit.c
diff options
context:
space:
mode:
authortlatorre <tlatorre@uchicago.edu>2018-09-21 12:54:04 -0500
committertlatorre <tlatorre@uchicago.edu>2018-09-21 12:54:04 -0500
commite867ac29427b58fba1a86558aecfa85f9c706635 (patch)
treec79325bf192a805a3eae50e04054e1e33cfa6b08 /src/fit.c
parent7c06ffe328064f5354a0fe971d082d33c1008749 (diff)
downloadsddm-e867ac29427b58fba1a86558aecfa85f9c706635.tar.gz
sddm-e867ac29427b58fba1a86558aecfa85f9c706635.tar.bz2
sddm-e867ac29427b58fba1a86558aecfa85f9c706635.zip
split up the track integral into two intervals
This commit updates the likelihood calculation to split up the track integral into two intervals in some cases. I noticed when fitting some events that the likelihood value would change drastically for a very small change in the fit parameters. I eventually tracked it down to the fact that the track integral was occasionally returning a very small charge for a PMT which should have a very high charge. This was happening because the region of the track which was hitting the PMT was very small and the cquad integration routine was completely skipping it. The solution to this problem is a bit of a hack, but it seems to work. I first calculate where along the track (for a straight track) the PMT would be at the Cerenkov angle from the track. If this point is somewhere along the track then we split up the integral into two intervals: one going from the start of the track to this point and the other from the point to the end of the track. Since the cquad routine always samples points near the end of the intervals this should prevent it from completely skipping over the point in the track where the integrand is non-zero.
Diffstat (limited to 'src/fit.c')
0 files changed, 0 insertions, 0 deletions