 |
 |
I need to check, but we may need to rerun the recon because the wrong track state might have been used in the track-cluster matching. On Oct 21, 2015 09:48, "Omar Moreno" <[log in to unmask]> wrote: > Like I was saying ... This likely means that the position of the track at > the ECal in the DST is also wrong. We are going to need to rerun the > DST's. > On Oct 21, 2015 09:46, "Omar Moreno" <[log in to unmask]> wrote: > >> I didn't realize that an additional track state was added to a track. >> This likely means that the position >> >> On Oct 21, 2015 08:48, "Sho Uemura" <[log in to unmask]> wrote: >> > >> > Also, I meant to say this: >> > >> > Since the TrackState array index is pretty arbitrary, but each >> TrackState has a location ID, people should not be hard-coding the array >> index in their code, and should use the location ID instead (loop over all >> track states, and pick the one with the correct location). It's less >> convenient but safer. >> > >> > And I'm not picking on Holly's code here - this is something that a lot >> of recon code does. This is our fault. >> > >> > If it helps, there is a utility method that does this for you: >> TrackUtils.getTrackStateAtECal(track). >> > >> > >> > On Wed, 21 Oct 2015, Sho Uemura wrote: >> > >> >> Tim is talking about the track state location ID >> (state.getLocation()). Holly is using the track state array index. >> >> >> >> What happened was that Pelle added an additional track state for GBL >> tracks, which represents the track parameters at the last layer of the SVT >> (this doesn't seem to be working quite right, which is an outstanding bug). >> This shows up at index 1, which used to be where the ECal extrapolation >> went. >> >> >> >> For seed tracks: >> >> getTrackStates(0) = at IP (TrackState.AtIP), ref to origin >> >> getTrackStates(1) = at ECal (TrackState.AtCalorimeter), ref to ECal >> intersection >> >> >> >> For GBL tracks: >> >> getTrackStates(0) = at IP (TrackState.AtIP), ref to origin >> >> getTrackStates(1) = at last layer (TrackState.AtLastHit), ref to origin >> >> getTrackStates(2) = at ECal (TrackState.AtCalorimeter), ref to ECal >> intersection >> >> >> >> I don't know why Holly is seeing a nonzero ref point that's >> centimeters off from the cluster position. Maybe we screwed that up, or >> maybe for GBL tracks the ECal extrapolation is being done from the >> AtLastHit track state (which is bogus), which should not have been turned >> on until it had been checked. I can check if that's what's going on. >> >> >> >> Hope this clears things up. And hopefully I'm not adding any >> misinformation to the mix here, there's enough of it going around. >> >> >> >> On Wed, 21 Oct 2015, Holly Vance wrote: >> >> >> >>> Just in case this was missed- >> >>> >> >>> Ok-after checking this in the DST and when using the FSParticle >> collection, >> >>> the track position at the Ecal is still obtained as it was before and >> >>> works. If I directly iterate over the UnconstrainedMollerCandidate >> >>> collection, and get the tracks associated with a vertex, the track >> >>> positions at the ecal don't really make a lot of sense (as mentioned >> in my >> >>> previous e-mail). I'm not sure why this doesn't work in Pass3, but it >> did >> >>> work in Pass 2. >> >>> >> >>> The getReferencePoint method is working, but I am having different >> results >> >>> in the UnconstrainedMollerCandidateCollection than I did with Pass2. >> >>> Additionally, this method still works for FSParticle collection. >> >>> >> >>> On Wed, Oct 21, 2015 at 10:56 AM, Nelson, Timothy Knight < >> >>> [log in to unmask]> wrote: >> >>> >> >>>> Hi Matt, >> >>>> >> >>>> In LCIO, TrackState 1 is ?at IP?, so this definitely doesn?t seem >> like a >> >>>> good convention. Track state 4 is ?at calorimeter? but, in any case, >> the >> >>>> reference point is meant to be independent of the trajectory itself, >> and I >> >>>> think using to store a track position (simply by our own convention) >> is not >> >>>> a good idea, since there is no way to guarantee this behavior (as is >> now >> >>>> found.) >> >>>> >> >>>> Tim >> >>>> >> >>>>> On Oct 21, 2015, at 7:36 AM, Graham, Mathew Thomas < >> >>>> >> >>>> [log in to unmask]> wrote: >> >>>>> >> >>>>> >> >>>>> >> >>>>> I had put the track position at the ECal as the reference point for >> >>>> >> >>>> track state 1 (and adjusted the track parameters accordingly >> IIRC)?this may >> >>>> have changed though, but not by me. >> >>>>> >> >>>>> >> >>>>>> Hi Holly, >> >>>>>> >> >>>>>> I?m not an expert on finding position at the ECal, but the >> reference >> >>>> >> >>>> point for the track doesn?t have anything to do with the position of >> the >> >>>> track at any position along it?s path (it could be kilometers away >> from the >> >>>> track, in principle), and was probably never really the right way >> even if >> >>>> it did seem to give sensible results. The reference point is simply >> the >> >>>> zero of the coordinate system for the track parameters. This is >> usually >> >>>> the origin of our global coordinates. >> >>>>>> >> >>>>>> >> >>>>>> Can someone else chime in and provide the ?right? answer here? >> >>>>>> >> >>>>>> Tim >> >>>>>> >> >>>>>>> On Oct 21, 2015, at 6:20 AM, Holly Vance <[log in to unmask]> >> wrote: >> >>>>>>> >> >>>>>>> Hello, >> >>>>>>> >> >>>>>>> Can anyone confirm that this is still the correct method to get >> the >> >>>> >> >>>> track position at the Ecal from Pass 3? >> >>>>>>> >> >>>>>>> track->getTrackStates()[1]->getReferencePoint() >> >>>>>>> >> >>>>>>> This same code worked for Pass 2, but now I mostly get 0 for all >> >>>> >> >>>> values. Has anyone else confirmed this works? The few times I get >> something >> >>>> other than 0, the distribution sits 6-10cm away from the matched >> cluster >> >>>> x-y positions. Z position still looks fine. >> >>>>>>> >> >>>>>>> >> >>>>>>> -Holly >> >>>>>>> >> >>>>>>> >> >>>>>>> Use REPLY-ALL to reply to list >> >>>>>>> >> >>>>>>> To unsubscribe from the HPS-SOFTWARE list, click the following >> link: >> >>>>>>> >> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1 >> >>>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> ######################################################################## >> >>>>>> Use REPLY-ALL to reply to list >> >>>>>> >> >>>>>> To unsubscribe from the HPS-SOFTWARE list, click the following >> link: >> >>>>>> >> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1 >> >>>>> >> >>>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> BEGIN-ANTISPAM-VOTING-LINKS >> >>>> ------------------------------------------------------ >> >>>> >> >>>> NOTE: This message was trained as non-spam. If this is wrong, >> >>>> please correct the training as soon as possible. >> >>>> >> >>>> Teach CanIt if this mail (ID 01PvOV0rk) is spam: >> >>>> Spam: >> >>>> >> https://www.spamtrap.odu.edu/canit/b.php?i=01PvOV0rk&m=13ee7639fef7&t=20151021&c=s >> >>>> Not spam: >> >>>> >> https://www.spamtrap.odu.edu/canit/b.php?i=01PvOV0rk&m=13ee7639fef7&t=20151021&c=n >> >>>> Forget vote: >> >>>> >> https://www.spamtrap.odu.edu/canit/b.php?i=01PvOV0rk&m=13ee7639fef7&t=20151021&c=f >> >>>> ------------------------------------------------------ >> >>>> END-ANTISPAM-VOTING-LINKS >> >>>> >> >>>> >> >>> >> >>> >> ######################################################################## >> >>> Use REPLY-ALL to reply to list >> >>> >> >>> To unsubscribe from the HPS-SOFTWARE list, click the following link: >> >>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1 >> >>> >> >> >> >> >> ######################################################################## >> >> Use REPLY-ALL to reply to list >> >> >> >> To unsubscribe from the HPS-SOFTWARE list, click the following link: >> >> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1 >> >> >> > >> > ######################################################################## >> > Use REPLY-ALL to reply to list >> > >> > To unsubscribe from the HPS-SOFTWARE list, click the following link: >> > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1 >> > ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the HPS-SOFTWARE list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1