sphenix-tracking-l AT lists.bnl.gov
Subject: sPHENIX tracking discussion
List archive
- From: Christof Roland <christof.roland AT cern.ch>
- To: Joe Osborn <osbornjd91 AT gmail.com>
- Cc: sphenix-tracking <sphenix-tracking-l AT lists.bnl.gov>
- Subject: Re: [Sphenix-tracking-l] Track DST Size
- Date: Wed, 21 Sep 2022 17:46:38 +0200
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.JoePS this means I don't even want to begin to know what the cluster DST consumes... On to TrkrClusterv4!___________________________Joe Osborn, Ph.DPhysics DepartmentBrookhaven National Laboratory
sPHENIX-tracking-l mailing list
sPHENIX-tracking-l AT lists.bnl.gov
https://lists.bnl.gov/mailman/listinfo/sphenix-tracking-l
-
[Sphenix-tracking-l] Track DST Size,
Joe Osborn, 09/21/2022
-
Re: [Sphenix-tracking-l] Track DST Size,
Christof Roland, 09/21/2022
-
Message not available
- Re: [Sphenix-tracking-l] [EXTERNAL] Re: Track DST Size, Joe Osborn, 09/21/2022
-
Message not available
-
Re: [Sphenix-tracking-l] Track DST Size,
Christof Roland, 09/21/2022
Archive powered by MHonArc 2.6.24.