The Track class does not seem to give access to track-fit error matrices (variance-covariance matrix). In general, it is needed to quantify the track resolution.
My use case: in ATLAS ITk Strips, we get a residual plot which is a combination of strip resolution (about 20 um) and track resolution (also about 20 um). To get the strip detector resolution, we would like to unfold the track resolution from the rms width of the residual plot. That requires a rather precise estimate of the track resolution which in turn needs a good model of our beam set-up (including passive material, hence my previous topic).
There are some issues with this:
For straightline filts, it is easy to get the error matrix (a 5 x 5 symmetric matrix, or 4 x 4 with no B-field) from the ROOT fit results. But this fit ignores material, so if the resolution is dominated by multiple scattering (as in our set-up), it is not much use.
For Gbl tracks, the covariance matrix would be large (a square of dimension 2 x number of detectors I think, maybe bigger). The Gbl manual explains why this is not calculated (CPU time would blow up). Instead they give a 5 x 5 (4 x 4 for B = 0) matrix for each plane (passive, DUT, or telescope planes). That is good enough for the use case I have. But complicates having a base method that suits all track types.
I implemented something giving a vector of 4 x 4 matrices: a single element for straightline, a mult-element (one per plane) for Gbl.
What I see is that for straightline, it does not mean very much because it ignores material, but is estimated from the hit data, so varies event to event. So it needs to be calculated for each event.
For Gbl tracks, the matrix is constant, so not much point obtaining it every event. I currently insist on all 7 telescope planes having hits on the track; I suspect that with hits missing, it would vary according to how many and which ones are missing. I suspect Gbl correctly calculates the matrix from the geometry and resolutions, not using hit positions e.g. using Gerhardt Lutz’s formulation.
So … it would be good to have. I would not at all recommend my implementation. But I would like to explore how things could be implemented well.