Open AJPfleger opened 5 months ago
13:26:57 Gx2fFitter VERBOSE updated params:
loc0: -31.48 +- 1 1.000
loc1: 10.62 +- 1 0.000 1.000
phi: -2.856 +- 0.01745 0.000 0.000 1.000
theta: 0.1068 +- 0.01745 0.000 0.000 0.000 1.000
q/p: 0.1268 +- 0.1 0.000 0.000 0.000 0.000 1.000
time: -239.7 +- 299.8 0.000 0.000 0.000 0.000 0.000 1.000
This suggests that the fitter is unstable for certain inputs / scenarios. I would argue that the navigation is supposed to break in this scenario.
Note that eta for these parameters is almost 3 which is at the edge of what the ODD can handle usually.
I also quickly checked the input vectors and they are practically orthogonal in XY.
In [8]: p = np.array([-8.8604, 30.2046, 10.6162])
In [9]: p[:2] / np.linalg.norm(p[:2])
Out[9]: array([-0.2814848 , 0.95956569])
In [10]: d = np.array([-0.1023, -0.0300, 0.9943])
In [11]: d[:2] / np.linalg.norm(d[:2])
Out[11]: array([-0.95958925, -0.28140447])
All in all I would argue that this is not a bug of the navigation but a bug of the fitter as the start parameters for the propagation are unphysical for what it is trying to fit.
This issue/PR has been automatically marked as stale because it has not had recent activity. The stale label will be removed if any interaction occurs.
This issue/PR has been automatically marked as stale because it has not had recent activity. The stale label will be removed if any interaction occurs.
This issue/PR has been automatically marked as stale because it has not had recent activity. The stale label will be removed if any interaction occurs.
This issue/PR has been automatically marked as stale because it has not had recent activity. The stale label will be removed if any interaction occurs.
Issue
We might encounter a FPEDIV in the path correction of the cylinder surface. This could happen when we end up parallel to the cylinder.
https://github.com/acts-project/acts/blob/dc1a1d35f97d60d90a51ef3255501cf41b115bcd/Core/src/Surfaces/CylinderSurface.cpp#L164
Stacktrace
Reproduce
Running
truth_tracking_gx2f.py
with2.5 < |eta| < 3.0
can result in the above behaviour. When it happens, the gx2f pushed the updated parameters so far, that the first encountered surface isPixels::Barrel
instead ofBeamPipe::Barrel
:However, we can also find sometimes values, that are just close to zero:
Solution
There have been a few attempts to solve this issue:
In the end, we decided not to treat the symptoms, but rather find the underlying issue.
Since it only occurred for the GX2F, this issue might solve itself during further development. However, I don't see it as the GX2F's responsible to check if the navigation will work with newly suggested parameters.