-
Notifications
You must be signed in to change notification settings - Fork 168
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor!: Particle hypothesis for track parameters #2181
refactor!: Particle hypothesis for track parameters #2181
Conversation
|
Codecov Report
@@ Coverage Diff @@
## main #2181 +/- ##
==========================================
+ Coverage 49.26% 49.52% +0.25%
==========================================
Files 449 447 -2
Lines 25403 25293 -110
Branches 11723 11620 -103
==========================================
+ Hits 12516 12527 +11
+ Misses 4554 4513 -41
+ Partials 8333 8253 -80
... and 11 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
📊 Physics performance monitoring for e7a7c2eSummary VertexingSeedingCKFAmbiguity resolutionTruth tracking (Kalman Filter)Truth tracking (GSF) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I took a first round, didn't found anything critical, just a few comments! Great work!
I think I'll do a second round once the CI is green
Core/include/Acts/EventData/detail/CurvilinearTrackParameters.hpp
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I looked through this until the point where GitHub stops auto-showing the diff anymore because too many files are touched.
I think in the future, it would be nice to separate the actual changes from the extra ones, so the PR stays reviewable.
return ParticleHypothesis<ChargeType>(pion().absPdg(), pion().mass(), absQ); | ||
} | ||
|
||
constexpr ParticleHypothesis(PdgParticle absPdg, float mass, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we make this private?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure - I feel like a user might want to add a particle we do not provide without writing their own particle hypothesis class and modified track parameters
/// Momentum accessor | ||
/// | ||
/// @param state [in] The stepping state (thread-local cache) | ||
Vector3 momentum(const State& state) const { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So momentum becomes absolute momentum and momentum is now the absolute momentum vector?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes I tried to align this with the methods we have in the track parameters
Examples/Algorithms/Propagation/include/ActsExamples/Propagation/PropagatorInterface.hpp
Outdated
Show resolved
Hide resolved
Examples/Algorithms/TruthTracking/ActsExamples/TruthTracking/TrackParameterSelector.cpp
Outdated
Show resolved
Hide resolved
I think before we can consider merging, we should discuss it in the meeting. Also, I've been thinking about the downstream implications and support. Could we actually separate just the hypothesis changes from everything else? I'm thinking that a lot of users will have a hard time adjusting to the particle hypothesis change, so if we cut a release right before merging we'd be able to backport changes for a while. |
I would like to move `ParticleData` to `Core` so we have one central spot to get mass and charge for a PDG particle identifier. This can the be utilized in #2181
abd20dd
to
e7a7c2e
Compare
With this PR I try to align the naming in the Stepper interface to `qOverP` and `absoluteMomentum` which is also my goal for the track parameters. I pulled these changes out of #2181.
I would like to move `ParticleData` to `Core` so we have one central spot to get mass and charge for a PDG particle identifier. This can the be utilized in acts-project#2181
I noticed that we are quite inconsistent with the use of `direction` and `unitDirection`. Personally I would opt for `direction` and have it as a unit vector implicitly. Also, I changed `qop` to `qOverP` which I will also align for the Stepper and TrackParameter interfaces in follow-up PRs I pulled these changes out of #2181.
We're ready to go for |
I think this one is ready to be closed. I split it off into multiple PRs the ones we can merge next are |
…s-project#2251) I noticed that we are quite inconsistent with the use of `direction` and `unitDirection`. Personally I would opt for `direction` and have it as a unit vector implicitly. Also, I changed `qop` to `qOverP` which I will also align for the Stepper and TrackParameter interfaces in follow-up PRs I pulled these changes out of acts-project#2181.
…s` (#2269) I am unhappy with the name `Single*TrackParameters` as it could refer to singly charged or single track. The track actually supports different kinds of charge hypothesis so I thought `Generic*TrackParameter` might fit better. I also merged `NeutralTrackParameters` into `TrackParameters` and removed the external template instantiation as it could be a performance hit because it disables inlining. Pulled these changes out of #2181
In this PR I introduce the concept of a particle hypothesis which will later be used by the track parameters. I also refactored the Charge interface a bit. This is the foundation for upcoming refactor PRs for the particle hypothesis. Pulled out from #2181. Co-authored-by: Paul Gessinger <[email protected]>
In this PR I make the particle hypothesis part of the track parameters. This allows us to consistently use the same hypothesis across various parts of our code. Before that the particle hypothesis was a bit scattered in the propagator and stepper. replaces #2181 after splitting it up blocked by - #2366 - #2396 - #2398 - #2397
In this PR I make the particle hypothesis part of the track parameters. This allows us to consistently use the same hypothesis across various parts of our code. Before that the particle hypothesis was a bit scattered in the propagator and stepper. replaces acts-project#2181 after splitting it up blocked by - acts-project#2366 - acts-project#2396 - acts-project#2398 - acts-project#2397
In this PR I make the particle hypothesis part of the track parameters. This allows us to consistently use the same hypothesis across various parts of our code. Before that the particle hypothesis was a bit scattered in the propagator and stepper.
TrackParameters
gainParticleHypothesis
ParticleHypothesis
is a new class which holds a charge type, the mass and the absolute PDG valueqOverP
or vice versaSingle*TrackParameters
are renamed and typedefed inTrackParameters.hpp
TrackParameters
implementations are now calledGeneric*TrackParameters
absoluteMomentum
,direction
,momentum
in the steppers, truth particles and track parametersalternative to #2178