We are not doing anything that contradicts the LCIO conventions. We happen
to have chosen a convenient reference point for these track states. You
can still write generic, portable code that uses the built-in methods to
find the track intersection with the ECal X-plane. But you don't have to.
I'm done arguing about this.
On Wed, 21 Oct 2015, Nelson, Timothy Knight wrote:
> Yes, I agree they should be accessed through getLocation. However, my point was that the indexes are defined like this in the LCIO interface and are therefore clear, documented in the code, and have always been like this. So at least their arrangement is fairly clear and reliable, unlike some internal decision we make about the definition of a reference point, which is the absolute *opposite* of clear, well-defined, documented in code, and immutable.
>
> Yes, it?s perfectly valid to ?decide? for our project what the reference point for each track state will be. However, that?s an internal convention and there is no mechanism for enforcing this convention in the code nor is it documented anywhere. Such things are inherently dangerous. Period.
>
> Tim
>
>> On Oct 21, 2015, at 9:47 AM, Sho Uemura <[log in to unmask]> wrote:
>>
>> To be extra clear,
>>
>> public interface TrackState
>> {
>> // TrackState location codes.
>> public final static int AtOther = 0; // Any location other than the ones defined below.
>> public final static int AtIP = 1;
>> public final static int AtFirstHit = 2;
>> public final static int AtLastHit = 3;
>> public final static int AtCalorimeter = 4;
>> public final static int AtVertex = 5;
>> public final static int LastLocation = AtVertex;
>>
>> /**
>> * The location of the track state.
>> * Location can be set to: AtIP, AtFirstHit, AtLastHit, AtCalorimeter, AtVertex, AtOther
>> */
>> public int getLocation();
>>
>> So the location codes are meant to go in the field accessd by getLocation() - says nothing about array indices (and it would be very weird if a track _had_ to have an AtOther track state before you could give it an AtIP track state).
>>
>> ----
>>
>> Because the reference point is arbitrary, there is no harm in setting it to a particular point of interest, and I think that if there is one specific point on the track that people are always going to care about, it can make sense to use that as the reference point.
>>
>> In other words you could set the ref to the origin and then users would have to find the intersection with the ECal every single time, or you can set the ref point to the intersection and then 99% of the time users can just look at the ref point; if you care about the direction at the ECal intersection, only then do you need to look at the track parameters.
>>
>> Maybe it's not conventional, but as long as the track parameters are defined correctly wrt the ref point, it's a perfectly valid definition of the track state, and I even think the built-in track utilities handle this correctly.
>>
>> On Wed, 21 Oct 2015, Nelson, Timothy Knight wrote:
>>
>>> To be clear, the array indexes are set in the interface along with the definitions of the ?locations", so they are one and the same and are fundamental to any implementation of TrackState that has ever existed in LCIO. So, IMO this is not the real problem here:
>>>
>>>> public interface TrackState
>>>> {
>>>> // TrackState location codes.
>>>> public final static int AtOther = 0; // Any location other than the ones defined below.
>>>> public final static int AtIP = 1;
>>>> public final static int AtFirstHit = 2;
>>>> public final static int AtLastHit = 3;
>>>> public final static int AtCalorimeter = 4;
>>>> public final static int AtVertex = 5;
>>>> public final static int LastLocation = AtVertex;
>>>>
>>>
>>> The problem is that, independent of how you are accessing the track state and whether you are accessing intended state, the reference point for a track is arbitrary and independent, regardless of the region of validity for the track state (the ?location?), and using the reference point to store the position of the track at some location is completely unconventional and therefore dangerous. Put simply, the reference point for a helix is simply the origin of the coordinate system for the track parameters. It makes no sense to guarantee anything regarding that location for any track state (otherwise, it would not be a variable!!)
>>>
>>> This is indeed one example (among many) of why the tracking infrastructure and reconstruction code needs a major overhaul.
>>>
>>> Tim
>>>
>>>> On Oct 21, 2015, at 8:47 AM, 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
