search

acts-project / acts

Experiment-independent toolkit for (charged) particle track reconstruction in (high energy) physics experiments implemented in modern C++
https://acts.readthedocs.io
Mozilla Public License 2.0
104 stars 166 forks source link

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

Open janheinri opened 12 months ago

janheinri commented 12 months ago

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 commented 12 months ago

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 commented 12 months ago

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 commented 12 months ago

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 commented 12 months ago

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

github-actions[bot] commented 11 months ago

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.