[Halld-offline] possible problems with DChargedTrackHypothesis

[semenov at jlab.org]

Hello Curtis,

Who's Alex?

Andrei :)


> Dear Alex,
>
>  my understanding is that you do not need a google account to use this,
> but the
> level of management is a lot better than other products.
>
> Curtis
> ---------
> Curtis A. Meyer			MCS Associate Dean for Faculty and Graduate Affairs
> Wean:    (412) 268-2745	Professor of Physics
> Doherty: (412) 268-3090	Carnegie Mellon University
> Fax:         (412) 681-0648	Pittsburgh, PA 15213
> curtis.meyer at cmu.edu	http://www.curtismeyer.com/
>
>
>
>> On Apr 26, 2016, at 6:35 PM, semenov at jlab.org wrote:
>>
>> 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>
>>>
>>>
>> <tdiff-160423.pdf>_______________________________________________
>> Halld-offline mailing list
>> Halld-offline at jlab.org
>> https://mailman.jlab.org/mailman/listinfo/halld-offline
>
>