feat: unbiased trackstates for fitters that do not smooth

[AJPfleger]

What?

Lets the RootTrackStatesWriter.cpp write unbiased states, even if there are no smoothed states.

Why?

The states we are writing are based upon the Kalman Filter formalism. There, we would expect predicted, filtered, and smoothed states. The smoothed states should be the final states. Other fitters, like the GX2F, do not take this path. Therefore, the final estimate is written to predicted.

Until now, the unbiased states could only be computed from smoothed states. However, it is also for interest for other fitters to investigate the unbiased pulls and residuals.

The idea for this PR evolved while investigating the track states for the GX2F (PR #2949). Seems to be useful to have this in.

Notes

We need to check for state.hasCalibrated(), since the physmon tests for the GSF were crashing. It seems, the GSF creates states without measurements. There, the programme aborted with

state.calibratedSize(): 4294967295
template_switch<Fn, 6, 6>(v=4294967295) is not valid (v > NMAX)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 48.67%. Comparing base (6fd0337) to head (a1a038b).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2999   +/-   ##
=======================================
  Coverage   48.67%   48.67%           
=======================================
  Files         493      493           
  Lines       29004    29004           
  Branches    13816    13816           
=======================================
  Hits        14117    14117           
  Misses       4947     4947           
  Partials     9940     9940           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[github-actions]

📊: Physics performance monitoring for a1a038b

Full contents

physmon summary

• ✅ CKF truth_smeared
• ✅ IVF truth_smeared
• ✅ AMVF truth_smeared
• ✅ Track Summary CKF truth_smeared
• ✅ Seeding truth_estimated
• ✅ CKF truth_estimated
• ✅ IVF truth_estimated
• ✅ AMVF truth_estimated
• ✅ Track Summary CKF truth_estimated
• ✅ Seeding seeded
• ✅ CKF seeded
• ✅ IVF seeded
• ✅ AMVF seeded
• ✅ AMVF (+grid seeder) seeded
• ✅ Track Summary CKF seeded
• ✅ Seeding orthogonal
• ✅ CKF orthogonal
• ✅ IVF orthogonal
• ✅ AMVF orthogonal
• ✅ Track Summary CKF orthogonal
• ✅ Ambisolver seeded
• ✅ Ambisolver orthogonal
• ✅ Seeding ttbar
• ✅ CKF ttbar
• ✅ Ambisolver
• ✅ Track Summary CKF ttbar
• ✅ AMVF ttbar
• ✅ AMVF (+grid seeder) ttbar
• ✅ Truth tracking (GSF)
• ✅ Truth tracking
• ✅ Truth tracking (GX2F)
• ✅ Particles fatras
• ✅ Particles geant4

[andiwand]

I wonder if it would be better to actually write smoothed parameters in the GX2 as smoothed corresponds to a global fit.

In case of the GSF there is a smoothing step which seems not to be taken in one of the tests since the output changes?

[AJPfleger]

We had about 1,5 years ago a discussion in that direction. Since non of the 3 categories really make sense for the GX2F, we settled to use predicted since, it is the least confusing for:

• There is no filtering and smoothing happening
• It is the first in the list and people might look for the missing predicted/filtered if smoothed is chosen
• In the KF thefiltered andsmoothed is computed from the predicted/filtered instead of only the calibrated measurements. This would change how the categories depend on each other (in a logical sense)

[andiwand]

to me predicted seems the most confusing one but okay I don't want to open a discussion on this here

But I don't think these changes should affect the GSF output

[paulgessinger]

@andiwand Not sure this helps, but originally, I was thinking that we would treat them stacked, like

1. predicted
2. filtered
3. smoothed

There's an accessor that returns the highest of these, i.e. smoothed if available, otherwise filtered if available, otherwise predicted. That accessor is called parameters (although that might have turned out to be confusing now).

Anyway, I don't have a strong preference what the GX2F should write its result in. I could also see them being conceptually closest to smoothed, rather than predicted.

[acts-project-service]

✅ Athena integration test results [9fcfb7e]

✅ All tests successful

status	job	report
🟢	run_unit_tests
🟢	test_ActsEFTrackFit
🟢	test_ActsBenchmarkWithSpot
🟢	test_ActsConversionWorkflow
🟢	test_ActsWorkflow
🟢	test_ActsValidateAmbiguityResolution
🟢	test_ActsValidateResolvedTracks
🟢	test_ActsValidateTracks
🟢	test_ActsValidateActsCoreSpacePoints
🟢	test_ActsValidateActsSpacePoints
🟢	test_ActsValidateSeeds
🟢	test_ActsValidateOrthogonalSeeds
🟢	test_ActsValidateClusters
🟢	test_ActsPersistifyEDM
🟢	test_ActsGSFRefitting
🟢	test_ActsKfRefitting
🟢	test_ActsExtrapolationAlgTest
🟢	test_ActsITkTest
🟢	run_workflow_tests_run4_mc
🟢	run_workflow_tests_run2_mc
🟢	run_workflow_tests_run2_data
🟢	run_workflow_tests_run3_mc
🟢	run_workflow_tests_run3_data
🟢	run_art_test: test_data18_13TeV_1000evt
🟢	run_art_test: test_ttbarPU40_reco

[AJPfleger]

@paulgessinger in developer meeting: should we refactor to automatically take the "highest" fit?