Skip to content

Conversation

@bloodyyugo
Copy link
Contributor

Isolations were never calculated/added to the TrackData for Kalman tracking. This PR does that.

-- For each layer, find the closest Si cluster, in the direction away from the beam, to the cluster-on-track and calculate the distance between the two.
-- if there is no cluster found or no hit-on-track for that layer, returns -999.
-- include this list of layer-isolations in the TrackData (which is a GenericObject) as the double array (which is it's intended purpose already).

The hpstr code already uses this array, in utils::buildTrack, to store the isolations in the Track object so no need to modify that code.

Closes #1158

@bloodyyugo bloodyyugo self-assigned this Dec 4, 2025
@bloodyyugo bloodyyugo linked an issue Dec 4, 2025 that may be closed by this pull request
Copy link
Collaborator

@mgignac mgignac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @bloodyyugo !

Looks good to me. In the hpstr level code, there is a timing cut to ensure the close by hit is in time (<30ns). Do we want to introduce a similar cut? You retrieve the time of the closest hit, but as far as I understand this information get dropped when written to the TrackData? There is also the possibility that there are >1 hits with slightly more spatial separation but closer in time, I suppose. It's probably a small effect. Perhaps a close approximation would be to write isot0 hit times as well?

List<Integer> layers = new ArrayList<Integer>();
List<Double> residuals = new ArrayList<Double>();
List<Float> sigmas = new ArrayList<Float>();
List<Integer> layersInt = new ArrayList<Integer>();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason why this chunk of code is moved down a few lines? It is hard to parse what is going on with the different loops and if statements.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first loop is of hits on track (so, only layers with a HOT are included) and the second one is over all layers. I separated the intersections list instantiations down to just before the loop over all layers because that's where it's filled.

// use the sign of the global plane position (vertical = z)
// times the local-->global v-->z element
// to determine if sensor is aligned (+ive v --> away from beam)
// or anti-aligned (+ive v is towards beam)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't fully understand this comment. What do you mean by local-->global v-->z element and what is +ive v

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The local-->global refers to the rotation matrix R (local i.e. sensor frame to the "global" frame for kalman tracking) and v-->z element is the element in that matrix (the z component of the v direction). +ive == positive.

@mgignac mgignac self-requested a review December 7, 2025 23:25
@sarahgaiser
Copy link
Collaborator

I think this looks good now. @bloodyyugo could you address my two questions above? happy to approve the PR after you have answered them!

@mgignac mgignac merged commit ee6e1aa into master Dec 8, 2025
1 of 2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Calculate and include hit-on-track isolations for KF tracks

4 participants