HPS-SOFTWARE Archives

Software for the Heavy Photon Search Experiment

HPS-SOFTWARE@LISTSERV.SLAC.STANFORD.EDU

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Sho Uemura <[log in to unmask]>
Reply To:
Software for the Heavy Photon Search Experiment <[log in to unmask]>
Date:
Wed, 21 Oct 2015 08:40:34 -0700
Content-Type:
TEXT/PLAIN
Parts/Attachments:
TEXT/PLAIN (145 lines)
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

ATOM RSS1 RSS2