Add track structs
Added track structs for Kalman Filter input and moved reused track structs (e.g. track states) to cuda/tracks. This time with merge conflicts fixed.
Merge request reports
Activity
- Resolved by Thomas Boettcher
- cuda/tracks/include/TrackTypes.cuh 0 → 100644
78 // Hypothetical SciFi segment. 79 struct SFSegment { 80 unsigned short nHits; 81 // TB: forward tracking doesn't exist yet, so this number of 82 // hits is a placeholder. 83 unsigned short hits[100]; 84 unsigned short utTrackIndex; 85 FullState state; 86 }; 87 88 //---------------------------------------------------------------------- 89 // Segment combinations. 90 //---------------------------------------------------------------------- 91 92 // VeloUT combination. 93 struct VeloUTTrack { For my understanding: Did you design the track in this way, so that one has the flexibility of creating tracks not crossing all detectors? That is why we need the extra definition of VeloUTTrack and LongTrack?
If I understand correctly, if a SFSegment is always created from a VeloUT track, it should be enough to go from the SFSegment to the UTSegment using the utTrackIndex, and from there to the VeloSegment using the veloTrackIndex,no?
Actually, our algorithms are designed in such a way that long every track used for a decision in the end contains a Velo, a UT and a SciFi segment. UT segments need a Velo segment as input for the extrapolation. SciFi segments need the Velo segment to extrapolate from and the UT segment for the momentum and charge estimate. So I think we can design the track object such that it always includes all three track segments.
Only if we add other algorithms to find downstream tracks or require decisions based on Velo only or veloUT tracks would we need the other track objects.
@gligorov @raaij Do you think we should keep the possibility to have downstream / veloUT tracks as input for the Kalman / a final decision?
@dovombru The VeloUTTrack is just meant for testing the kalman filter if forward tracking isn't ready yet.
I combined the velo, UT, and SciFi segments because we can then throw out the velo and UT segments that aren't used in long tracks. I'm not sure how helpful/necessary this actually is though.
- Resolved by Thomas Boettcher
I think before merging this branch, we should finish the discussion on whether we are all happy with this track object (@dcampora @plfernan @raaij @gligorov ) and then go ahead and adapt the algorithms to use it. Right now, I see you have kept the old containers and added the new ones. The merge should be cleaned up to only use one type of track object.
- cuda/kalman/PrepareInput/src/PrepareInput.cu 0 → 100644
1 #include "PrepareInput.cuh" 2 3 __global__ void prepareKalmanInput( added 9 commits
-
62cac3e5...19d44180 - 7 commits from branch
master
- d9b38d54 - Cleaned up comments and extra files.
- 65082973 - Fixed merge conflicts with master.
-
62cac3e5...19d44180 - 7 commits from branch