GenFit Track Model and StEvent

[plexoos]

On 10/14/22 11:20 AM, Brandenburg, James wrote:

I spent yesterday investigating GenFit to see if tracks can be saved as primitive types and then rebuilt. So far the answer is no as GenFit does not provide any ctors or other methods to do this. Also because the GenFit track is a deeply nested object (see attached figure) it requires diving into every member and saving it with some primitives. I understand the desire to avoid dependencies and I am open to solutions along that direction if they can be achieved reasonably.

For instance, can we not use the "Pimpl" idiom in c++ with a fixed size struct so that StEvent knows how to handle the memory? In this case the implementation can be outside the StEvent .so

There is also the similar dependency hiding approach of forward declaring classes and using references - has this been done in StEvent before? I am not sure how this works with IO though.

It seems relevant that we use a pegged version of GenFit in order to support ROOT5 and that GenFit is not actively maintained - so there is no expectation of updates unless we make them ourselves. Finally, the GenFit classes all inherit from TObject and appear to be streamer friendly, though I cannot find this written explicitly anywhere in the docs. I can test this if needed though.

-Daniel

[plexoos]

On 10/14/22 12:51 PM, Dmitri Smirnov wrote:

Hi Daniel,

Let me try to understand this better. When you propose to save a genfit::Track does it imply that we save the track parameters and the cov matrix at every fit point? Isn't there a propagator in GenFit that could be used to get track parameters at an arbitrary detector layer given a seed at DCA or vertex? It is possible I am missing something in the way how you expect to use the rebuilt Track once it is read from StEvent.

[plexoos]

On 10/17/22 10:34 AM, Brandenburg, James wrote:

Hi Dmitri, Jason, Xin,

I completely understand your question and from my experience with past STAR tracking it is understandable to represent tracks with a state + cov matrix and let the model go from there.

GenFit has a track propagation "representation" (we use the runge-kutta rep).
However, a fully fit track from GenFit includes more than a single trackRep. So there are two issues:

1. If we want to re-fit the tracks with calorimeter info after matching we need the full track object - this has been the plan for a while now. Or if the alignment / calibration makers are separate (not in the tracking

2. Even if we could live with just track projections, So far I cannot reproduce the projections with only a single state - the fitted track saves KalmanFilterStates at several places along the trajectory and I am not currently sure how these are used for final track projections. I will try to understand this more thoroughly.

Assuming I can understand #2 better and determine what / how many states must be saved for a given track, I am not sure how to rebuild everything I need from the primitive states (e.g. float vectors). You can see this from the class diagram I sent - that the AbsTrackRep depends on KalmanFitterInfo which in turn depends on the defined DetPlanes and TrackPoints.

If you have further insight on this please let me know,
Daniel

[plexoos]

On 10/19/22 10:37 AM, jwebb wrote:

Hi Daniel (et al),

Just getting back up to speed after a few days off. Quick questions...

1. If we want to re-fit the tracks with calorimeter info after
   matching we need the full track object

I guess the point is that you may need the constraint from the calorimeter energy
response to confirm / improve the charge sign of the tracks?

Is there a technical reason that you can't perform this refit during the data
production, when the genfit tracks are available? Or is this a process issue...
i.e. final calorimeter gains will not be available at time of data production.

Jason

[plexoos]

I see that you have a function to refit tracks with silicon hits:

star-sw/StRoot/StFwdTrackMaker/include/Tracker/TrackFitter.h

Line 446 in 6dd0b8e

TVector3 refitTrackWithSiHits(genfit::Track *originalTrack, Seed_t si_hits) {

It looks to me as it uses only the original track momentum from the cardinal representation to do the refit. Why can't this approach be used to refit tracks once they are read from StEvent? As with TPC tracks we can think of saving the innermost and outermost track states if this would help.