[Halld-offline] possible problems with DChargedTrackHypothesis

Wed Apr 27 15:58:26 EDT 2016

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-offline/attachments/20160427/564f8aad/attachment-0002.html>