KinKal truth-seeded track extrapolation#1869
Conversation
…n bias/uncertainty.
|
Hi @RobMina,
which require these tests: build. @Mu2e/fnalbuild-users, @Mu2e/write have access to CI actions on main. 📝 The author of this pull request is not a member of the Mu2e github organisation. |
brownd1978
left a comment
There was a problem hiding this comment.
Hi Rob, this is a nice addition to our functionality.
I'm uncomfortable adding MC-specific code to reconstruction modules intended nominally to run on real data, as that adds an otherwise unnecessary dependency. Eventually we will need to split MC-specific codes out of Offline, and this coupling will make that harder.
An alternative is to write a dedicated module that produces a KKTrack based purely on MC information. If you need to associate that with the reco KKTrack you could do that via the KalSeedMC. What do you think?
|
Thanks Dave! I've implemented the new modules as you suggested, splitting the MC-specific code out of the two reco fit modules. |
brownd1978
left a comment
There was a problem hiding this comment.
Hi Rob, thanks for splitting out the truth track, it's much cleaner this way. I hope it wasn't hard to change your analysis to work through the assns.
I see very little (any?) explicit dependence on trajectory type in this code, which begs the question whether you could unify these modules under a templated base class. That would also extend to the implementation to LoopHelix. You would need a runtime check to make sure the KalSeeds were of the expected type, and a switch to turn off domains, but otherwise it looks like the implementation is common. What do you think?
|
Hi Dave, that's a great idea! Re-implemented using a single module with templated base class, and validated for both CentralHelix and KinematicLine. |
|
@FNALbuild run build test |
|
⌛ The following tests have been triggered for 5d907f4: build (Build queue - API unavailable) |
|
☔ The build tests failed for 5d907f4.
N.B. These results were obtained from a build of this Pull Request at 5d907f4 after being merged into the base branch at 3d84f93. For more information, please check the job page here. |
brownd1978
left a comment
There was a problem hiding this comment.
Thanks Rob, this looks great! I still have a few minor quibbles, nothing that would block approval.
|
I have an immediate use case for truth extrapolation of LoopHelix (testing accuracy of reflection extrapolation). If you'd prefer not to add that I can easily make a follow-on PR, but since you did all the work you could also just add it. I understand that you might not be able to test it beyond compilation, that's fine. |
|
📝 The HEAD of |
…ocumenting rare degenerate case of one track piece, add LoopHelix support, rename to createTruthSeed.
|
Hi Dave, I added the LoopHelix and verified that it builds correctly. Also, I addressed the other earlier comments. |
|
@FNALbuild run build test |
|
⌛ The following tests have been triggered for 38068b4: build (Build queue - API unavailable) |
|
☀️ The build tests passed at 38068b4.
N.B. These results were obtained from a build of this Pull Request at 38068b4 after being merged into the base branch at 704459c. For more information, please check the job page here. |
... for MC. Helps to disentangle fit uncertainty from extrapolation bias/resolution. Turned off by default, comments in prolog.fcl show how to enable it.
This is independent of the material definition PR.