[Feature Request] Reference surface for tracking algorithm is hardcoded to be at origin

[janheinri]

Hi,

I noticed the following while going through the Python example scripts in Acts: When using the Kalman Filter truth tracking from https://github.com/acts-project/acts/blob/main/Examples/Python/python/acts/examples/reconstruction.py I got the following error: ResPlotTool ERROR Global to local transformation did not succeed. Apparently this happens, because the starting vertex for my particle gun is not located at the origin. The reference surface for the tracking algorithm seems to be hardcoded in https://github.com/acts-project/acts/blob/main/Examples/Algorithms/TrackFitting/src/TrackFittingAlgorithm.cpp#L88 Many thanks to @andiwand for helping me to understand what the underlying problem was here. I feel like this could become restrictive in case the fitting algorithm is used for experiments with non collider geometries. I was indeed able to remove the above error by adapting the corresponding reference surface. It is probably possible to mostly circumvent this by either also hardcoding this if necessary or using custom global coordinate transformations for affected geometries. The cleanest option would probably be to pass the reference surface from a higher level down to the tracking algorithm. Even though I must admit, that I have no idea how complicated this implementation would be. However I thought it might be a good occasion to properly document this in case someone else might have the same problem in the future.

[paulgessinger]

Right, I guess that makes sense. Note that the fitter itself already has the ability to have the reference surface passed in, in part for exactly this reason. This is only hard-coded in the examples, where we're a bit more liberal with the assumptions that we're making and how generalizeable we want to make things.

I guess the easiest solution would be to make the reference position at least configurable from python?

[janheinri]

Oh I am sorry for misinterpreting this. So far I have mostly used the examples. Yes I think this would already help out a lot. The main advantage probably is that nothing from the core library needs to be changed if you want to have a different reference surface from python.

[andiwand]

I think it could also be as simple as providing a target surface from python. Either we move the default to python then or we use the C++ default if python provides None

[paulgessinger]

Oh right we can probably actually instantiate the surface directly in python as well.

[github-actions[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.