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

Nathan Baltzell baltzell at jlab.org
Wed Jan 22 15:44:24 EST 2014 

Hi Mohammad,

Looks like the effects on momentum and theta are not too large
for the elastics you show (~1% and 0.1deg).  But it would be most
interesting to see how much change in reconstructed quantities
there is for the 6 GeV runs where the difference in the drift
speed compared to pass1v1 is much larger.  Maybe we need some
more 6 GeV files for that.

For the 1.206 GeV data, I actually see almost no change in
the number of good elastic tracks in the RTPC, but I get 30%
more good tracks in the dz(CLAS-RTPC) peak for 6 GeV.

Regards,
Nathan


On Wed, 22 Jan 2014 09:42:12 -0600, <hattawy at ipno.in2p3.fr> wrote:

> Hello All,
>   I updated the wiki page (
> https://clasweb.jlab.org/rungroups/lowq/wiki/index.php/Drift_Speed_Correction:_Results)
> with the new plots related to checking the performance of the drift
> speed corrections.
>   For the 1.2 GeV data at the beginning, The two cooking versions are
> consistent at the level of selecting good tracks. While, the newly
> cooked data have collected 15 % more elastic events. For the 6 GeV data,
> the same increase percentage has been achieved in collecting good
> tracks.
>
>   Suggestions are greatly appreciated.
>
> Best regards,
> Mohammad.
>
>
>
>
>
>> 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
>>>
>>>
>>

More information about the Eg6_analysis mailing list