sPHENIX tracking discussion

[Joe Osborn <osbornjd91 AT gmail.com>]

Sounds like there is consensus that this is needed as the state information is in general extraneous other than in special circumstances. I will work on it.

Joe

On Wed, Sep 21, 2022 at 12:12 PM Pereira Da Costa, Hugo Denis Antonio <hugo.pereira-da-costa AT lanl.gov> wrote:

As far as track based distortion corrections are concerned, (Job A): if one considers only the tracks that are in TPOT acceptance, this is only about 8% of the total tracks (and even less if you put a min pT cut). For all other tracks, they are essentially useless, unless we want to rely on MVTX+INTT only to extrapolate in the TPC

Hugo

---

From: sPHENIX-tracking-l <sphenix-tracking-l-bounces AT lists.bnl.gov> on behalf of Christof Roland via sPHENIX-tracking-l <sphenix-tracking-l AT lists.bnl.gov>
Sent: Wednesday, September 21, 2022 9:46 AM
To: Joe Osborn
Cc: sphenix-tracking
Subject: [EXTERNAL] Re: [Sphenix-tracking-l] Track DST Size

 

Hi Joe, 

I think we should think carefully for which use case we need to store the entire track states together with the track, as you said.

If we store the packed cluster informations ~20bits per cluster(layer) together with the momentum at the vertex plus covariance, we 

can do analysis with the tracks and if needed we can apply new corrections and refit the track and rebuild all trajectory states.

The fullblown trackstates we only need in some expert debug mode or internally to job A where hugo's residual calculation is applied.

A simple track + 20bit cluster model should amount to ~6PB for 100B AuAu events I calculated a while ago.

Cheers

   Christof 

On 21. Sep 2022, at 17:31, Joe Osborn via sPHENIX-tracking-l <sphenix-tracking-l AT lists.bnl.gov> wrote:

Hi all,

Chris looked at the stripped down track+vertex only DSTs in their current form - they come out to 50 kB per pp event which corresponds to 5 PB for 100B events. This is probably going to be worse in AuAu, thus, we need to come up with an even more stripped down version of the track object.

The vast majority of the space must be consumed by the storage of all the track states in the track object. A single track state contains a pathlength (float), position and momentum (6 floats), and a covariance (21 floats), and is saved in the track for each state (e.g. up to 57 layers of tracking + 3 calo layers). In reality this will not be needed by the average analyzer, I suspect, other than the calorimeter projection states.

Therefore, I propose creating a new track version which we can run as an afterburner once the tracking is finished that will strip this information out and give only the bare bones of the track which excludes all state information other than the calorimeter projections which are needed by the analyzers. This will maintain the current track object which contains all the state information, which is (for example) needed in the distortion correction determination, while also writing to DST a stripped down version.

Any objections? I can implement this if there aren't any comments.

Joe

PS this means I don't even want to begin to know what the cluster DST consumes... On to TrkrClusterv4!

___________________________

Joe Osborn, Ph.D

Physics Department

Brookhaven National Laboratory

josborn1 AT bnl.gov

_______________________________________________
sPHENIX-tracking-l mailing list
sPHENIX-tracking-l AT lists.bnl.gov
https://lists.bnl.gov/mailman/listinfo/sphenix-tracking-l