acts
acts copied to clipboard
Vertexing issues observed in python vertexing example
TruthVertex Finder + VertexFitterAlgorithm with reconstructed input tracks crashes with a SEGFAULT
This combination doesn't make too much sense I suppose, but right now it gives a hard SEGFAULT. I think this should work on a technical level. My understanding is that the Truth particles are used for the vertex finding, and then the vertex fit runs on reconstructed tracks. This seems to be fine if the tracks are reconstructed in the same job, but not if the tracks are read back in from the summary. My guess is that there's some link between tracks and truth particles that the fitter uses and the reader doesn't recover correctly.
Vertex performance writer warnings
The vertex performance writer (I think) complains with a WARNING if the number of reconstructed tracks and the number of truth particles doesn't match. I guess this case is expected, since tracking efficiency is not 100%? Should this be a loud WARNING? Right now I have to work around that in the python based tests because in the CI, a WARNING log message will throw an exception
AMVF gives error for empty input
The AMVF gives a VertexingError
when the input collection is empty. I guess it makes sense that the vertexing can't run in this case, but the question is if that should be a hard error, or more of a noop: not enough tracks => no vertices. Otherwise, I'm guessing the vertexing algorithm around the AMVF in this case should check if the input is empty and not call the AMVF at all in this case.
Thoughts / input / discussion is welcome!
/cc @Corentin-Allaire @robertlangenberg @asalzburger @baschlag
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.
The vertexing test is flaky and fails irregularly. I haven't been able to figure out what the underlying problem is. Example failed job: https://github.com/acts-project/acts/runs/7296836937?check_suite_focus=true
Attached the full logs for debugging.
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.