Skip to content

Conversation

@QWeyrich
Copy link

This adds a more sophisticated track matching algorithm to ND CAFMaker, which matches tracks between LAr (Pandora or SPINE tracks) and TMS and then creates joint tracks out of the successful matches. Track matching is unique (will never match one track in one detector to multiple tracks in the other detector), has a customizable cutoff (fCut) in Params.h that prevents overmatching, and takes into consideration the projected x and y differences between tracks, angles between tracks, and, optionally, the time difference between when the tracks are created. NOTE: while track matching ought to perform much better when time is included, it is not currently functional. You should run the track matcher in its default configuration, with the useTime parameter set to false, until time-based matching is patched.

@noeroy noeroy requested review from LiamOS and noeroy August 22, 2025 13:02
@brucehoward-physics
Copy link
Member

Note that this depends on DUNE/duneanaobj#57

@noeroy noeroy requested a review from chenel August 22, 2025 15:06
Copy link
Contributor

@noeroy noeroy left a comment

Choose a reason for hiding this comment

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

Looks good to me, with the couple of things i've noted.
I'm just not sure why are we defining two matching functions for ndlar and TMS instead of adding all of that work to the existing framework.

Another thing to add will be the proper setup when duneanaobj will be updated and published.

Copy link
Collaborator

@chenel chenel left a comment

Choose a reason for hiding this comment

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

I have an overall question/concern here. It looks like this method is directly pulling objects out of the TMS reco file. I think this is likely going to duplicate effort, since the TMSRecoBranchFiller will be doing the same thing. Is there a reason you decided to implement it this way, rather than using the TMS tracks pulled out by the TMSRecoBranchFiller and already put into the StandardRecord? If there isn't a good reason I would heavily prefer using the StandardRecord variants, because otherwise we will have to maintain the TMS interface in two places.

@QWeyrich QWeyrich closed this Sep 23, 2025
@QWeyrich QWeyrich reopened this Sep 23, 2025
@LiamOS
Copy link
Member

LiamOS commented Oct 9, 2025

While this PR seems generally good and sane (some TMS-side stuff notwithstanding), I think the ndcaf_setup.sh will require some editing for this to work for users, at least changing the duneanaobj version. (v03_11_00 available on UPS).

I do want to make sure this builds and runs before approving.

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.

5 participants