[Hallc_sidis_analysis] TRacking parameters and efficiency

Mon May 25 09:00:34 EDT 2020

Hello all,
           I updated  THcHallCSpectrometer.cxx so that the "tr" branch will now have
all the info about that goes into the pruning. You need to use this branch:
https://github.com/JeffersonLab/hcana/tree/update-april2020

Peter and I have slightly different meanings of track efficiency. For me, the tracking efficiency
does not involved cuts on quantities that involve track information. I agree that the pruning
is helping with track selection so when there are more the two possible tracks
it will pick the better one when compared to the chi-square only test. So I would
definitely use pruning method.
     Now I also agree that eliminating events which are bad reconstruction is a good idea
and then correcting for these rejected events in needed. I would call that a good track
reconstruction efficiency. I make the distinction since traditionally in Hall C, the track efficiency
uses the goodscinhit with some PID based on non-track information.

If you are planning to use this branch, then you need to set the
default pedestals. Also the new code shifts each detector AdcTdcDiffTime by an
new hodoscope offset  that is the difference between the
hodo average adc and tdc times ( in addition to the start time). The "easiest"
is   to change the hhodo_adc_tdc_offset
probalby by -45 for all planes to get the HMS Hodoscope ADCTDC diff time to peak at zero.
It does not have to be exactly zero.
But you need to check if this is true. You also should check SHMS HOdo ADCTDC diff time
but that is usually close to zero. You will need to change the Hodo ADCTDC diff time windows,
though wiht the new code you are not so sensitive to the hodo windows being wrong.

With this change the ADCTDC diff time windows for the
other detectors should work unless you set them very tight.

Cheers,
                 Mark
________________________________
From: Mark Jones <jones at jlab.org>
Sent: Saturday, May 23, 2020 1:28 PM
To: Peter Bosted <bosted at jlab.org>; Dipangkar Dutta <ddutta07 at gmail.com>
Cc: hallc_sidis_analysis at jlab.org <hallc_sidis_analysis at jlab.org>
Subject: Re: TRacking parameters and efficiency

I quickly wrote a document about track selection in HCANA. If there are mistakes or nonsensical
statements, then let me know. If there needs to be more explanation then
let me know.

 I will work on a document for the tracking itself.

Since I keep getting asked about this, I will state that the track selection or
pruning does NOT effect the tracking efficiency. It may only change which
track (when there are2 or more possible tracks) is picked as the golden track.

Cheers,
           Mark
________________________________
From: Peter Bosted <bosted at jlab.org>
Sent: Friday, May 22, 2020 4:07 PM
To: Dipangkar Dutta <ddutta07 at gmail.com>
Cc: hallc_sidis_analysis at jlab.org <hallc_sidis_analysis at jlab.org>; Mark Jones <jones at jlab.org>
Subject: TRacking parameters and efficiency

Hi Hem, Jia, et al.,
    Most everything related to tracking is in for
example
/group/c-sidis/bosted/hallc_replay/PARAM19/SHMS/GEN/ptracking.param
(for spring19. I think I have same for PARAM_FALL19/...)
and similary there is /htracking.
    As you can see, this file is where you can turn on
the pruning software, and set the pruning parameters.
Perhaps Mark Jones has a writeup that he can send us that
explains how it works and what the variables are?
    Near the bottom of this file are the range of
scinitllator paddlee numbers to be used in defining
the goodscinhit variable, I think. I adjusted the limits
a little bit from what we had online. The idea is that
if paddles within these ranges go off, and all four
planes fire, geometrically there should be a track. These
limits are needed because the hodoscope array is slightly
bigger than the drift chambers (on purpose).
    I don't use the def-file cuts to obtain tracking efficiency. Instead, I
definie it myself in the code
/group/c-sidis/bosted/hallc_replay/PeterB.C
    Yous can see that for HMS, I require all kinds of good
things in the SHMS, plus goodscinhit, plus another variable
that I define that ensures that we had a good start time.
Then I have three counters, one for just a track, then with
a cut on hdelta, then with a cut on hbeta, then with a cut
of ytar. I used the tightest cut for my actual efficiency,
but the other ones are useful too.
    There is a place in the code where tracking efficiency
is obtained as a function of raw cointime (also defined
in my code). I didn't see any obvious dependance on this,
quantity.
    The output of PeterB.C is a "skimmed" set of events
that will be processed by another code to get cross
sections, etc. This is because it takes too long to
loop through 2510 root files each time I want a new
result. There is also a little report file that includes
that tracking efficiency and the reftime multiplicity
efficiency. Also some estimate of hodoscope efficiency
that is done differently than in hcana and put in the
REPORT FILES.
     My "skimmed" files are in plain text format which
I like because I can see everything in emacs, but most
analyzers make "skimmed" root files. Basically, just
keep the variables you really need and put cuts on
things like cointime, HMS cer and cal, perhaps aerogel,
and of course a good track. In the ideal world, you
should be able to process the "skimmed" files for the
entire set of experiments in an hour or less. The way
I work, this code actually produces another file for each
run, which are the number of counts in bins of
z, pt, phi*. I keep track of the number of reals and
accientals separately, and have three definitions. The
third one has the tightest cuts, but is meant to have
a more reliable pi-/pi+ ratio but reducing the kaon
contamination to a negligible level (for example, with
ceraero>4 npe). The same file also contains the number
of counts and total weight (times normfac) from SIMC
for each bin. I have seven sets of SIMC values:
SIDIS pi with radiation
SIDIS pi with no radiative tail
exclusive pion
SIDIS from endcaps
diffractive rho
SIDIS K with rad
SIDIS K no rad
    These come from the events files produced by SIMC,
which I store in the same plain test format as the
real data.
    I have other codes that process these "count files"
to obtain all the physics results, make plots, and fit
for physics parameters.
    Everyone does things differently, but that is my
method. I plan  combine runs at identical kinematics and
target together at some point to reduce the number of
bins that only have a few counts, because for those
bins the error bars is not Gaussian and it can be a
bit tricky to combine runs together at the cross section
level.
    Anyway, this might be more than you wanted to know,
but feel to ask more questions about tracking efficiency.
As I say, this is probably one of the most tricky parts
of the analysis to understand, because it is closely
tied up with other cuts and definitions. The best
thing to do is study the runs taken with different beam
current and make sure that your final yield does
not depend on beam current. For example, runs 5368-3478.
These runs had aerogel tray SP11 by the way.
After months and months of work, I'm more or less
satisfied now. Make sure you're using Mark's new
version of hcana, his new matrix elements for HMS, and
new matrix elements for SIMC.
    Feel free to ask more questions!
     Peter

Prof. Peter Bosted
email: bosted at jlab.org
phone: (808) 315-1297 (cell)
P.O. Box 6254, Ocean View, HI 96737

On Thu, 21 May 2020, Dipangkar Dutta wrote:

> Hi All,
> We will have the regular CSV analysis meeting tomorrow
> (Friday) at 1:00 PM EDT
>
> The Meeting URL is
> https://bluejeans.com/341030850
>
> Please plan on showing a few slides on your work and
> please upload the
> slides to the SIDIS elog at:
> https://hallcweb.jlab.org/elogs/SIDIS+Pt+and+CSV+Exper
> iments+Analysis
>
>
> Cheers
> Dipangkar
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/hallc_sidis_analysis/attachments/20200525/c1b48c28/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: HCANA_pruning.pdf
Type: application/pdf
Size: 141675 bytes
Desc: HCANA_pruning.pdf
URL: <https://mailman.jlab.org/pipermail/hallc_sidis_analysis/attachments/20200525/c1b48c28/attachment-0001.pdf>