sPHENIX tracking discussion

[Gregory Ottino <gottino AT lbl.gov>]

Hi all,

Unless I am mistaken, Tony Joseph and I had a discussion of this yesterday. Maybe we can have a discussion at the tracking meeting (or after) today, as I think Tony has been working on implementing this functionality and getting it in centrally would be better so it could be setup for cosmics or collisions.

Best,

Greg

On Wed, Oct 16, 2024 at 10:41 AM Osborn, Joseph <josborn1 AT bnl.gov> wrote:

Hi Hugo,

> ​Right now the only instance that I have found is in TrackResiduals::lineFitClusters(). Is that all there is ?

Yes, this was just quick and dirty at the beginning of the run to get us going with something. It was definitely not intended to be for long term use.

> ​Is there any other, more correct, alternative around ?

If not: I have some old code that I can easily repurpose that would do a proper fit to the clusters accounting for their uncertainties. (this boils down to a simple 4x4 matrix inversion really)

Note that ideally, an ACTS (or GENFIT) straight line fit would be even better than this, because it would properly handle the  material budget in addition to the cluster uncertainties.

We don't have one right now. Acts does not have a 0 field fitter - the current KF expects nonzero field so it just dies if you try to run it with a 0 constant field. I have used it with a really small constant field (e.g. 0.01T) but haven't had time to do careful debugging on efficiencies etc. It completes some fits but inevitably there will still be some bias to this, because it is of course still fitting to some helix even if it is very low curvature. If GenFit has something available to use perhaps we could use it since we won't really be "production time constrained" with this data as it is special. But that would have to be a global decision as we'd have to keep GenFit in our builds long term. Or we could develop something ourselves, based on what you already have or something else.

> ​Finally: is TrackResiduals really the right place to do such a fit, and should we not rather write a dedicated module, similar to PHActsTrackFitter ? This would allow all evaluators to run on straight track fits (including my own), and not just PHTpcResiduals.

TrackResiduals is definitely not the place to do this,  your suggestion is a better long term solution. This just developed out of a quick and dirty way early in the run. In fact I think it was really made when we only had 0 field cosmic data to look at and has not been developed any further since (e.g. with the actual zero field data) we have been focusing on commissioning/characterizing various things in the run. The actual simple line fitting functionality is really embedded in the TrackFitUtils utility, which is accessible by anything.

Those are my initial thoughts, but more discussion is welcome.

Joe

___________________________

Joe Osborn, Ph.D

Physics Department

Brookhaven National Laboratory

josborn1 AT bnl.gov

---

From: sphenix-tracking-l-request AT lists.bnl.gov <sphenix-tracking-l-request AT lists.bnl.gov> on behalf of "Pereira Da Costa, Hugo Denis Antonio" <sphenix-tracking-l AT lists.bnl.gov>
Sent: Wednesday, October 16, 2024 10:21 AM
To: Tony Frawley <frawley AT fsunuc.physics.fsu.edu>; Joe Osborn <osbornjd91 AT gmail.com>; sphenix-tracking-l AT lists.bnl.gov <sphenix-tracking-l AT lists.bnl.gov>
Cc: Hugo Pereira Da Costa <hugo.pereira.da.costa AT gmail.com>
Subject: [[Sphenix-tracking-l] ] Straight line fit in fun4all

 

All, (especially Joe, Tony)

I am looking into analyzing our ‘golden’ zero-field runs.

I am confused about which code is responsible for doing the straight line fit of our clusters in that configuration.

Right now the only instance that I have found is in TrackResiduals::lineFitClusters(). Is that all there is ?

This fit ignores errors on the cluster position, thus handling MVTX, INTT and TPC clusters on the same footage. This is subobtimal for qualifying misalignments.

It also ignores TPOT clusters, probably for the same reason. (because TPOT detectors are 1D, one of the coordinate has an error as large as the strip length and the cluster position at the middle of the strip. Ignoring the error will break the fit.)

Is there any other, more correct, alternative around ?

If not: I have some old code that I can easily repurpose that would do a proper fit to the clusters accounting for their uncertainties. (this boils down to a simple 4x4 matrix inversion really)

Note that ideally, an ACTS (or GENFIT) straight line fit would be even better than this, because it would properly handle the  material budget in addition to the cluster uncertainties.

 

Finally: is TrackResiduals really the right place to do such a fit, and should we not rather write a dedicated module, similar to PHActsTrackFitter ? This would allow all evaluators to run on straight track fits (including my own), and not just PHTpcResiduals.

 

Comments ?

 

Hugo