sPHENIX tracking discussion

["Frawley, Anthony" <afrawley AT fsu.edu>]

Hi All,

Here are my notes from the tracking meeting this morning.

Cheers

Tony

Tracking meeting June 3, 2016:
------------------------------------------

We need to zero in on a preferred scenario for the tracking review. We have maybe a couple of months.
For the ALD response we (Alan and Mike) made progress on getting TPC tracking software to work in Hijing events, estimating space charge distortion effects (Tom) on single Upsilon simulations. The results say that we can connect tracks in the TPC to the maps inner barrel using single Hijing events.   

For TPC simulations there is a working branch in Mike's area.
Alan's tune 1 has good momentum resolution but 80% eff, his tune 2 has high efficiency but less good momentum resolution.
These tunes bracket a good place, so we should just need to refine them.
Next week Mike will take his private branch and merge it into the master so that it does not disturb the silicon tracking.

But we need quite a bit more realism before we can draw firm conclusions. The next step is very important - adding event pileup to the simulations. The beam crossing separation is 100 nsec, but there is 1.9 microsec latency in the maps readout, longer in the TPC. Not an issue for the maps in in Au+Au, but in pp it will have to be dealt with. For the TPC we will have between 1 and 2 events in Au+Au, more in p+p.
Mike thinks that it will be straightforward to implement for the silicon, but for the TPC expects it will be harder to tune under occupancy, it may take a couple of weeks.

Tom: Our goal should be to allow pileup to be a free parameter in the simulations - it depends heavily on gas chosen - and have the software tell us what we can tolerate. Mike: that is also the right way to construct the software.

TPC drift times will give us between 1 and 2 events in the TPC. Mike suggests building a super-event that has the collision of interest at zero, and decide how many crossings before and after you want to accept. All subsystems then need to decide which hits are irrelevant.
Mike: Two approaches: toss multiple hepmc events into G4, or throw events separately and later merge them at truth hits level at different times before running through disgitizers. Consider both pp and AuAu scenarios.

Tom: SB wants to get involved in tracking software, we want to contribute 2 postdocs and a faculty member. Mike will be back at BNL wed, will work with them. Should Mike go to SB on Friday? Yes.

JH: We need to improve the estimates of data rates coming off TPC. Use Hijing events, estimate reality factors. The actual data rate in Au+Au is going to be ~ 100 KHz (already almost there).
Tom: STAR and ALICE cluster their data in the hardware, giving a large volume reduction. But this makes it difficult to embed MC events in data. STAR takes some raw data for this reason - this will impact the data load.
Tom: We need to understand what the front end will look like for the no-trigger detector.

We discussed a possible intermediate tracker, which RIKEN is interested in. The purpose would be to add robustness to the tracking. It does not seem to be required in the simulations that do not include pileup effects, but may very well be needed once confusion from pileup is included in the simulations. Jamie Dunlop tells us that STAR needs to use their intermediate silicon tracker to track. In their case, the HFT has a long latency because all cells are polled. The ALPIDE chip has hit cells raise their hand, instead of polling all of them. So latency is shorter than it is for the HFT, but is more dependent on occupancy.

Assigning tracks to a crossing in each detector is a real issue. The TPC will have many collisions in pp, which one was the triggered one? Therefore the intermediate tracker should preferably see only one crossing, so that it disambiguates time vs position. This would verify that the track is correct in space (AuAu) and time (pp). The silicon technology proposed by RIKEN can zero in on one crossing. Other technologies are possible also for a fast layer.

Mike said that the LDRD defense at LANL yesterday seemed to go well - lots of good questions, he was able to give strong answers to all questions.

We decided to come back in two weeks.
Mike will come back with the TPC code in the build, and a plan for pileup implementation.
I will solicit reports from everyone on their plans for the pre=tracking-review period.