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

Sun Jan 19 21:45:20 EST 2014

Hi Mohammad, Hi All,

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
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
processed 6 GeV data-files, which their cooking is not done yet, will go
eventually to this directory: /volatile/clas/claseg6/gempass1_v3/6gev/.

Best regards,

Lamiaa

On Fri, Jan 17, 2014 at 10:36 AM, <hattawy at ipno.in2p3.fr> wrote:

> Hello Nathan and All,
>    There was a problem with the previous test cooking. The TDCmax
> calculation needs the run number as input. I implemented it to be the
> runNum variable, but it seems not working. Attached two plots, the
> expected TDCmax vs. z from the corrections and the actual one we got
> from the previous test cooking.
>     My corrections include the runs from 61488 to 61960. I kept the
> previous formula for the runs which are not included in this range.
> This formula is: TDCmax = 53.1422 -0.0317579*z +0.00199476*z*z. This
> formula is giving us the concave up distribution of TDCmax which we
> got from cooking, while the corrections have to give concave down TDC
> vs. z distribution.
>     I have to investigate the variable runNum and make sure that it is
> referring to the run Number. Then i will cook some files to check if
> everything is going well and update the wikipage.
>
> Best regards,
> Mohammad.
>
>
>
>
> > 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
> >>
> > _______________________________________________
> > 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/20140119/36c9ddc5/attachment.html 