-
Notifications
You must be signed in to change notification settings - Fork 4
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
Update track fit EDM #58
Conversation
|
That makes sense.
This is not a vertex position, this is the track position of closest approach to the vertex (or some, in the case of Acts,
It is calculable via jacobians that relate the two bases, there are transforms that do this that you can basically copy from the |
Sounds good to me. Up to @sly2j to click the merge button. |
So for my own understanding - this gets merged first and then we make the corresponding changes to EICrecon that will reflect these changes? I'm pretty sure merging this will break the nightly build |
The nightly build in eic-shell doesn't pull in the main branch of just anything, only epic and eicrecon. So merging this doesn't mean it gets into eic-shell. We first need to cut a release here and put it explicitly in eic-shell. |
Thanks for the clarification, I naively assumed all the repos got built together rather than some being only released on versions and some not. That makes sense for repos that don't change as frequently as others |
There's the eternal tension between only putting releases into the environments rolled out to users by default, and putting only rolling main versions into the nightly. I wish we could have a nightly that's just main only but it's not workable and leads to too much breakage. So we've settled on epic and eicrecon main only... And there's pressure even here, in particular when changing acts versions in non-compatible ways wrt eicrecon. |
After eic/EDM4eic#58, there is no more `charge` field in edm4eic::TrackParameters, so we have to get this from `qOverP`, but this is backwards compatible.
After eic/EDM4eic#58, there is no more `charge` field in edm4eic::TrackParameters, so we have to get this from `qOverP`, but this is backwards compatible.
### Briefly, what does this PR introduce? Due to incompatible changes in #58 the next version will be 5.0.0.
### Briefly, what does this PR introduce? This adds forward support for edm4eic version 5, which includes the changes in eic/EDM4eic#58. ### What kind of change does this PR introduce? - [ ] Bug fix (issue #__) - [x] New feature (issue, follow-up on eic/EDM4eic#58) - [ ] Documentation update - [ ] Other: __ ### Please check if this PR fulfills the following: - [ ] Tests for the changes have been added - [ ] Documentation has been added / updated - [ ] Changes have been communicated to collaborators ### Does this PR introduce breaking changes? What changes might users need to make to their code? No. ### Does this PR change default behavior? Yes, some fields not written as before since CKFTracking does not yet write edm4eic::Track collection.
### Briefly, what does this PR introduce? Move measurements from Track (which is introduced in #58) back to Trajectory, and add back outliers. ### What kind of change does this PR introduce? - [ ] Bug fix (issue #__) - [ ] New feature (issue #__) - [ ] Documentation update - [x ] Other: partially revert a change ### Please check if this PR fulfills the following: - [ ] Tests for the changes have been added - [ ] Documentation has been added / updated - [x ] Changes have been communicated to collaborators. -- This change is communicated to Joe Osborn. ### Does this PR introduce breaking changes? What changes might users need to make to their code? CKFtracking.cc needs to be updated to take the new data structure. ### Does this PR change default behavior? --------- Co-authored-by: Wouter Deconinck <wdconinc@gmail.com>
Briefly, what does this PR introduce?
This introduces changes to the track fit and track state EDM objects to better conform to a single container that can deliver all of the needs of downstream reconstruction algorithms and (ultimately) physics analysis.
edm4eic::Trajectory
and intoedm4eic::Track
edm4eic::TrackParameters
object, which will need to contain the complete covariance to swap between edm4eic and Acts::EDM. Also adds a surface type as bound track parameters make no sense without an associated surface.edm4eic::Track
The resulting track object contains the set of track parameters at the vertex, some criteria to evaluate the track fit (e.g. those contained in the one to one relation to
edm4eic::Trajectory
), and all track states associated to the fit (also still inedm4eic::Trajectory
).The track parameters at the vertex do need to be stored separately (e.g. not as another uniquely defined track state), for a technical reason. They are going to (1) be most frequently used in global coordinates, which the track parameters are not in and (2) are associated to a
PerigeeSurface
, which is transient unlike the surfaces associated with the actual geometry. Without knowledge of the surface, a set of BoundTrackParameters do not have a well defined global definition.Opening this PR now as it will likely have nontrivial downstream consequences, so comments welcome.
What kind of change does this PR introduce?
Please check if this PR fulfills the following:
Does this PR introduce breaking changes? What changes might users need to make to their code?
It introduces breaking changes to EICrecon. Currently there are 3 containers produced by the CKF in EICrecon - the aim of this PR is to reduce this to a single container. This will in turn change other downstream reconstruction algorithms that rely on the CKF output as they will have to access this changed structure.
Does this PR change default behavior?
No