sPHENIX tracking discussion

[Thomas K Hemmick <hemmick AT skipper.physics.sunysb.edu>]

5003... (the last one).

---------- Forwarded message ----------
From: James Dunlop <dunlop AT bnl.gov>
Date: Fri, Oct 30, 2015 at 10:23 AM
Subject: Re: 5000 pancakes
To: Thomas K Hemmick <hemmick AT skipper.physics.sunysb.edu>
Cc: James Dunlop <dunlop AT bnl.gov>


Just as an FYI: I woke up this morning with a worry about loopers, since these multiply the
charge by looping back into the TPC and leaving multiple periods in the helix.  Very low-pt
electrons from UPC-like events double the occupancy of the HFT, for example.
But the looper situation is actually quite similar in sPHENIX as in STAR, because the
lower radius to first order cancels the field increase.    sPHENIX is still well away from the
peak in the charged particle pt distribution at ~300-400 MeV for hadronic events.
In the cals there is so much energy loss that that's not a problem.  I just draw the circles below.

This is also, BTW, why sPHENIX needs better position resolution than STAR to do
better in the linear term in momentum resolution.  To first order, position-dominated pt resolution scales as 1/(L^2 B) where
L is the transverse radius of the outermost point, assuming perfect vertex constraint.
STAR has B of 0.5 T, L of 200 cm.  sPHENIX has B of 1.5 T, L of 80 cm.
sPHENIX/STAR = 0.5*200*200/(1.5*80*80) = 2,
so for the same position resolution sPHENIX has a factor of 2 worse momentum resolution in the linear term than STAR.
Without a vertex constraint, in the TPC alone that's 0.5*150*150/(1.5*50*50) = 3.
However, the higher B field brings down the MS component, so that's where sPHENIX wins for the moderate pt of Upsilon daughters.

Another worry is background from material interactions.  The support structures of the HFT
have caused all sorts of headaches in the space charge distribution by increasing the charge load
on the east of the TPC, where the HFT is cantilevered.
That will need a pretty detailed MC for any sPHENIX configuration.  But, then again, since these are pancakes
all you have to worry about is ensuring that there isn't a lot of azimuthal structure in your material
distribution.

--J






> On Oct 29, 2015, at 10:29 PM, James Dunlop <dunlop AT bnl.gov> wrote:
>
> Making sure this gets to the right mailbox.
>
> Oh, and for completeness, the algorithm to get the multiplicity distribution on the
> right from the double error function on the left is that you do
> mult = pow(ctbsum^{1/4},4)/35
> Just a simple scaling from a very old study I did on multiplicity
> distributions; again, not the perfect distribution of what
> charge will look like event by event, but should get the basic
> shape pretty well.
>
> --J
>
>
>> Begin forwarded message:
>>
>> From: James Dunlop <dunlop AT bnl.gov>
>> Date: October 29, 2015 at 10:23:20 PM EDT
>> To: thomas.hemmick AT stonybrook.edu
>> Cc: James Dunlop <dunlop AT bnl.gov>
>> Subject: Re: 5000 pancakes
>>
>> Rough test, showing that the RMS of a 5000-folded example multiplicity distribution is ~1.5%, and
>> it's pretty darn gaussian.  Don't worry about the absolute scale; pretty close, but not exact.  Gets
>> the basics of the multiplicity shape right, though.  So you should be able to get a few percent precision with
>> just averaging.  I'd be doubtful you could do much better anyway without much more sophisticated
>> treatment of non-uniformities in the charge distribution radially and azimuthally (backgrounds, for example).
>>
>> Still need to have a good measure for the total charge, and doing that with
>> electronic charge history summing is probably a smart way to do it anyway (though
>> you could always try to do it the STAR way and just keep track of instantaneous lumi and
>> scale it up and/or down empirically.
>> There, though, we keep track of changes at the 1s level, because of the slow flushing time.  With your
>> faster flushing rate you'd
>> have to keep a more granular scaler rate in order not to miss beam-related events.)
>>
>> Still, should be relatively easy algorithm.  People do this kind of thing in FPGA's for baseline
>> shift subtraction.  Just for every RHIC clock tick you also sum up the charge over threshold over
>> some region of the detector, put
>> that into a rolling buffer, and read out that history when you read out the TPC.  Could also do it
>> for your faster ticks, but I assume these are a fixed multiple of the RHIC ticks for synchro reasons.
>>
>> Probably smart to select the regions by radius and some azimuthal sectioning, since there
>> is an overall 1/r to 1/r^2 decrease in charge vs. radius, and if there is ever a beam background
>> that tends to be along the horizontal (actually more like 30 degrees or so above the horizontal,
>> because the floor can shield).  Only real issue is that you have to have a pretty good handle on
>> noise subtraction, since even one noisy channel that is always on will skew this sum charge.
>> --J
>>
>>
>>
> <check_5000folding.pdf>
>>
>>
>>> On Oct 29, 2015, at 5:47 PM, James Dunlop <dunlop AT bnl.gov> wrote:
>>>
>>> OK, just taking the clearing time of star, about 1 s, and bringing that down an order of magnitude, you still have 0.1 s clearing time.  At 50 khz interaction rate that's 5000 pancakes in 80 cm, or something like 150 um on average between the pancakes.   Now there are large fluctuations in the charge of these pancakes, both due to loopers and the underlying humpbacked multiplicity distribution, but I bet that knowing fine details of the spatial distribution of the charge really doesn't matter much.  Should be a simple Monte Carlo with a quick 2d calculation of the kick per charge for a Delta function folded in with a charge per pancake uniform in charge^1/4, spaced randomly, as compared to the same average amount of charge spread randomly.  I bet the rms is actually quite small.  5000-folding gets you pretty far on the central limit theorem.
>>
>> --
>> James C Dunlop                       Ph.: (631) 344-7781
>> Building 510A                        Cell: (631)316-8153
>> P.O. Box 5000                      Fax: (631) 344-4206
>> Brookhaven National Laboratory
>> Upton, NY 11973
>> dunlop AT bnl.gov
>>
>>
>>
>>
>
> --
> James C Dunlop                        Ph.: (631) 344-7781
> Building 510A                 Cell: (631)316-8153
> P.O. Box 5000                      Fax: (631) 344-4206
> Brookhaven National Laboratory
> Upton, NY 11973
> dunlop AT bnl.gov
>
>
>
>

--
James C Dunlop                  Ph.: (631) 344-7781
Building 510A                   Cell: (631)316-8153
P.O. Box 5000                      Fax: (631) 344-4206
Brookhaven National Laboratory
Upton, NY 11973
dunlop AT bnl.gov

Attachment: sPHENIX_loopers.pdf
Description: Adobe PDF document