<div dir="ltr"><div><div><div><div><span style="font-family:arial narrow,sans-serif"><font>Hi Mohammad, Nathan and All,<br><br></font></span></div><span style="font-family:arial narrow,sans-serif"><font>I have implemented several modified routines from Stepan in our software to solve the segmentation fault issue that was occasionally <font>happening</font><font> <br>

</font>while reading the RF TDC time for some data-files, and also to fix the false return of <font>a</font> .not. operator whenever applied to a true logical <font>expression!</font><br>I believe these changes won&#39;t affect Mohammad&#39;s drift path study results, but it might affect the particle identification and a time determination <br>

in CLAS based on Nathan&#39;s comparison (<a href="https://mailman.jlab.org/pipermail/eg6_analysis/2013-December/000357.html">this email</a>), in which he reported some changes in a trigger time and a neutral particles id. between <br>

Pass1_v1 and the new OS cooked files. For a quick check, I processed 10 files of a run 61448, which you can find in this directory: <br>/volatile/clas/claseg6/tgemRHL6_v3/1p2gev/. But If <font>you need more data</font> for this comparison I can process more<font><font>;</font> either reprocess the <font>same files <br>

that Mohammad used in his stud<font>y for both beam energ<font>ies</font> or <font>others based on your preferences. <br><br></font></font></font></font></font></span></div><span style="font-family:arial narrow,sans-serif"><font><font><font><font><font><font>Thank you,<br>

<br></font></font></font></font></font></font></span></div><span style="font-family:arial,helvetica,sans-serif"><font><font><font><font><font><font><font><span style="font-family:arial narrow,sans-serif">Lamiaa</span><br>

<br></font></font></font></font></font></font></font></span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 16, 2014 at 4:18 PM, Nathan Baltzell <span dir="ltr">&lt;<a href="mailto:baltzell@jlab.org" target="_blank">baltzell@jlab.org</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Mohammad &amp; EG6,<br>
<br>
I am noticing some strange things with this new data.  While the<br>
yields in dz(CLAS-RTPC) peak are increased like your good track<br>
yields, S/B ratio is smaller than it used to be (but maybe that<br>
is ok).  Next, the width of the peak is larger.  So I looked at<br>
dz vs theta, and that same dependence of the peak position in<br>
pass1v1 is now at least 3x larger.   Also, if you look at it as<br>
function of z, things are quite different:  as you move upstream,<br>
dz peak gets washed out, whereas before it was pretty clear at<br>
all vertices.  Do you see the same?  I don&#39;t think any of these<br>
effects are coming from the electron vertex, as a quick event-by-<br>
event scan shows the electron vertex is basically unchanged, and<br>
the beam windows haven&#39;t moved.<br>
<br>
Any ideas?  I put a few of these plots on the wiki:<br>
<a href="https://clasweb.jlab.org/rungroups/lowq/wiki/index.php/Gempass1v2nab" target="_blank">https://clasweb.jlab.org/rungroups/lowq/wiki/index.php/Gempass1v2nab</a><br>
<br>
It might be useful to see some more plots of the change in<br>
reconstructed quantities for the overlap events.  Like<br>
dz/dtheta/dp versus theta/z (you already showed dp vs z).<br>
<br>
And maybe we should go ahead and recook the rest of 1 GeV to<br>
look closer at elastics once 64bit user_ana issues are resolved.<br>
<br>
Regards,<br>
Nathan<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Thu, 16 Jan 2014 11:02:16 -0600, &lt;<a href="mailto:hattawy@ipno.in2p3.fr">hattawy@ipno.in2p3.fr</a>&gt; wrote:<br>
<br>
&gt; Hello Nathan,<br>
&gt;    For the new region which is around 2 rad in phi, it is not totally new<br>
&gt; region. If you see in the previous cooking it exists but not very<br>
&gt; clear.<br>
&gt;<br>
&gt;    About the 60% increase in the 1.2 GeV, yes the TDCmax and the drift<br>
&gt; speed they are consistent in the two method with a variation of 1%. It<br>
&gt; is not clear for me why we have this increase. It might be the fact<br>
&gt; that we compared the drift speed of the golden elastic events to the<br>
&gt; one of good tracks. If you can have a look at the two versions of<br>
&gt; cooking for 1.2 runs, you will see the distributions of sdist, edist<br>
&gt; and the other parameters getting narrower in the new cooking, while<br>
&gt; they have been wide before and large number of the tracks they were not<br>
&gt; included in the initial drift speed comparison.<br>
&gt;    The new cooked files are in:<br>
&gt; /volatile/clas/claseg6/gempass1_v2/6gev/<br>
&gt; /volatile/clas/claseg6/gempass1_v2/1p2gev/<br>
&gt;<br>
&gt;    The old cooking are in:<br>
&gt; /volatile/clas/claseg6/gempass1_v1/6gev/<br>
&gt; /volatile/clas/claseg6/gempass1_v1/1p2gev/<br>
&gt;<br>
&gt; Best regards,<br>
&gt; Mohammad.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;&gt; Hi Mohammad,<br>
&gt;&gt;<br>
&gt;&gt; Looks like you also picked up a region of phi that didn&#39;t even exist<br>
&gt;&gt; before (~2.2 rad)!<br>
&gt;&gt;<br>
&gt;&gt; Is it correct that there is 60% increase even in the 1.2 GeV runs that<br>
&gt;&gt; were being used<br>
&gt;&gt; for the previous calibrations?  I thought old and new drift speed were<br>
&gt;&gt; consistent there?<br>
&gt;&gt;<br>
&gt;&gt; And can you tell me where these newly cooked 10 runs are?<br>
&gt;&gt;<br>
&gt;&gt; Regards,<br>
&gt;&gt; Nathan<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Thu, 16 Jan 2014 09:57:42 -0600, Mohammad Hattawy<br>
&gt;&gt; &lt;<a href="mailto:mohammad.hattawy@gmail.com">mohammad.hattawy@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;&gt; Dear all, As we have seen from the previous studies, the drift speed is<br>
&gt;&gt;&gt; changing during the experiment. I have been working on correcting the<br>
&gt;&gt;&gt; drift speed. New correcting &gt;parameters are extracted and implemented<br>
&gt;&gt;&gt; in<br>
&gt;&gt;&gt; the cooking package. Selected 10 test runs were recooked with these new<br>
&gt;&gt;&gt; modifications.<br>
&gt;&gt;&gt; I did a study of the performance of these corrections. As a result, we<br>
&gt;&gt;&gt; collect more good tracks in the RTPC. This incease is ranging from 60%<br>
&gt;&gt;&gt; to 126%.  A detailed &gt;study can been found here:<br>
&gt;&gt;&gt; <a href="https://clasweb.jlab.org/rungroups/lowq/wiki/index.php/Drift_Speed_Correction:_Results" target="_blank">https://clasweb.jlab.org/rungroups/lowq/wiki/index.php/Drift_Speed_Correction:_Results</a><br>


&gt;&gt;&gt;<br>
&gt;&gt;&gt;  Comments and suggestions are greatly appreciated.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; --Best regards,<br>
&gt;&gt;&gt; Mohammad Hattawy._______________________________________________<br>
&gt;&gt; Eg6_analysis mailing list<br>
&gt;&gt; <a href="mailto:Eg6_analysis@jlab.org">Eg6_analysis@jlab.org</a><br>
&gt;&gt; <a href="https://mailman.jlab.org/mailman/listinfo/eg6_analysis" target="_blank">https://mailman.jlab.org/mailman/listinfo/eg6_analysis</a><br>
&gt;&gt;<br>
_______________________________________________<br>
Eg6_analysis mailing list<br>
<a href="mailto:Eg6_analysis@jlab.org">Eg6_analysis@jlab.org</a><br>
<a href="https://mailman.jlab.org/mailman/listinfo/eg6_analysis" target="_blank">https://mailman.jlab.org/mailman/listinfo/eg6_analysis</a><br>
</div></div></blockquote></div><br></div>