[Eg6_analysis] Checking the performance of the extracted drift speed corrections

Thu Jan 16 23:46:27 EST 2014

Hi Mohammad, Nathan and All,

I have implemented several modified routines from Stepan in our software to
solve the segmentation fault issue that was occasionally happening
while reading the RF TDC time for some data-files, and also to fix the
false return of a .not. operator whenever applied to a true logical
expression!
I believe these changes won't affect Mohammad's drift path study results,
but it might affect the particle identification and a time determination
in CLAS based on Nathan's comparison (this
email<https://mailman.jlab.org/pipermail/eg6_analysis/2013-December/000357.html>),
in which he reported some changes in a trigger time and a neutral particles
id. between
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:
/volatile/clas/claseg6/tgemRHL6_v3/1p2gev/. But If you need more data for
this comparison I can process more; either reprocess the same files
that Mohammad used in his study for both beam energies or others based on
your preferences.

Thank you,

Lamiaa

On Thu, Jan 16, 2014 at 4:18 PM, Nathan Baltzell <baltzell at jlab.org> wrote:

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