<html>
<head>
</head>
<body dir="auto">
<div><br>
</div>
<div id="AppleMailSignature">That is correct: there is no impact to the low intensity run due to this particular issue (and the effect on the high intensity run can be minutes minimized/eliminated with reprocessing of REST production).</div>
<div id="AppleMailSignature"><br>
</div>
<div id="AppleMailSignature">Matt<br>
<br>
<div>----</div>
<div>This message was sent from my iPhone.</div>
</div>
<div><br>
On Sep 14, 2017, at 8:06 PM, Curtis Meyer <<a href="mailto:cmeyer@cmu.edu">cmeyer@cmu.edu</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>Hi Matt -
<div class=""><br class="">
</div>
<div class=""> does this mean the low-intensity was not impacted by this? Curtis<br class="">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
---------</div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">
Curtis A. Meyer<span class="Apple-tab-span" style="white-space: pre;"> </span>MCS Associate Dean for Research<br class="">
Phone: (412) 268-2745<span class="Apple-tab-span" style="white-space: pre;"> </span>
Professor of Physics<br class="">
Cell: (412) 260-6290<span class="Apple-tab-span" style="white-space: pre;">
</span>Carnegie Mellon University<br class="">
Fax: (412) 681-0648<span class="Apple-tab-span" style="white-space: pre;">
</span>Pittsburgh, PA 15213<br class="">
<a href="mailto:cmeyer@cmu.edu" class="">cmeyer@cmu.edu</a><span class="Apple-tab-span" style="white-space: pre;">
</span><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.curtismeyer.com_&d=DwMFAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=VNruI5B3_Ie9AiOp0_GgpPscd-lfGLx1DNIPlMbQfwQ&m=3g7TnUJ5BPV4Rk_fLjlMLDK3V0n9eeTkOyhehFtuiPE&s=RLzF0ADMEgMwjf11qdh4ABInhLWvB4DuUF6eEgaz1a8&e=">http://www.curtismeyer.com/</a></div>
</div>
</div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Sep 14, 2017, at 6:30 PM, Shepherd, Matthew <<a href="mailto:mashephe@indiana.edu" class="">mashephe@indiana.edu</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class=""><br class="">
Hi all,<br class="">
<br class="">
Justin reported yesterday in the production meeting that there is an apparent reduction in FCAL efficiency in the spring high intensity running. We've been digging into this and thanks to Sean's detective work, we are now pretty sure we understand what happened.<br class="">
<br class="">
Summary:<br class="">
<br class="">
A bogus set of channel-by-channel timing offsets was used in the high-intensity reconstruction which ultimately resulted in efficiency loss.<br class="">
<br class="">
Good news:<br class="">
<br class="">
* It has nothing to do with HV setting or raw data, i.e., it is recoverable. It is only correlated with HV changes because we intentionally redetermined timing constants for the different HV set points.<br class="">
<br class="">
Bad news:<br class="">
<br class="">
* Recovery requires reprocessing the data.<br class="">
* FCAL efficiency and resolution will be degraded in a nontrivial way (with polar angle dependence) for the existing REST data for the high intensity run.<br class="">
* The current REST version of high-intensity run is not usable for DNP for any analysis that depends on getting efficiency correct as implementing this effect in the MC is slightly nontrivial.<br class="">
<br class="">
Details:<br class="">
<br class="">
Attached is a plot generated by Sean of the timing offset that gets applied to each channel in the high intensity run. Units are in ns. The variations across channels in the high intensity running are simply unphysical. There is no way to get differences
on the scale of 20-30 ns between neighboring channels as observed. (It is not yet known whether this is a mistake or a breakdown of the existing calibration procedure due to some other "feature" of the high intensity run, e.g., a crate level timing shift
that the algorithm didn't respond well to.)<br class="">
<br class="">
The efficiency loss happens because in the clustering routine we make a loose timing cut: hits must be within 15 ns of the maximum energy hit in order to be added to the cluster. Therefore, the key problem with these buggy timing offsets is not the absolute
scale, but the fact the offset is much more *inhomogeneous* in the outer regions than the inner regions. In the outer regions, depending on which block is the "seed" block of the cluster, the neighboring block may not be added to the cluster because it fails
the timing cut.<br class="">
<br class="">
To demonstrate that this is correct, we widened the timing cut:<br class="">
<br class="">
-PFCAL:TIIMING_CUT=200<br class="">
<br class="">
And this resulted in a significant increase in pi0 yield in our pi0 skims.<br class="">
<br class="">
In addition, if FCAL timing is used elsewhere in any capacity, e.g., neutral hypothesis evaluation in the analysis library, then additional efficiency losses are possible.<br class="">
<br class="">
It turns out the timing offsets problem has a side-effect on the gain constants that Justin noticed last night. Because one tends to randomly thrown away hits that are incorrectly deemed to be out of time in outer regions of the FCAL, then there is a tendency
to compensate for this energy loss by boosting the gains of the blocks. The result is a suspicious-looking 2D distribution of gain constants (also attached) for the high intensity running. <br class="">
<br class="">
It goes without saying that making either the plot Sean or Justin made with the actual gain constants used for reconstruction would have raised alarm bells. While we have monitoring plots for data, we may consider having standardized visual depictions of constants
that we can check prior to launch. <br class="">
<br class="">
Our immediate plan is to use low intensity time offsets for the high-intensity running and then redetermine the gain constants using the "histogram fit adjust" method developed by Mike and Will at CMU, which seems to handle edge-effects better than the previous
method. This is the minimum thing that needs to be done before reprocessing of the high-intensity run can start.<br class="">
<br class="">
This effect most certainly led to resolution degradation in the high intensity run. It remains to be seen if any of this is linked to the apparent large floor term we see in the energy dependence of the resolution.<br class="">
<br class="">
Matt<br class="">
<br class="">
<br class="">
Timing offsets plotted by Sean:<br class="">
<span id="cid:6531BABB3D85874292D29674A512CC6B@exchange.iu.edu"><toffsets_r31001.pdf></span><br class="">
<br class="">
Gain constants plotted by Justin:<br class="">
<br class="">
<br class="">
<span id="cid:B7D85F39DAE4CC488790413066C91CDA@exchange.iu.edu"><PastedGraphic-2.tiff></span><br class="">
<br class="">
---------------------------------------------------------------------<br class="">
Matthew Shepherd, Professor<br class="">
Department of Physics, Indiana University, Swain West 117<br class="">
727 East Third Street, Bloomington, IN 47405<br class="">
<br class="">
Office Phone: +1 812 856 5808<br class="">
<br class="">
_______________________________________________<br class="">
Halld-cal mailing list<br class="">
<a href="mailto:Halld-cal@jlab.org" class="">Halld-cal@jlab.org</a><br class="">
<a href="https://mailman.jlab.org/mailman/listinfo/halld-cal">https://mailman.jlab.org/mailman/listinfo/halld-cal</a></div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
</body>
</html>