[Halld-offline] possible problems with DChargedTrackHypothesis

Michael Staib mstaib at andrew.cmu.edu
Wed Apr 27 17:40:13 EDT 2016 

Hi Andrei,

Ok, that rules that out then. There are definitely edges in your plots at +- 2ns. This would point to some RF bunch selection issue. I’d follow Paul’s suggestion. If you want to quickly check the quality of the timing calibrations, run the plugin “HLDetectorTiming” along with yours. Of particular interest would be the histograms in the SC_Target_RF_Compare and the TRACKING directory. These seem OK in the last version of the offline monitoring, but if these have shifted, it could throw off the selection.

-Mike


--
Michael Staib
Graduate Student, Dept. of Physics
Carnegie Mellon University
mstaib at cmu.edu
phone: 412-268-2983



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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-offline/attachments/20160427/a75e72c9/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2016-04-27 at 5.36.26 PM.png
Type: image/png
Size: 53334 bytes
Desc: not available
URL: <https://mailman.jlab.org/pipermail/halld-offline/attachments/20160427/a75e72c9/attachment-0002.png>

More information about the Halld-offline mailing list