sPHENIX tracking discussion

[Anthony Frawley <afrawley AT fsu.edu>]

Please ignore the last few lines after my signature in the summary. They are left over raw notes that I forgot to delete.

Tony

---

From: Anthony Frawley
Sent: Tuesday, February 6, 2018 4:09 PM
To: sphenix-tracking-l AT lists.bnl.gov
Cc: Anthony Frawley
Subject: Notes from tracking meeting on 2/6/2018

 

Hi All,

Here are some notes from the tracking meeting this morning.

We started out with a request from John Haggerty that we update the performance plots (and discussion) in the CDR document by February 12 so that it better reflects our current understanding and simulations of the tracker. Christof and Tony will take this offline.

John also told us that we have been asked to provide a list of Ultimate Performance Parameters (UPP's!) to reflect the ultimate performance goal of the experiment once commissioning is complete. We agreed that we should keep the list short and conservative. Suggestions were:

- Upsilon mass resolution of 100 MeV or better.

- Tracking efficiency of 90% or better in central Au+Au collisions.

- pT resolution of 10% or better at 40 GeV/c.

New storage objects for tracking:

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

The rest of the meeting was a discussion of redesigned storage objects for the upgrade and reorganization of the tracking software. We discussed this two weeks ago, when Darren presented some slides containing a proposal. Darren's slides from that meeting have been posted on the agenda page for today's meeting:

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

I will just summarize the consensus that came out of the (1 hour long) discussion this morning and the earlier discussions.

The TrackerHit object will move from storing a single hit to storing a list of related hits.

Each instance of a TrackerHit object (Darren's slide 4) will store the following:

• For the TPC, a (zero suppressed) list of time bins and ADC values for one readout channel.
  

• Or for the MVTX, a list of hit pixel ID's  for one sensor.

• Or for the INTT, a list of hit strip ID's and ADC values for one sensor.
  

A hit ID that encodes the address of the TPC readout channel, MVTX sensor, or INTT strip, including layer.

• Reduce this ID to 32 bits, since it does not need to encode cell/strip/pixel locations in this scheme.

A single pointer to a truth map that will contain the information needed for truth matching (TBD).

• This pointer will be empty when analyzing real data
• The truth map could be arbitrarily detailed, depending on what is needed for a given purpose.
  

Each subsystem has its own class for best sorting.

This scheme eliminates the need to store the readout channel/sensor address with every cell/strip/pixel hit.
It will greatly facilitate clustering.
It maximally segregates simulations and reconstruction.

The TrackerCluster object (Darren's slide 5) is what the tracking code will interface with.
TrackerCluster needs a flag specifying whether the stored position is local or global.

Darren will absorb all of this and update his proposal. We will meet next Tuesday at 10:30 am to resume the discussion.

If I missed anything or got anything wrong, please correct me!

Thanks
Tony



Tracker cluster needs a flag if stored position is local or global (Darren's slide 3 from jan22)
Cluster uses tracker ID to store layer.
Do we need the lower 32 bits, now that TrackerHit contains list of pixels, cells, strips
Keep only upper 32 bits for TrackerHit.