 |
 |
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