Weekly Research Report

Andrew William Watsonsites.temple.edu/awwatson

10 July 2013 – 17 July 2013

Abstract

This is my weekly laboratory / research report for the week of Wednes-day 10 July 2013 to Wednesday 17 July 2013. My Wordpress lab journalis hyperlinked above. This abstract will be longer than future ones be-cause I’ll be describing this report’s format on this initial version. Below,sections are numbered and named after large projects I’ve made progresson during the past week; section names are analogous to the large bulletedcategories on my wordpress page. Progress will not be broken down daily,as it is on my wordpress, rather, it will be presented here in a summaryformat, with subsections included in each section if categories need to bebroken down further (for example, a section titled Coding may be brokendown into DarkArt, C++, and Geant4. Also, please excuse my (likely)terrible LATEX for the first few lab reports...it’s been a while.

1 API-120 and Source Deployment Arm

1.1 Summary

If we leave its flange as it is, we can just fit the API-120 and its attachedphotodetector within a 6in ID tube. We have enough space for a 3mm thickshell around the apparatus if we take it as-is. However, if we can trim just 0.5infrom the radius of the 4.75in diameter flange, we can enclose the API-120 in anabsolute minimum radius tube of 2.35in, giving us plenty of room to design asurrounding enclosure for it.

1.2 Calculations

Note: By and large, I attempted to round all pixel measurements down, andall inch measurements up, increasing our in/px ratio to take into account thecrude nature and potential measurement error of the API-120 drawing whichwe’ve been given. However, I’m sure I missed some opportunities to better take

1

Figure 1: Highly non-technical, end-on drawing of API-120

the error into account. Given the conclusions above (that removing a bit of theradial extent of the flange would greatly improve our ability to fit the apparatusinto a 6in ID tube), however, small errors in measurement may be negligible.

We want to calculate the minimum circumcircle radius of the apparatusseen in Figure 1. To do this, we must first calibrate the previously markedmeasurements on the diagram (in inches) to the standard ruler we have for thedrawing, namely the grid of pixels on which it appears. The red markings on thefar bottom and far right of the diagram give some calibration measurements.

We can see that the 6.25in width stretches from pixel no. 61 on the left topixel no. 349 on the right. This means that

349− 61 = 288px = 6.25in (1)

This gives us a conversion of 0.02170139in/px or exactly 46.08px/in.

Similarly, on the right, the height marked 3.397in stretches from pixel no.320 at the top to pixel no. 478 at the bottom. This means that

478− 320 = 158px = 3.397in (2)

This gives us a conversion of exactly 0.0215in/px or 46.5116279px/in.

A third calibration can be done with the diameter of the apparatus. It’smarked as 3.187in. The radius runs from the center at (205.5, 404.5) to thebottom of the circle at (205, 478). It’s worse for us if the in/px ratio is larger,because is makes our “measured” lengths from this drawing larger, making it

2

harder for us to fit the apparatus down the source deployment arm. Thus, I’llround the center to (205, 405) (a shorter distance between the center and thecircumference means fewer pixels which means a larger in/px ratio). This givesus a radius of 73px, and a diameter of 146px = 3.187in, giving us a conversionof 0.02182877in/px or 45.8111076px/in.

Finally, Jim Simpson from Thermo Fisher also sent Dr. Martoff an email onWed 17 Apr 2013 which read, in part, “...the OD of the PMT flange is 4.75in indiameter and can certainly be smaller and have different mounting holes. The2.75in ID is necessary to fit onto the tube.” Meaning that the pink markings onthe drawing should be 4.75in apart horizontally. This gives us

315− 95 = 220px = 4.75in (3)

giving us a conversion of 0.02159091in/px or 46.3157895px/in.

Recalling that a larger in/px is desirable, because it accounts for all possiblemeasurement errors from this crude diagram, we will use our final calibration,rounded up to 3 significant digits. Thus, on this drawing, we can conclude that0.0219in = 1px or (when converting in the opposite direction) 45.9px = 1in.

In Jim’s email, he also mentioned that there are “end cap screws”, which“stand proud of the 3.00in OD housing by 4mm. The end cap screws standproud of the 3.19in OD end caps by 2 mm.” If there is an end cap screw atthe very bottom of the 3.19in OD end cap, this gives us an additional 2mm =0.0787402in (0.0788in rounded up) = 3.6px (3px, rounded down). This gives usan actual ”bottom” point of (205.5, 481).

In another email with Jim (Mon 10 June 2013), Dr. Martoff mentionedthat he had talked with SensL and that “their devices are only 2.2 mm thickincluding the package, and are read out over a cable (no electronics on thephotodetector).” This means we only need to add 2.2mm to the top of ourdiagram to account for the photodetector which will be attached. Roundingthis up gives 3mm = 0.12in (0.11811in) = 5px (5.5px). Thus, our three “top”points are, from left to right, {(95, 279), (205.5, 267), (315, 279)}. (Recallthat this is a *.jpg image, so distances to points are measured from the top-leftcorner.)

We need a circumcircle which contains all four points. Since the top-middlepoint is to close to the horizontal line separating the outside top points, it’sreally a non-issue. We need a circumcircle which can contain the three points{(95, 279), (315, 279), (205.5, 481)}.

These three points give us an isosceles triangle with a height of 481px - 279px= 202px = 4.43in (4.4238in), a base of 315px - 95px = 220px = 4.82in (4.818in),and side lengths of

√(4.43in)2 + (0.5× 4.82in)2 = 5.05in (5.043114117in).

If we allow the base to equal a, and the other two sides to be b and c (where

3

b = c), we can use the formula found at bit.ly/hJbDP5 to calculate:

(abc)/√

(a + b + c)(b + c− a)(c + a− b)(a + b− c)

= (ab2)/√

(2b + a)(2b− a)(a)(a)

= (ab2)/√

(4b2 − a2)(a2)

= (ab2)/√

(2ba)2 − a4

= (4.82in× 5.052in2)/√

(2× 5.05in× 4.82in)2 − (4.82in)4

= 2.88in (2.873302716in)

(4)

...meaning we have roughly 0.12in of radial space to work with, enough for atleast a 3mm thick shell.

Recall that this is an absolute minimum value, with all calculations roundedup. Better technical drawings of the API-120 could facilitate a higher minimumradius.

If we can trim the flange to a negligible radius, such that we needn’t evenconcern ourselves with it, then our minimum circumcircle radius simply becomeshalf the distance between the top and bottom of the apparatus in our drawing.This gives a minimum radius of

0.5× (481px− 267px) = 0.5× 214px = 107px = 2.35in (2.3433in) (5)

This would give the vertical center point of this minimum circumcircle as

(481px + 267px)× 0.5 = 748px× 0.5 = 374px (6)

so that the center point would be (205.5px, 374px). Since the top of the flangehas a fixed vertical (y) position of 279px, we can calculate its maximum hori-zontal extent using a simple distance formula.

√(x2 − x1)2 + (y2 − y1)2 = r√

(x2 − 205.5px)2 + (279px− 374px)2 = 108px

(x2 − 205.5px)2 + (−95px)2 = (108px)2

(x2 − 205.5px)2 = 2639px

x2 − 205.5px = 51px (51.371198156px)

x2 = 256px (256.5px)

(7)

This means, if we can trim a radial length of

279px− 256px = 23px = 0.51in (0.5037in) (8)

we can achieve a minimum possible overall circumcircle radius of 2.35in. If afull half inch reduction isn’t possible, it’s clear that smaller we can make theflange, the more room we free up, regardless.

4

2 Cerenkov Background Problem

2.1 Summary

The Cerenkov light background is no longer an issue. Alfredo has confirmedthat the cuts he used to eliminate Cerenkov events in the PMTs apply equallywell to events in the Teflon cylinder of the inner detector.

2.2 Background

Though I misunderstood what we were discussing at first, Dr. Martoff, PeterMeyers, and I had a conversation a few weeks ago about a “Cerenkov Back-ground Problem”, which I assumed had something to do with the light distribu-tion in Alfredo’s optical Monte Carlo. It turns out that those two issues reallyhave nothing to do with each other. Peter’s concern was that Cerenkov lightproduction in DS-50 might be a significant source of background. The MC LightDistribution Problem will be discussed in the next section.

The Cerenkov background problem has been investigated previously. InJuly of 2012, Alex Wright performed a monte carlo study of Cerenkov lightproduction in DS-50 (Doc #402 on the DS docdb), suggesting that Cerenkovlight could be a serious–even limiting–source of background.

However, Alfredo ran a follow-up study (Doc #527 on the DS docdb) inFebruary 2013 which showed all Cerenkov events could be removed from thedata with a few cuts. Specifically, he threw away events which had a significantfraction of the light in one PMT. This makes sense if a lot of light is generatedin the windows if the PMTs, or their Teflon mounts, but Peter didn’t think itwould have any effect on Cerenkov light generated in the large Teflon cylinderof the inner detector.

Alfredo went ahead and did some more MC runs last week (8 July), updat-ing his Cerenkov table to include events generated within the Teflon cylinder(bit.ly/12wfc73), confirming that the Cerenkov background is no longer an issue.

3 MC Light Distribution Problem

3.1 Summary

The photons emitted by events generated in Alfredo’s optical MC are, on thewhole, much more evenly distributed than is seen in the laboratory, especiallywhen the events are localized near the center of the detector. Christy wasworking on this problem just before she graduated this past fall, and, as far asI know, no one has picked up the torch since then.

5

3.2 Background

Though there was nothing in her thesis specific to the issue of improper light dis-tribution in the optical MC, Christy Love wrote an entry in the DS-10 AnalysisLogbook (blackhole.lngs.infn.it/wordpress/?p=1868) titled “S2 Light Distribu-tion: MC vs. Data” on 4 October 2012, describing a rather glaring discrepancybetween optical data acquired from the actual DS-10 detector, and optical dataacquired from the MC which simulates that same detector.

As can be seen in Figures 2 through 5, there are major differences betweenthe acquired data and the simulated data in DS-10. There are four major issueswith these data:

1. MC shows >500 fewer events giving more than 30% of the light in a singletube (analysis focused on center tube [0] and one perimeter tube [1])

2. MC gives a different overall light distribution than Data when events arelocalized near the center of the detector

3. Data shows many more events with much larger fractions of overall lightyield, especially on the max channels

4. MC and data give similar light distributions on the center tube when theevents are localized near the perimeter of the detector. Similar, but stilltoo dissimilar for comfort, I’d say.

Overall, the MC is detecting light which is much more evenly distributed through-out the detector than we’re seeing with the actual data, especially when theevents are localized near the center of the detector. Perhaps hard-coded driftvelocities are set too high? Or indices of refraction too low? This would allowthe light to spread out more evenly than it does in actuality, no?

6

Figure 2: Histogram: S2 Light Fraction on Ch0 (Max Ch0 & 30%)

Figure 3: Histogram: S2 Light Fraction on Ch1 (Max Ch0 & 30%)

7

Figure 4: Histogram: S2 Light Fraction on Ch1 (Max Ch1 & 30%)

Figure 5: Histogram: S2 Light Fraction on Ch0 (Max Ch1 & 30%)

8

4 General MC Problems

4.1 Summary

My download of Alfredo’s optical MC isn’t working. Statistics of consecutiveruns are exactly the same, which presumably shouldn’t be happening, even ifno parameters are changed in main all.C in between runs. Apparently this hasbeen a problem for a while, since histograms of the hundred 1000-event runswhich I ran this past fall all have identical statistics. Christy has been unableto help me remedy this problem, and Alfredo and John have yet to respond tomy SOS-es.

4.2 Background

And last but not least, I would be working more on the light distributionproblem...if my MC worked. Following the directions given to me by Christy(bit.ly/13vsqjh), which are nearly identical to the directions included with thedownload (bit.ly/12GsqS4).

I followed these directions several months ago, when I was initially setting upthe MC to run on my laptop. It seemed to work fine then, and I ran one hundred1000-event simulations, adjusting the LAr drift velocity, gAr drift velocity, andtau liquid extraction independently, roughly ±10% at a time.

Since, initially, I didn’t know how to make histograms from the ROOT filesgenerated by the MC, I built a repository of the hundred output files and plannedto look at them later. This past week, I used Christy’s macro (which just appliessome basic cuts and gives the same four figures shown in the previous section)to analyze these data files, and all of the output files were exactly the same.Not just the same mean, or the same RMS error, exactly the same. To me,this suggests that, not only do the parameters I changed have no (or at least anegligible) effect on the light distribution, but there’s some random seed whichisn’t being re-generated from run to run.

I attempted making ridiculous changes to the code to see if anything I coulddo would affect the outcome of the histograms. Figures 10 and 11 are the S2light distributions for a MC run where in Figure 10, lardftvel = 0.20 (thedefault), but in Figure 11, lardftvel = 0.00.

As you can see, there’s a small change in the statistics, but the overall shapeand distribution is effectively unchanged. Finally, because I thought I maybe using too few events (the two runs just mentioned only had one hundred220keV events), I ran two 5000-event runs. Surely, I thought, there must besome random seed which doesn’t allow consecutive runs to have exactly thesame statistics.

As Figures 12 and 13 show, I was mistaken. I’ve reached out to Christy,

9

Figure 6: My Histogram: S2 Light Fraction on Ch0 (Max Ch0 & 30%)

Figure 7: My Histogram: S2 Light Fraction on Ch1 (Max Ch0 & 30%)

10

Figure 8: My Histogram: S2 Light Fraction on Ch1 (Max Ch1 & 30%)

Figure 9: My Histogram: S2 Light Fraction on Ch0 (Max Ch1 & 30%)

11

Figure 10: S2 light histogram when lardftvel = 0.20

Figure 11: S2 light histogram when lardftvel = 0.00

12

Figure 12: First S2 light histogram with 5000 220keV full-volume events

Figure 13: Second S2 light histogram with 5000 220keV full-volume events

13

John, and Alfredo for help, but Christy hasn’t been able to help me solve myproblem, saying she’s never seen her MC do anything like this. John and Alfredohave yet to respond to my emails. I asked Christy if I could checkout the MCfrom a different repository than argus, but she said that’s the only one thathosts the monte carlo. She suggested downloading it from her home directoryon blackhole, but since her graduation, that’s been deleted. It looks like I’mstuck until Alfredo can help me figure out what’s going on.

14