Using the MC generated for 400 days (USMC hasn't changed since then) I plot the corrected charge as a function of distance to the wall along the track direction (distwall) assuming various different attenuation corrections. Which ever gives flattest responce is then The length to use to correct the MC of water attenuation, and is the length I wish my stoppers to be able to find.
Here is the page (many images) containing comparisons in energy and assumed attenuation length. The code to generate the histograms is in work/stopper/ideal_atten.c. The kumac as well as a format conversion script and the table generating script are in this current page.
It seems that there is a slight energy dependence on which attenuation length to use. I am not altogether sure what this is due to.
My sample of 1250 MeV electrons is pretty slim, so I am generating 100, 1500 MeV electrons now. This should help to show if the energy dependence is strong out to higher energies. If the detector response is relatively independent of energy for a give assumed attenuation length for the energy region 1Gev +/i 0.5GeV, it is probably okay to let this slide.
So, 65m is still the target USMC attenuation length for the correction. I will tune the stopping muon code to try to produce this length. Any differences will be assumed to be linear and just corrected for.
The data of run 3033 has a long tail which goes up to high charge, above 200pe, even for relatively high Distance From Track. This could be because run 3033 is shortly after the increase in attenution length due to changing water filters, or it could be some aspect which USMC does not handle correctly. What ever it is, it leads to a significant effect in the attenuation length measurement due to forced PMT saturation at 200pe. To check this, I am stripping of an earlier run, 2145, from DLTs 70 and 71. This is running on skdeca2 and is going to /u/skdeca3a/scratch/bviren to the file mbvec.002145.dlt07.data and can be monitored by looking at out.2145.dlt07. skdeca3 has been flaky recently (like you can't log in) but still doesn't seem to mind NFS serving. Hopefully it will stay up long enough to at least finish this.