[Halld-offline] possible problems with DChargedTrackHypothesis

[semenov at jlab.org]

Paul:

You suggestion to use the google group is not good for me because I do not
have google account, and I do not want create it because of the google
demand to share my cell phone number. I do believe that we are working for
JLab (not for the Google corporation), so we should use JLab computer
resources. I would suggest to use "halld-offline" e-mail list. Sorry and
thank you for understanding. (Alternatively, some shared "gluex" account
for google might be a solution, but in this case it will be not obvious
why's actually the author of the specific communication.)

Talking of "t0 is set to the chosen RF time, propagated to the vertex-z of
the track": Am I correct that in this case, "t0" should be exactly the
same as "T" value from the DVertex class? (If yes, it's strange because
"t0" is close to the "T" from DVertex, but not exactly the same.)

By the way, how the "t1" value is produced? Is it some estimation from the
chambers timing, or it came from the "t1_detector" (which is in my case
always =4; I hope that it corresponds to BCAL). If the last is correct,
how good this "t1" value is? (Meaning time-walk corrections, channels
alignment etc.)

My plot contains all PIDs.

Talking of multiple hypotheses, I do believe that "PID" in this class is
not a vector but one number. Does it mean that "DChargedTrackHypothesis"
vector size is always bigger than the size of the correspondent
"DTrackTimeBased" vector (that contains one record per one "real" track, I
hope)?

I do not agree that the right-column plots do not help. In the case of
multiple hypotheses (viz., unknown particle mass), the right-column plot
(which presents the TOF minus the time needed to travel the pathLength
distance with the speed-of-light) shows that we have a lot of tracks with
TOF that suggests that the particle travels much faster than
speed-of-light (negative values in the histogram). If we do not consider
tachyons seriously, it means that the "TOF" value has some problems.

I'll produce the "(TOF-L/(beta*C)) vs momentum" 2-dim plots you suggested,
but it will require a few hours on our computers; I hope that it will be
ready tomorrow. (I'm not quite sure why you want to see "momentum
dimension": most probably, it will be just horizontal bands. But OK, no
problem. Note that I can not just plot "TOF vs momentum" because different
pathLengths.)

Thank you,
Andrei




>
> On Apr 25, 2016, at 8:26 PM, pmatt at jlab.org wrote:
>
>You may know this, but for the record, when you call
> DKinematicData::TOF(), it is subtracting t1 - t0. In the
> DChargedTrackHypothesis factory, t0 is set to the chosen RF time,
> propagated to the vertex-z of the track.
>
> Are you histogramming this for all PID hypotheses?  Or are you always
> picking the ones with the same PID? (e.g. proton)  Remember, each
> physical track has multiple hypotheses, for different PIDs.  If you chose
> all hypotheses, then only one can be correct, and you will see funny
> structures.  Although yes, they would not give rise to the right-column
> plots.  However, the tracks certainly aren’t going at beta = 1, so the
> right plots don’t help much.
>
>You should have separate plots for each PID, and then you should make this
> a 2D plot vs. track momentum, and you will see a mass dependence that
> will give rise to the structures.  You should see distinct pion, proton,
> etc. bands.
>
> - Paul
>
>************************************************************************
>
> We now have a new method of asking software questions, a google group:
> gluex-software at googlegroups.com
>
> I am about to forward this message to there, and then will try to answer
> it there when I have time.  If you are not part of the group yet, please
> sign up:
>
> https://groups.google.com/forum/#!forum/gluex-software
>
>  - Paul
>
> On Apr 25, 2016, at 6:46 PM, semenov at jlab.org wrote:
>
>> Paul, Mark and Simon:
>>
>> I'm trying to use the information from DChargedTrackHypothesis, and I
>> see
>> the things I do not understand. If I plot "TOF" (from the class) minus
>> the
>> time-of-flight "pathLength*sqrt(mass*mass+pmag*pmag)/pmag/c" (that I
>> calculated from the variables in the class) for the charged tracks that
>> are matched with the showers in BCAL, I see some interesting structure
>> (see the top-left panel in the attached file) instead of expected
>> centered-at-zero peak with the RMS of the order of the uncertainty on
>> TOF
>> (0.4-0.5ns). The bottom-left panel shows the same-variable histogram
>> with
>> the requirement to have 3 or more charged tracks in the event (to be
>> sure
>> that we have a good start time).
>>
>> For the "mass", I used the "PID" hypothesis in the class. To be sure
>> that
>> this structure is not affected much by PID hypothesis, I plotted also
>> the
>> histograms for "TOF-pathLength/c" (see the right column in the file);
>> everything that is visibly below zero are "tachyons" :) that means that
>> the problem is probably with the "TOF" variable which is the difference
>> between "t1" (stop time) and "t0" (start time) variables. "t0" is pretty
>> close to the "vertex" time "T" from DVertex class.
>>
>> As you can see from the plot, the peaks in the structure are not
>> separated
>> with 4-ns intervals, so I would not blame "wrong-RF-bucket" reason.
>>
>> For this plot, I used run 3180, and my version of sim-recon is 1.10 .
>>
>> Most probably, I just using something incorrectly, and you already have
>> a
>> good explanation for the plots I see. Could you please help me?
>>
>> Thank you,
>> Andrei<tdiff-160423.pdf>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tdiff-160423.pdf
Type: application/x-pdf
Size: 29405 bytes
Desc: not available
URL: <https://mailman.jlab.org/pipermail/halld-offline/attachments/20160426/5d67b756/attachment-0001.bin>