Estimate Track Parameters from Seeds use only one surface. What about strips?

[CarloVarni]

The estimation of track parameters from seed uses space point information, but also uses a surface to perform a global-to-local transformation of the bottom space point coordinate. It also checks that the bottom space point lies on the provided surface:
https://github.com/acts-project/acts/blob/main/Core/include/Acts/Seeding/EstimateTrackParamsFromSeed.hpp#L156

This may be appropriate for pixels, since there is only one surface. But does it apply also to strips and overlap strips? We are only using one surface in that function, but the space point is constructed from multiple 1D measurements. In the strip overlap case these measurements are not even back-to-back.

Or in general, what would be the appropriate procedure in cases in which we have 3D space point positions starting from multiple measurements?

/cc @noemina @paulgessinger

[beomki-yeo]

Currently, EstimateTrackParamsFromSeed indeed only works for planar surface because the seed is at the middle point of two measurements, which means that the seed is not bound to the surface.

In general, you can get the bound track parameter from the seed with the following steps;

1. Get the free track parameter from seed
2. Extrapolate or propagate track to the bottom strip (one that is closer to the origin)
3. Get the bound track parameter from the propagator

The difficult part is that ACTS propagator does not take a free track parameter as an input argument (it only takes bound track parameter AFAIK, fix me if it is wrong). I didn't like that so I added another constructor in detray stepper and propagator to take free track parameter as an input. (I added it for the same purpose you have) Check the detray code here: https://github.com/acts-project/detray/blob/main/core/include/detray/propagator/base_stepper.hpp . (Also you have to be careful when you do covariant transport for the propagator fed with free track parameter input; as it starts from the free track parameter, you should not include jacobian for bound_to_free coordinate transformation in calculating the transport jacobian)

Thing is that writing the extrapolation code might be a heavy task - I know how to do it in detray but have no idea with ACTS code; Other experts might know how to do it...

[beomki-yeo]

BTW it is nice that you brought it up - we need to do refactor EstimateTrackParamsFromSeed so that it can work with arbitrary detector type

[pbutti]

Hello,
Really interesting discussion. I hope people won't mind if I chime in.

I'm not fully sure I understand the comment of @beomki-yeo. The vector of parameters returned by the estimator is bound to the surface it is referenced to, in this case the one of the bottom space point.
However I agree that the propagator for the moment only take bound track states for propagation. While in principle should be always possible to define a curvilinear surface given the track momentum direction at an arbitrary point on track and project the track parameters to bound, your solution to extend to free parameters propagation is definitely more elegant (and probably faster).

@CarloVarni in my opinion, one possible simple extension could be to just pass a custom surface constructed around the 3D bottom space point. In the case of a 2 strip cross formed by an axial-stereo pair, I'd construct an axial-oriented surface with translation equal to the location of the 3D space point. You'd have loc0/loc1 = 0 and the rest should be well defined. I don't think the interface should be changed in this case.
I'm not sure I can comment on the strip-overlap case as I'm not able to visualize the geometry.

[beomki-yeo]

The vector of parameters returned by the estimator is bound to the surface it is referenced to, in this case the one of the bottom space point.

Possibly I was wrong, but isn't a spacepoint from multiple strips bound to any surface?

[beomki-yeo]

to define a curvilinear surface given the track momentum direction at an arbitrary point on track and project the track parameters to bound,

Ah indeed. Starting from a curvilinear surface sounds much better

[stale]

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.