Skip to content
Snippets Groups Projects

Add track structs

Closed Thomas Boettcher requested to merge thboettc_merge_track_object into master
2 unresolved threads

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

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • 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.

    • @thboettc thank for the clarification, I see your point now. Let's discuss it further on Tuesday.

    • Please register or sign in to reply
  • 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.

  • Please remove the files test.txt and StreamSequence.cu.swp.

  • After the last MR, there are some conflicts. Please fix them.

  • 1 #include "PrepareInput.cuh"
    2
    3 __global__ void prepareKalmanInput(
    • Why is the conversion to VeloUT tracks neded at this stage? The UTSegments should contain all the necessary information, as one can trace back to the VeloSegment from there.

    • The idea was to check the kalman filter on VeloUT tracks before forward tracking was done. So once forward tracking is ready this step will make LongTracks.

    • Please register or sign in to reply
  • Thomas Boettcher added 9 commits

    added 9 commits

    Compare with previous version

  • @thboettc do you want to keep this merge request open? It is probably not needed anymore when the event model that is implemented for the Velo in the master branch has been propagated to the UT and SciFi. Is there any functionality in this MR that you need for the Kalman?

  • @dovombru No, there's nothing we need here. I'll go ahead an close it.

  • Please register or sign in to reply
    Loading