-
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: Use common direction transform Jacobian #2782
refactor: Use common direction transform Jacobian #2782
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #2782 +/- ##
==========================================
- Coverage 48.87% 48.83% -0.05%
==========================================
Files 485 486 +1
Lines 28205 28175 -30
Branches 13286 13285 -1
==========================================
- Hits 13786 13760 -26
+ Misses 4829 4820 -9
- Partials 9590 9595 +5 ☔ View full report in Codecov by Sentry. |
📊: Physics performance monitoring for ea6d780physmon summary
|
Co-authored-by: Alexander J. Pfleger <[email protected]>
Co-authored-by: Alexander J. Pfleger <[email protected]>
After having a closer look at the code it seems like the jacobians are duplicated in the |
(closed the wrong pr) |
This changes 1 vertex in the Athena run 3 workflow test. |
that is very unexpected. I will check the diff again. maybe I messed something up |
I'm ok to update references and merge this. Do you want to go ahead with this now or wait until January? |
would be great - I can update the hashes |
This causes lots of new navigation failures in the Athena workflows, which somehow we did not see in the previous Athena runs. |
This is not actually causing any issues. I tracked it down to a combination of #2712 and simultaneous changes on the Athena side. |
I found the same code in a few places and there seems to be a bit of simplification opportunity in the math
In acts-project#2780 I realized that we do not call any of the functions in `JacobianEngine` on the current main branch and most of them are duplicated in `CovarianceEngine`. Here I try to unify the duplicated code again blocked by - acts-project#2782 - acts-project#2781
I noticed that the concept of a curvilinear surface is a quite spread over the codebase and I wanted to improve this. Here I introduce a surface like class which does not actually inherit from `Acts::Surface` but shares some of the functionality. This way the jacobians are put in a single place and can be used from somewhere else in an expressive fashion. Afterwards it might make sense to let the `CurvilinearTrackParameters` depend on this special surface instead of a `PlaneSurface` or to merge them with `BoundTrackParameters` completely. related issues - #2812 blocked by - #2789 - #2782 - #2781 - #2811
I noticed that the concept of a curvilinear surface is a quite spread over the codebase and I wanted to improve this. Here I introduce a surface like class which does not actually inherit from `Acts::Surface` but shares some of the functionality. This way the jacobians are put in a single place and can be used from somewhere else in an expressive fashion. Afterwards it might make sense to let the `CurvilinearTrackParameters` depend on this special surface instead of a `PlaneSurface` or to merge them with `BoundTrackParameters` completely. related issues - acts-project#2812 blocked by - acts-project#2789 - acts-project#2782 - acts-project#2781 - acts-project#2811
…d of bound vector (acts-project#2811) This avoid free->bound->free roundtrips and aligns the interface with `freeToBoundJacobian` related issues - acts-project#2810 blocked by - acts-project#2789 - acts-project#2782 - acts-project#2781
I noticed that the concept of a curvilinear surface is a quite spread over the codebase and I wanted to improve this. Here I introduce a surface like class which does not actually inherit from `Acts::Surface` but shares some of the functionality. This way the jacobians are put in a single place and can be used from somewhere else in an expressive fashion. Afterwards it might make sense to let the `CurvilinearTrackParameters` depend on this special surface instead of a `PlaneSurface` or to merge them with `BoundTrackParameters` completely. related issues - acts-project#2812 blocked by - acts-project#2789 - acts-project#2782 - acts-project#2781 - acts-project#2811
…d of bound vector (acts-project#2811) This avoid free->bound->free roundtrips and aligns the interface with `freeToBoundJacobian` related issues - acts-project#2810 blocked by - acts-project#2789 - acts-project#2782 - acts-project#2781
I noticed that the concept of a curvilinear surface is a quite spread over the codebase and I wanted to improve this. Here I introduce a surface like class which does not actually inherit from `Acts::Surface` but shares some of the functionality. This way the jacobians are put in a single place and can be used from somewhere else in an expressive fashion. Afterwards it might make sense to let the `CurvilinearTrackParameters` depend on this special surface instead of a `PlaneSurface` or to merge them with `BoundTrackParameters` completely. related issues - acts-project#2812 blocked by - acts-project#2789 - acts-project#2782 - acts-project#2781 - acts-project#2811
I found the same code in a few places and there seems to be a bit of simplification opportunity in the math