sPHENIX tracking discussion

[Anthony Frawley <afrawley AT fsu.edu>]

Hi All,

Here are my notes from the meeting this morning. Please send corrections or comments to the list.

Cheers

Tony

February 20, 2018 tracking meeting

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

The focus today was on code reorganization. We had a very useful discussion.

Haiwang showed two slides on code reorganization. They are posted on the agenda page:

https://indico.bnl.gov/conferenceDisplay.py?confId=4284

Slide 1:
Christof suggested adding a truth seeding module that sets seeds from truth tracks, for testing. Agreed.
Haiwang commented that for simulations without the MVTX we will need an alternative vertexing scheme to Sookhyun's MVTX based one. Yes. Not urgent (we can still use truth vertexing in that case).

Slide 2:
Discussion about Haiwang's proposal to add an 8 bit flag to the cluster and vertex objects to keep track of vertex evolution from initial vertexing to final 3D vertexing. Christof suggested just making vertex objects with different names on the node tree, with each module knowing which one it wants. Agreed.

A fairly long discussion about how to relate clusters to vertices. The conclusion was that instead of adding flags to clusters, we should create targeted association maps for each purpose. For example, a map to store which tracking iteration the cluster was used in, a separate map to associate cluster with vertex, etc.
The idea is to create a targeted map when it is needed, and keep it on the node tree. Maps would generally be transient, not written out unless it is needed in the file.

Christof suggested making a flow chart of the proposed iterative tracking modular structure. We agreed that Haiwang and Christof will discuss this off line. Making an example macro (or pseudo macro) would be useful. We will discuss it again next week.

Haiwang will add truth vertexing seeding, and will add extra structures to make things work with iterative tracking.
Seed cleaning and track cleaning should be broken out into separate modules?

The discussion turned to segregation of simulations and reconstruction code. We settled on this:

Create separate areas in offline/packages/ for reconstruction code and storage and utility objects (e.g. code for decoding keys). Jin summarized the discussion as follows. This parallels the way it is organized for the calorimeters:

offline/packages/TrackBase
- libtrack_io.so
  - * TrkrCluster
  - * TrkrHitSet
- libtrack_util.so
  - * TrkrDefUtil

offline/packages/TrackReco
- libtrack_reco.so
  - * PHG4TrackKalmanFitter
  - * Other construction modules

All classes should have G4 removed from the name: e.g. PHTrackKalmanFitter.

Calibration code will be located in the separate subsystem specific areas (eg. offline/packages/TPCCalibration).

Christof suggested that we add a base class for all reconstruction modules, to facilitate introducing new ways of doing things in the future. (e.g. going to a machine learning tracking module instead of Kalman filter). The idea would be to make base classes for various purposes, e.g.
- Clusters from hits
- Seeding from clusters
- Tracks from seeds
- etc.
These would be added on top of SubSysReco. It would allow us to take all of the common parts out of the modules and keep them in the base class. Then introducing a new algorithm for doing something would not require reproducing all of the I/O, for example. We agreed that adding the base class now will increase the work needed in the short term, but putting it off will only make the required effort greater. Haiwang will try to set it up.

Sookhyun noted that we need to map clusters to tracks, and asked where the map that associates clusters to tracks should be. It should go in offline/packages/TrackBase.

Long discussion about when to move code to offline. We finally agreed that:
- Darren will move his new storage objects code into offline/packages/TrackBase and make a pull request.
- Haiwang will add code to offline/packages/TrackReco and make a pull request.