Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initialize RecoX and RecoY to fix first node bug #205

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

jdkio
Copy link
Contributor

@jdkio jdkio commented Feb 7, 2025

There's a bug where the RecoX of the first node of the kalman track will be initialized to 18314 .

Reco_Tree->Scan("KalmanPos:TrackHitTruePos", "", "entryrange=100,110");
***********************************************
*        0 *        0 *           *           *
*        1 *        0 *     18314 * -1503.153 *
*        1 *        1 * 0.9841747 * -2416.708 *
*        1 *        2 *     18153 *     18153 *
*        1 *        3 * -1475.746 * -1484.912 *

That value corresponds to TMS_Const::TMS_Thick_End (a z value) so I thought it was being set to the wrong number at some point. But that was a dead end. Turns out all kalman node RecoX and RecoY values were uninitialized, and for some reason RecoX defaults to that value. But then Predict sets the value to a new one for all nodes except node 0 (the loop starts at node 1). This fixes it by initializing the RecoX to the same as x, and same with RecoY and y.

root [1] Reco_Tree->Scan("KalmanPos:TrackHitTruePos", "", "entryrange=100,110");
***********************************************
*    Row   * Instance * KalmanPos * TrackHitT *
***********************************************
*        0 *        0 *           *           *
*        1 *        0 * -1491.766 * -1503.153 *
*        1 *        1 * -2340.117 * -2416.708 *
*        1 *        2 *     18153 *     18153 *
*        1 *        3 * -1475.746 * -1484.912 *
*        1 *        4 * -2330.354 * -2399.559 *

@LiamOS, maybe you know if there's a better prediction than that? This seems slightly off since it's not taking into account the particle's trajectory, and only setting it to the hit x and y

@jdkio jdkio requested review from LiamOS and xiaoyan1997 February 7, 2025 19:44
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.

1 participant