feat: Adding unit tests for perigee propagation outside beam pipe

[asalzburger]

This adds a (currently failing) unit test when starting from a perigee that is not within the beam pipe but within the pixel barrel volume.

Several issues can be studies here:

• path length estimates for low momentum tracks
• wrong destimation volume checks

@andiwand @paulgessinger

[andiwand]

interesting that this only happens for 1 out of 12 cases

q = -1, p = 0.1
start -8.86561  28.6601       10
end -8.8656 28.6601      10
q = -1, p = 0.25
start -8.86561  28.6601       10
end -8.8656 28.6601      10
q = -1, p = 0.5
start -8.86561  28.6601       10
end -8.86561  28.6601       10
q = -1, p = 1
start -8.86561  28.6601       10
end -8.86561  28.6601  9.99999
q = -1, p = 10
start -8.86561  28.6601       10
end -8.86561  28.6601       10
q = -1, p = 100
start -8.86561  28.6601       10
end -8.86561  28.6601       10
q = 1, p = 0.1
start -8.86561  28.6601       10
end  88.4957 -286.083  91.9656
/home/andreas/cern/source/acts/Tests/UnitTests/Core/Propagator/PropagatorTests.cpp(432): [1;31;49merror: in "PerigeePropagationFromOutside": check startPerigee.position(tgContext).isApprox( endPerigee->position(tgContext), 1e-4) has failed[0;39;49m
q = 1, p = 0.25
start -8.86561  28.6601       10
end -8.8656 28.6601      10
q = 1, p = 0.5
start -8.86561  28.6601       10
end -8.86561  28.6601       10
q = 1, p = 1
start -8.86561  28.6601       10
end -8.86561  28.6601       10
q = 1, p = 10
start -8.86561  28.6601       10
end -8.86561  28.6601       10
q = 1, p = 100
start -8.86561  28.6601       10
end -8.86561  28.6601       10

and start and end position are almost scaled by a factor of 10 modulo sign

[paulgessinger]

Could you add a test case where the parameters are inside the beampipe volume, but the target perigee parameters are outside?

[paulgessinger]

We could potentially flag the failing test as expected failure and merge it already.

[andiwand]

I looked into this and believe that we run into the path limit with p <= 0.1 which is set to 1/2 of the helix because the end direction after the forward propagation is (-x,-y,z)

the back propagation log looks like this

15:27:42    Propagator     VERBOSE   Path aborter limit set to -523.961 (full helix =  -1047.92)
15:27:42    Propagator     VERBOSE   Entering propagation.
15:27:42    Propagator     VERBOSE   No Volume | Entering navigator::status.
15:27:42    Propagator     VERBOSE   No Volume | Initialization.
15:27:42    Propagator     VERBOSE   No Volume | Current surface set to start surface undefined
15:27:42    Propagator     VERBOSE   No Volume | Slow start initialization through search.
15:27:42    Propagator     VERBOSE   No Volume | Starting from position (88.4957, -286.0825, 91.9656) and direction (-0.9436, -0.2919, 0.1564)
15:27:42    Propagator     VERBOSE   Pixel::Barrel | Start volume resolved.
15:27:42    Propagator     VERBOSE   Target: x | Target surface reached at distance (tolerance) 4.86623e-06 (0.0001)
15:27:42    Propagator     VERBOSE   Target: x | Current surface set to target surface  undefined
15:27:42    Propagator     VERBOSE   Propagation terminated without going into stepping loop.
15:27:42    Propagator     VERBOSE   Stepping loop done.

I believe here we abort so early because our initial position and direction "intersects" the perigee already after the 180° rotation from the forward propagation

[stale[bot]]

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.

[asalzburger]

Will redo with with navigator infrastructure.