[Sbs_gems] [New Logentry] Low SBS GEM efficiency is definitely NOT a software issue under current conditions

Sun Apr 21 22:20:02 EDT 2024

Logentry Text:
--
Reading Jimmy’s comment in his latest update (https://logbooks.jlab.org/entry/4285768) that “Nilanga has some hope this value can be increased with some software changes.” I feel strongly compelled to push back rather forcefully and throw some cold water on the notion that software has anything to do with this, to avoid fostering a sense of false hope that software can save us when we the hardware is operated with inadequate gain/detection efficiency. If we were running in a condition with north of 15-20% occupancy and only loose tracking constraints with almost no redundancy of the tracking geometry, then yes, the software as currently written could reduce the apparent tracking efficiency pretty substantially. But that is emphatically NOT what we are dealing with right now (other than the low redundancy of the tracking geometry). We already know what we should expect in these conditions, which is a high tracking efficiency, as already demonstrated with the low-current!
  LH2 elastic runs taken at the beginning AND with fully digitized Monte Carlo simulation of LH2 elastic scattering in this experiment with this setup, reconstructed using exactly the algorithm that is deployed on the counting house computers right now. Indeed, the Monte Carlo simulation was used to test the new code needed to analyze the data from this experiment.

Currently, in the back tracker GEMs we see VERY low occupancies (of order ~1-few %). The tracking code should have absolutely no trouble whatsoever dealing with this situation when the detector is working. In this experiment, with three independent tracking systems and HCAL measuring elastic scattering, we have multiple handles on the tracking efficiency beyond just the track-based calculation.

According to the Monte Carlo which includes the steel analyzer:

1) We should expect to find a good proton track in the back tracker about 65% of the time when we get a good elastically scattered electron track in BigBite AND above-threshold energy deposit in HCAL, and the back tracking is done constraining the tracks to point to the highest-energy cluster in HCAL.
2) If we restrict ourselves to the case where we ALSO reconstruct the proton track in the front tracker, with the front track constrained to point to the intersection of the back track with the midpoint of the analyzer, that should happen about 45% of the time.
3) If we further restrict ourselves to the case where we find both front and back proton tracks and the  reconstructed polar scattering angle is less than 0.15 radians (about 8.6 degrees), that should happen about 39% of the time. The reason I want to compare with small-angle scatterings in the analyzer is because I can then make a direct comparison to data.  

What we actually see with current conditions for LH2 elastic scattering is illustrated by the attached plot (from combined analysis of runs 271 and 272 (full replays).

The BLUE histogram shows the W^2 spectrum of events in BigBite with a basic preshower energy cut and a cut on the azimuthal correlation between BigBite and HCAL to select elastically scattered protons that SHOULD have been detected in SBS. These are events where the proton (or perhaps a forward neutron from charge-exchange) was detected in HCAL. The cut on the azimuthal correlation means the nucleon did not experience large-angle scattering in the analyzer.

The RED histogram shows the events where we find a good track in the SBS back tracker (without any other cuts on scattering angles or track quality other than the usual chi2, since cutting on the correlation with the front tracker also reduces the yield by the (also very low) tracking efficiency there).

The ratio of elastic peak integrals between red and blue histograms is 5.3%. This number should be compared to an expected ratio from simulation of at least 39% up to 65% with the most directly comparable event selection on HCAL. If I’m being generous I’ll say the current overall tracking efficiency in the back tracker relative to ideal is 5.3%/39% = 13.6%. But a more conservative estimate would be 5.3% / 65% = 8.2%. These estimates of tracking efficiency with 3 of 4 layers imply per-layer detection efficiencies of 36% and 30%, respectively. Either of these estimates is qualitatively consistent with what the track-based efficiency calculations are currently reporting, which supports my earlier claim that the track-based calculation is pretty reliable at these low occupancies. If I also require that we got a track in the front tracker and the polar scattering angle between back track and front track is less than 0.15 radians, I get the black histogram. The ratio of elasti!
 c peak integrals between the black histogram and the blue is 0.7%, while the ratio between the black and the red is about 13% (which roughly implies ~13% tracking efficiency in the front GEMs).

Finally, we can estimate the tracking efficiency from earlier in the experiment without relying on Monte Carlo. For straight-through run 83 (the low-current LH2 run taken at the beginning), I get about 90% tracking efficiency in SBS with the 8-layer tracking requiring a minimum of 4 out of 8 layers when I cut on W^2 and the BigBite-HCAL angular correlation (the SBS tracks are constrained to point at the highest-energy HCAL cluster). When I analyze the same run, but with the first four layers and the back four layers treated as separate trackers (“polarimeter mode”) I find a 65% probability to get a track in either the front or the back tracker when I cut on W^2 and the BigBite-HCAL angular correlation. As expected the tracking efficiency is lower with 3 out of 4 layers than with the more redundant 4 of 8, especially with so many holes in the acceptance, but it was still much higher at the beginning of the experiment than the currently observed 8-13.6%.

Anyway, in conclusion, all of these independent, assumption-free estimates of current software tracking efficiency are entirely consistent with what the track-based detection efficiency calculation is currently reporting. We know the software is reliable in these conditions because it DID work very well on both real data taken earlier and on Monte Carlo simulated data reconstructed using the same code.

Everyone needs to understand that the software, while far from perfect, is not currently the issue, and you cannot get good physics data from this experiment in the current operating condition of the hardware. I am NOT advocating attempting to operate the detectors in unsafe conditions, I just want to emphatically rule out that this has anything to do with software!

---

This is a plain text email for clients that cannot display HTML.  The full logentry can be found online at https://logbooks.jlab.org/entry/4285829
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/sbs_gems/attachments/20240421/6a2a2f16/attachment.html>