<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Right. You should probably make separate plots for whether m_t1_detector is either SYS_BCAL, SYS_TOF, or SYS_FCAL. </div><div><br></div><div>The t0 one should hopefully always be SYS_RF. </div><div><br></div><div> - Paul</div><br><div><div>On Apr 27, 2016, at 3:58 PM, Michael Staib <<a href="mailto:mstaib@andrew.cmu.edu">mstaib@andrew.cmu.edu</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Andrei,<div class=""><br class=""></div><div class="">Have you checked that every track has the same <span style="color: rgb(51, 51, 51); font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; white-space: pre; background-color: rgb(255, 255, 255);" class="">m_t0_detector and </span><span style="color: rgb(51, 51, 51); font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; white-space: pre; background-color: rgb(255, 255, 255);" class="">m_t1_detector? </span><span style="background-color: rgb(255, 255, 255);" class=""><font color="#333333" class=""><span style="white-space: pre;" class="">I wouldn’t be surprised if there is some lingering differences in the timing between the possible <font face="Menlo" class="">t0</font> and <font face="Menlo" class="">t1 </font>detectors here. </span></font></span></div><div class=""><span style="background-color: rgb(255, 255, 255);" class=""><font color="#333333" class=""><span style="white-space: pre;" class=""><br class=""></span></font></span></div><div class=""><span style="background-color: rgb(255, 255, 255);" class=""><font color="#333333" class=""><span style="white-space: pre;" class="">There is no plan to improve the calibrations in that old data, but feel free if you find that it helps.</span></font></span></div><div class=""><font color="#333333" face="Consolas, Liberation Mono, Menlo, Courier, monospace" class=""><span style="white-space: pre; background-color: rgb(255, 255, 255);" class=""><br class=""></span></font><div class="">
<div class=""><div class="">--</div><div class="">Michael Staib</div><div class="">Graduate Student, Dept. of Physics</div><div class="">Carnegie Mellon University</div><div class=""><a href="mailto:mstaib@cmu.edu" class="">mstaib@cmu.edu</a></div><div class="">phone: 412-268-2983</div></div><div class=""><br class=""></div><br class="Apple-interchange-newline">
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On Apr 27, 2016, at 3:42 PM, <a href="mailto:semenov@jlab.org" class="">semenov@jlab.org</a> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Paul:<br class=""><br class="">The requested 2-dim plots for pions+/-, protons and K+ are in the attachment.<br class=""><br class="">Though the statistics is not very high, the 2-horn structure is still<br class="">visible for pions as well as a lot of "too-high-speed" events.<br class=""><br class="">Does it help?<br class=""><br class="">Thank you,<br class="">Andrei<br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">Paul:<br class=""><br class="">You suggestion to use the google group is not good for me because I do not<br class="">have google account, and I do not want create it because of the google<br class="">demand to share my cell phone number. I do believe that we are working for<br class="">JLab (not for the Google corporation), so we should use JLab computer<br class="">resources. I would suggest to use "halld-offline" e-mail list. Sorry and<br class="">thank you for understanding. (Alternatively, some shared "gluex" account<br class="">for google might be a solution, but in this case it will be not obvious<br class="">why's actually the author of the specific communication.)<br class=""><br class="">Talking of "t0 is set to the chosen RF time, propagated to the vertex-z of<br class="">the track": Am I correct that in this case, "t0" should be exactly the<br class="">same as "T" value from the DVertex class? (If yes, it's strange because<br class="">"t0" is close to the "T" from DVertex, but not exactly the same.)<br class=""><br class="">By the way, how the "t1" value is produced? Is it some estimation from the<br class="">chambers timing, or it came from the "t1_detector" (which is in my case<br class="">always =4; I hope that it corresponds to BCAL). If the last is correct,<br class="">how good this "t1" value is? (Meaning time-walk corrections, channels<br class="">alignment etc.)<br class=""><br class="">My plot contains all PIDs.<br class=""><br class="">Talking of multiple hypotheses, I do believe that "PID" in this class is<br class="">not a vector but one number. Does it mean that "DChargedTrackHypothesis"<br class="">vector size is always bigger than the size of the correspondent<br class="">"DTrackTimeBased" vector (that contains one record per one "real" track, I<br class="">hope)?<br class=""><br class="">I do not agree that the right-column plots do not help. In the case of<br class="">multiple hypotheses (viz., unknown particle mass), the right-column plot<br class="">(which presents the TOF minus the time needed to travel the pathLength<br class="">distance with the speed-of-light) shows that we have a lot of tracks with<br class="">TOF that suggests that the particle travels much faster than<br class="">speed-of-light (negative values in the histogram). If we do not consider<br class="">tachyons seriously, it means that the "TOF" value has some problems.<br class=""><br class="">I'll produce the "(TOF-L/(beta*C)) vs momentum" 2-dim plots you suggested,<br class="">but it will require a few hours on our computers; I hope that it will be<br class="">ready tomorrow. (I'm not quite sure why you want to see "momentum<br class="">dimension": most probably, it will be just horizontal bands. But OK, no<br class="">problem. Note that I can not just plot "TOF vs momentum" because different<br class="">pathLengths.)<br class=""><br class="">Thank you,<br class="">Andrei<br class=""><br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class=""><br class="">On Apr 25, 2016, at 8:26 PM, <a href="mailto:pmatt@jlab.org" class="">pmatt@jlab.org</a> wrote:<br class=""><br class="">You may know this, but for the record, when you call<br class="">DKinematicData::TOF(), it is subtracting t1 - t0. In the<br class="">DChargedTrackHypothesis factory, t0 is set to the chosen RF time,<br class="">propagated to the vertex-z of the track.<br class=""><br class="">Are you histogramming this for all PID hypotheses? Or are you always<br class="">picking the ones with the same PID? (e.g. proton) Remember, each<br class="">physical track has multiple hypotheses, for different PIDs. If you<br class="">chose<br class="">all hypotheses, then only one can be correct, and you will see funny<br class="">structures. Although yes, they would not give rise to the right-column<br class="">plots. However, the tracks certainly arent going at beta = 1, so the<br class="">right plots dont help much.<br class=""><br class="">You should have separate plots for each PID, and then you should make<br class="">this<br class="">a 2D plot vs. track momentum, and you will see a mass dependence that<br class="">will give rise to the structures. You should see distinct pion, proton,<br class="">etc. bands.<br class=""><br class="">- Paul<br class=""><br class="">************************************************************************<br class=""><br class="">We now have a new method of asking software questions, a google group:<br class=""><a href="mailto:gluex-software@googlegroups.com" class="">gluex-software@googlegroups.com</a><br class=""><br class="">I am about to forward this message to there, and then will try to answer<br class="">it there when I have time. If you are not part of the group yet, please<br class="">sign up:<br class=""><br class=""><a href="https://groups.google.com/forum/#!forum/gluex-software">https://groups.google.com/forum/#!forum/gluex-software</a><br class=""><br class=""> - Paul<br class=""><br class="">On Apr 25, 2016, at 6:46 PM, semenov@jlab.org wrote:<br class=""><br class=""><blockquote type="cite" class="">Paul, Mark and Simon:<br class=""><br class="">I'm trying to use the information from DChargedTrackHypothesis, and I<br class="">see<br class="">the things I do not understand. If I plot "TOF" (from the class) minus<br class="">the<br class="">time-of-flight "pathLength*sqrt(mass*mass+pmag*pmag)/pmag/c" (that I<br class="">calculated from the variables in the class) for the charged tracks that<br class="">are matched with the showers in BCAL, I see some interesting structure<br class="">(see the top-left panel in the attached file) instead of expected<br class="">centered-at-zero peak with the RMS of the order of the uncertainty on<br class="">TOF<br class="">(0.4-0.5ns). The bottom-left panel shows the same-variable histogram<br class="">with<br class="">the requirement to have 3 or more charged tracks in the event (to be<br class="">sure<br class="">that we have a good start time).<br class=""><br class="">For the "mass", I used the "PID" hypothesis in the class. To be sure<br class="">that<br class="">this structure is not affected much by PID hypothesis, I plotted also<br class="">the<br class="">histograms for "TOF-pathLength/c" (see the right column in the file);<br class="">everything that is visibly below zero are "tachyons" :) that means that<br class="">the problem is probably with the "TOF" variable which is the difference<br class="">between "t1" (stop time) and "t0" (start time) variables. "t0" is<br class="">pretty<br class="">close to the "vertex" time "T" from DVertex class.<br class=""><br class="">As you can see from the plot, the peaks in the structure are not<br class="">separated<br class="">with 4-ns intervals, so I would not blame "wrong-RF-bucket" reason.<br class=""><br class="">For this plot, I used run 3180, and my version of sim-recon is 1.10 .<br class=""><br class="">Most probably, I just using something incorrectly, and you already have<br class="">a<br class="">good explanation for the plots I see. Could you please help me?<br class=""><br class="">Thank you,<br class="">Andrei<tdiff-160423.pdf><br class=""></blockquote><br class=""><br class=""></blockquote>_______________________________________________<br class="">Halld-offline mailing list<br class=""><a href="mailto:Halld-offline@jlab.org" class="">Halld-offline@jlab.org</a><br class=""><a href="https://mailman.jlab.org/mailman/listinfo/halld-offline">https://mailman.jlab.org/mailman/listinfo/halld-offline</a><br class=""></blockquote><span id="cid:F91589E7-30B8-40B5-B51D-57BD94355E1B@phys.cmu.edu"><run3180-2d.pdf></span>_______________________________________________<br class="">Halld-offline mailing list<br class=""><a href="mailto:Halld-offline@jlab.org" class="">Halld-offline@jlab.org</a><br class=""><a href="https://mailman.jlab.org/mailman/listinfo/halld-offline">https://mailman.jlab.org/mailman/listinfo/halld-offline</a></div></div></blockquote></div><br class=""></div></div></blockquote></div><br></body></html>