<div dir="ltr"><div><div><div>Hi Mohammad, Hi All,<br><br></div>After the modification that Mohammad did to initialize the run number's variable properly before the new implemented drift path calculation is done, I have processed <br>
some runs of 1.2 GeV and 6 GeV data-set. The new 1.2 GeV cooked data are located in this directory: /volatile/clas/claseg6/gempass1_v3/1p2gev/. However, the <br>processed 6 GeV data-files, which their cooking is not done yet, will go eventually to this directory: /volatile/clas/claseg6/gempass1_v3/6gev/.<br>
<br></div>Best regards,<br><br></div>Lamiaa<br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 17, 2014 at 10:36 AM, <span dir="ltr"><<a href="mailto:hattawy@ipno.in2p3.fr" target="_blank">hattawy@ipno.in2p3.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Nathan and All,<br>
There was a problem with the previous test cooking. The TDCmax<br>
calculation needs the run number as input. I implemented it to be the<br>
runNum variable, but it seems not working. Attached two plots, the<br>
expected TDCmax vs. z from the corrections and the actual one we got<br>
from the previous test cooking.<br>
My corrections include the runs from 61488 to 61960. I kept the<br>
previous formula for the runs which are not included in this range.<br>
This formula is: TDCmax = 53.1422 -0.0317579*z +0.00199476*z*z. This<br>
formula is giving us the concave up distribution of TDCmax which we<br>
got from cooking, while the corrections have to give concave down TDC<br>
vs. z distribution.<br>
I have to investigate the variable runNum and make sure that it is<br>
referring to the run Number. Then i will cook some files to check if<br>
everything is going well and update the wikipage.<br>
<br>
Best regards,<br>
Mohammad.<br>
<br>
<br>
<br>
<div class="im"><br>
> Hi Mohammad, Nathan and All,<br>
><br>
> I have implemented several modified routines from Stepan in our software<br>
> to<br>
> solve the segmentation fault issue that was occasionally happening<br>
> while reading the RF TDC time for some data-files, and also to fix the<br>
> false return of a .not. operator whenever applied to a true logical<br>
> expression!<br>
> I believe these changes won't affect Mohammad's drift path study results,<br>
> but it might affect the particle identification and a time determination<br>
> in CLAS based on Nathan's comparison (this<br>
</div>> email<<a href="https://mailman.jlab.org/pipermail/eg6_analysis/2013-December/000357.html" target="_blank">https://mailman.jlab.org/pipermail/eg6_analysis/2013-December/000357.html</a>>),<br>
<div class="HOEnZb"><div class="h5">> in which he reported some changes in a trigger time and a neutral<br>
> particles<br>
> id. between<br>
> Pass1_v1 and the new OS cooked files. For a quick check, I processed 10<br>
> files of a run 61448, which you can find in this directory:<br>
> /volatile/clas/claseg6/tgemRHL6_v3/1p2gev/. But If you need more data for<br>
> this comparison I can process more; either reprocess the same files<br>
> that Mohammad used in his study for both beam energies or others based on<br>
> your preferences.<br>
><br>
> Thank you,<br>
><br>
> Lamiaa<br>
><br>
><br>
><br>
> On Thu, Jan 16, 2014 at 4:18 PM, Nathan Baltzell <<a href="mailto:baltzell@jlab.org">baltzell@jlab.org</a>><br>
> wrote:<br>
><br>
>> Hi Mohammad & 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'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'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>
>><br>
>><br>
>><br>
>> On Thu, 16 Jan 2014 11:02:16 -0600, <<a href="mailto:hattawy@ipno.in2p3.fr">hattawy@ipno.in2p3.fr</a>> wrote:<br>
>><br>
>> > Hello Nathan,<br>
>> > For the new region which is around 2 rad in phi, it is not totally<br>
>> new<br>
>> > region. If you see in the previous cooking it exists but not very<br>
>> > clear.<br>
>> ><br>
>> > About the 60% increase in the 1.2 GeV, yes the TDCmax and the drift<br>
>> > speed they are consistent in the two method with a variation of 1%. It<br>
>> > is not clear for me why we have this increase. It might be the fact<br>
>> > that we compared the drift speed of the golden elastic events to the<br>
>> > one of good tracks. If you can have a look at the two versions of<br>
>> > cooking for 1.2 runs, you will see the distributions of sdist, edist<br>
>> > and the other parameters getting narrower in the new cooking, while<br>
>> > they have been wide before and large number of the tracks they were<br>
>> not<br>
>> > included in the initial drift speed comparison.<br>
>> > The new cooked files are in:<br>
>> > /volatile/clas/claseg6/gempass1_v2/6gev/<br>
>> > /volatile/clas/claseg6/gempass1_v2/1p2gev/<br>
>> ><br>
>> > The old cooking are in:<br>
>> > /volatile/clas/claseg6/gempass1_v1/6gev/<br>
>> > /volatile/clas/claseg6/gempass1_v1/1p2gev/<br>
>> ><br>
>> > Best regards,<br>
>> > Mohammad.<br>
>> ><br>
>> ><br>
>> ><br>
>> >> Hi Mohammad,<br>
>> >><br>
>> >> Looks like you also picked up a region of phi that didn't even exist<br>
>> >> before (~2.2 rad)!<br>
>> >><br>
>> >> Is it correct that there is 60% increase even in the 1.2 GeV runs<br>
>> that<br>
>> >> were being used<br>
>> >> for the previous calibrations? I thought old and new drift speed<br>
>> were<br>
>> >> consistent there?<br>
>> >><br>
>> >> And can you tell me where these newly cooked 10 runs are?<br>
>> >><br>
>> >> Regards,<br>
>> >> Nathan<br>
>> >><br>
>> >><br>
>> >><br>
>> >> On Thu, 16 Jan 2014 09:57:42 -0600, Mohammad Hattawy<br>
>> >> <<a href="mailto:mohammad.hattawy@gmail.com">mohammad.hattawy@gmail.com</a>> wrote:<br>
>> >><br>
>> >>> Dear all, As we have seen from the previous studies, the drift speed<br>
>> is<br>
>> >>> changing during the experiment. I have been working on correcting<br>
>> the<br>
>> >>> drift speed. New correcting >parameters are extracted and<br>
>> implemented<br>
>> >>> in<br>
>> >>> the cooking package. Selected 10 test runs were recooked with these<br>
>> new<br>
>> >>> modifications.<br>
>> >>> I did a study of the performance of these corrections. As a result,<br>
>> we<br>
>> >>> collect more good tracks in the RTPC. This incease is ranging from<br>
>> 60%<br>
>> >>> to 126%. A detailed >study can been found here:<br>
>> >>><br>
>> <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>
>> >>><br>
>> >>> Comments and suggestions are greatly appreciated.<br>
>> >>><br>
>> >>> --Best regards,<br>
>> >>> Mohammad Hattawy._______________________________________________<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>
>> >><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>
>><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>
><br>
</div></div><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>
<br></blockquote></div><br></div>