Start and End Direction Not Filled When Kalman Filter is Turned Off

[jdkio]

This is Reco_Tree->Show(1) from /exp/dune/data/users/kleykamp/dune-tms/2024-09-30_MicroProdN1p2_dune-tms0.3.0_no_kalman.tmsreco.root, which is v0.3.0 with kalman filter turned off in the config:

 nHits           = 48
 TrackHitPos     = -465.994, 
                  -337.609, 11368, -465.994, -337.609, 11423, 
                  -395.251, -337.609, 11478, -395.251, -337.609, 
                  11533, -342.194, -675.072, 11588, -342.194, 
                  -675.072, 11643, -324.508, -337.609
 nKalmanNodes    = 0
 TrackHitPos     = 0, 
                  0, 0, 0, 0, 0, 
                  0, 0, 0, 0, 0, 
                  0, 0, 0, 0, 0, 
                  0, 0, 0, 0
 TrackHitTruePos = 0, 
                  0, 0, 0, 0, 0, 
                  0, 0, 0, 0, 0, 
                  0, 0, 0, 0, 0, 
                  0, 0, 0, 0
 StartDirection  = 0, 
                  0, 0
 EndDirection    = 0, 
                  0, 0

I also noticed that KalmanPos uses the name TrackHitPos:

  Reco_Tree->Branch("KalmanPos",      RecoTrackKalmanPos,       "TrackHitPos[nTracks][200][3]/F");
  Reco_Tree->Branch("KalmanTruePos",  RecoTrackKalmanTruePos,   "TrackHitTruePos[nTracks][200][3]/F");

https://github.com/DUNE/dune-tms/blob/main/src/TMS_TreeWriter.cpp#L234-L235

I think the purpose of the Reco_Tree was to provide the final "best" track information for the cafs. So we probably don't want a separate kalman track branch. Instead, it should replace the information from the 3d track. And then in the Line_Candidates ttree, we should save each separately for debugging and validation

So start and end direction should use the kalman filter track info if available and otherwise use the 3d reco track

[jdkio]

In the same vein, the reco track should include info on which plane and bar the last hit is on. This has a number of uses, include the ND physics sample cut as well as bar-by-bar calibration. I'd add it but I don't want to add it twice

[LiamOS]

Part of the logic to having them separate was that one Kalman node does not necessarily correspond one-to-one to hits, so multiple hits in a single layer are considered together.

My feeling would also be that we should only have one variable for this, but the two we have differ subtley. Any feelings on this?

[AsaNehm]

The TrackMatching calculates a Direction for the start of the track. That is saved into TMS_Track and could be written onto the output Reco_Tree and overwritten by the Kalman result if there is one.
The EndDirection would need to be added as this doesn't exist in the TrackMatching yet

[AsaNehm]

I just checked and the problem with it not being filled is coming from the fact that the direction calculation is first of all commented out on main in TrackMatching3D and second that it still sets the Direction variable instead of the StartDirection variable. The former does not exist anymore... Need to fix that for sure

[jdkio]

@LiamOS, I think Kalman is dissimilar enough to keep them separate for now. It is a bit strange because we use the 3d track to recover the primary true particle. It's possible, though unlikely, that the kalman fit could remove enough energy that the primary true particle changes