bug: navigation suggests pathCorrection=inf on cylinderSurface
#3267
Comments
AJPfleger
added
Bug
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. 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. |
Have *almost* same settings for GX2F and KF makes it easier to understand in the physmon output and check if our results are good. ## Why *almost*? Had also 3 FPEs which fixed here, but did not choose this approach: - #3254 This issue only occurred for `2.5 < |eta| < 3.0`. To get better physmon until the problem is fixed (maybe in a later stage of the GX2F-development), the eta-range is reduced. The full eta-range could be used after solving: - #3267
…ct#3248) Have *almost* same settings for GX2F and KF makes it easier to understand in the physmon output and check if our results are good. ## Why *almost*? Had also 3 FPEs which fixed here, but did not choose this approach: - acts-project#3254 This issue only occurred for `2.5 < |eta| < 3.0`. To get better physmon until the problem is fixed (maybe in a later stage of the GX2F-development), the eta-range is reduced. The full eta-range could be used after solving: - acts-project#3267
|
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. |
|
#3411 does not solve the underlying issue but rather avoids getting there in the first place. I would keep it open for now. |
During the Athena integration, I ran again into the issue described in - #3267 This PR does not fix the navigation itself but avoids the GX2F ending up in a state, where the above issue would occur. I investigated different approaches to avoid ending up in a situation, where an FPE would occur. ### Simulate division The FPE occurs, when we are calling the path correction. Checking and aborting if the x-y components for position and direction are zero would be sufficient. However, we should also apply the transformation to the position first, which seemed a bit difficult in the actor. Using this approach too many tracks were filtered out. I didn't not check, if all of them would fail anyhow, though. ### Constrain parameters (Used) I had the issue only, when starting from a volume, that was different from the initial volume of the starting parameters. However, there were also cases, where I switched volumes and didn't crash. After looking into all non-crashing cases (analysed 13 tracks, because then the Athena truth tracking crashed), I saw, that all of them would later end with the error `NotEnoughMeasurements. Therefore, we effectively do not lose any tracks but detect their failure earlier. In the physmon, we also see with larger statistics no change to the current behaviour. ## Testing I built a new detector for testing this behaviour. I tried to reuse the old one by adding extra parameters, but I didn't succeed. Somehow, I had to flip the detector to force the volume change. I also added a visualisation script to it, that generates an `.obj` of the detector and draws the measurements. This one I used for the development since the beginning but didn't find a proper place to put it in. The new detector might be complex enough, that we maybe want to visualise it during development. <img width="1210" alt="image" src="https://github.com/user-attachments/assets/dcf5b91f-f98c-4511-8507-0fc7e4a23ace"> ## Blocked - #3463
|
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.
acts/Core/src/Surfaces/CylinderSurface.cpp
Line 164 in dc1a1d3
Stacktrace
Reproduce
Running
truth_tracking_gx2f.pywith2.5 < |eta| < 3.0can result in the above behaviour. When it happens, the gx2f pushed the updated parameters so far, that the first encountered surface isPixels::Barrelinstead 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.
The text was updated successfully, but these errors were encountered: