[Halld-offline] possible problems with DChargedTrackHypothesis

Wed Apr 27 16:20:17 EDT 2016

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
> 

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