[Halld-offline] possible problems with DChargedTrackHypothesis

[semenov at jlab.org]

Michael and Paul:

In my plots, I have the only tracks that are matched with the showers in
BCAL; t1_detector values for the events I selected are always equal 4
(that corresponds to BCAL, I hope).

Paul: I'll produce "beta-vs-momentum" 2-dim plots. (Probably,
"mass^2-vs-momentum" plots will be interesting also.)

Thank you,
Andrei




> Right.  You should probably make separate plots for whether m_t1_detector
> is either SYS_BCAL, SYS_TOF, or SYS_FCAL.
>
> The t0 one should hopefully always be SYS_RF.
>
>  - Paul
>
> On Apr 27, 2016, at 3:58 PM, Michael Staib <mstaib at andrew.cmu.edu> wrote:
>
>> Hi Andrei,
>>
>> Have you checked that every track has the same m_t0_detector and
>> m_t1_detector? I wouldn’t be surprised if there is some lingering
>> differences in the timing between the possible t0 and t1 detectors here.
>>
>> There is no plan to improve the calibrations in that old data, but feel
>> free if you find that it helps.
>>
>> --
>> Michael Staib
>> Graduate Student, Dept. of Physics
>> Carnegie Mellon University
>> mstaib at cmu.edu
>> phone: 412-268-2983
>>
>>
>>
>>> On Apr 27, 2016, at 3:42 PM, semenov at jlab.org wrote:
>>>
>>> Paul:
>>>
>>> The requested 2-dim plots for pions+/-, protons and K+ are in the
>>> attachment.
>>>
>>> Though the statistics is not very high, the 2-horn structure is still
>>> visible for pions as well as a lot of "too-high-speed" events.
>>>
>>> Does it help?
>>>
>>> Thank you,
>>> Andrei
>>>
>>>
>>>
>>>> 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>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Halld-offline mailing list
>>>> Halld-offline at jlab.org
>>>> https://mailman.jlab.org/mailman/listinfo/halld-offline
>>> <run3180-2d.pdf>_______________________________________________
>>> Halld-offline mailing list
>>> Halld-offline at jlab.org
>>> https://mailman.jlab.org/mailman/listinfo/halld-offline
>>
>
>