[Halld-offline] possible problems with DChargedTrackHypothesis

[semenov at jlab.org]

Mike and Paul:

The attachment contains 2-dim plots ("beta-vs-momentum" and
"mass^2-vs-momentum") for pions+/-, protons, K+, and all PIDs. The file
"run03180_votes_160427.pdf" is for my plugin alone, and the file
"run03180_votes_HLDetectorTiming_160428.pdf" is for my plugin together
with "HLDetectorTiming" plugin. Both files were produces with
"dNumParticleVotes>=2" condition, and both are for the one data file from
the run 3180.

looking on the plots, I would say that neither "beta" plots nor "mass^2"
plots show any good bands + we have a lot of events with "beta>1"
("mass^2<0")...

So I would like to ask my question again: How the "t1" time (in the
DChargedTrackHypothesis class) is produced? Is it the time that came from
BCAL (in my case), or it's some projection of the time from the chambers?
(Or something else?)

Now I'm running the same plots for the file 10913.

Thank you,
Andrei



> 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 --------------
A non-text attachment was scrubbed...
Name: run03180_votes_160427.pdf
Type: application/pdf
Size: 93169 bytes
Desc: not available
URL: <https://mailman.jlab.org/pipermail/halld-offline/attachments/20160429/d301b08b/attachment-0004.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: run03180_votes_HLDetectorTiming_160428.pdf
Type: application/pdf
Size: 105967 bytes
Desc: not available
URL: <https://mailman.jlab.org/pipermail/halld-offline/attachments/20160429/d301b08b/attachment-0005.pdf>