sPHENIX tracking discussion

[Anthony Frawley <afrawley AT fsu.edu>]

Hi Joe,

Presently, all track related classes are in trackbase_historic. It makes sense to put the new seed classes there also. If we don't get too hung-up on the name, any new track classes could reside in trackbase_historic, and we can eventually retire the Svtx classes.

As I mentioned today, I had to move MvtxDefs and InttDefs into trackbase in my branch, because they will be needed by ActsTransformations.

I say put the new seed classes in trackbase_historic.

Cheers

Tony

---

From: sPHENIX-tracking-l <sphenix-tracking-l-bounces AT lists.bnl.gov> on behalf of Osborn, Joe via sPHENIX-tracking-l <sphenix-tracking-l AT lists.bnl.gov>
Sent: Monday, April 11, 2022 5:19 PM
To: sphenix-tracking-l AT lists.bnl.gov <sphenix-tracking-l AT lists.bnl.gov>
Subject: [Sphenix-tracking-l] Longer Term Strategy with Trackbase

 

Hi all,

 

I started moving the track seed objects into trackbase, and ran into a circular package dependency. The problem is that the ActsTransformations class is in trackbase_historic as some of the functions are at the SvtxTrack level, so it needs to know about SvtxTracks. So, I wanted to pitch this for discussion before implementing it because some of the solutions I considered are pretty invasive.

 

The TrackSeed class needs the local->global transformation available in ActsTransformations. It may be easier to separate this into an ActsClusterTransformation class and an ActsTrackTransformation class, or something like this. One could exist in trackbase_historic, the other in trackbase.

 

It also brings up the question of what our longer term strategy is for these packages. Do we plan to have all the fundamental object classes in trackbase? Or do we plan to have a separate package for track related objects (e.g. trackbase_tracks or some more clever name if I actually spent more than 5 seconds thinking about it).

 

We may want to consider this carefully, to avoid having trackbase getting extremely cluttered but also without introducing the possibility for circular dependencies between packages.

 

Joe

 

---------------------------

 

Joe Osborn, Ph.D.

Associate Research Scientist

Oak Ridge National Laboratory

osbornjd AT ornl.gov

(859)-433-8738