 |
 |
Sorry… just checked again. It’s not bad in Y, but is pretty bad in X. > On Oct 21, 2015, at 8:57 PM, Sho Uemura <[log in to unmask]> wrote: > > If it is really not significantly worse than AtIP, then this does not explain what Holly is seeing. I thought AtLastHit was showing worse global residuals than AtIP at all layers, which means it's really bad and could be garbage at the ECal. > > On Thu, 22 Oct 2015, Nelson, Timothy Knight wrote: > >> The AtLast track state isn?t really that bad, it?s just that it *should* be a lot better than the AtIP state at the back of the tracker. I?m digging around in all this now, but I have to say finding the bug for that specific symptom is lower priority than figuring out how best to attack the mess, in general (which I should probably enter in JIRA soon). >> >>> On Oct 21, 2015, at 6:15 PM, Sho Uemura <[log in to unmask]> wrote: >>> >>> Looked in the code. The matcher does do the right thing (loops through the track states to find the AtCalorimeter state). The extrapolator was doing the right thing (loops through the track states) but it was using the AtLastHit state for GBL tracks. >>> >>> So I changed that. This should fix the problem you were seeing where the extrapolated position was way off; you'll still need to change your code to look at the correct track state. >>> >>> This should also improve track-cluster matching. I'm surprised that worked at all, but we really don't know what's wrong with the AtLastHit state, or how wrong it is - so maybe it's sometimes close enough to match. Maybe someone can look at how matching performs in pass3 vs. in a snapshot? >>> >>> On Wed, 21 Oct 2015, Sho Uemura wrote: >>> >>>> I (think) I caught and fixed that in the matcher code. But if the ECal track state is bad because the AtLastHit state was used to extrapolate, that also needs to be fixed, and then the recon does need to be rerun. >>>> >>>> On Wed, 21 Oct 2015, Omar Moreno wrote: >>>> >>>>> 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 >>>> >> >> >> ######################################################################## >> 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