[Halld-offline] possible problems with DChargedTrackHypothesis

Paul Mattione pmatt at jlab.org
Wed Apr 27 17:31:36 EDT 2016 

Also, try only plotting for events where DEventRFBunch::dNumParticleVotes is >= 2.  There should only be one such object in JANA (with default tag).  I think that cut was on when I plotted.  

Although you may have two tracks, they might not both have matching hits in the start counter.  

 - Paul

On Apr 27, 2016, at 5:27 PM, semenov at jlab.org wrote:

> 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
>>> 
>> 
>> 
> 
>

More information about the Halld-offline mailing list