sphenix-tracking-l AT lists.bnl.gov
Subject: sPHENIX tracking discussion
List archive
- From: Thomas K Hemmick <hemmick AT skipper.physics.sunysb.edu>
- To: sphenix-tracking-l AT lists.bnl.gov
- Subject: [Sphenix-tracking-l] Fwd: 5000 pancakes
- Date: Fri, 30 Oct 2015 12:18:21 -0400
5002...
---------- Forwarded message ----------
From: James Dunlop <dunlop AT bnl.gov>
Date: Thu, Oct 29, 2015 at 10:29 PM
Subject: Fwd: 5000 pancakes
To: Thomas K Hemmick <hemmick AT skipper.physics.sunysb.edu>
Cc: James Dunlop <dunlop AT bnl.gov>
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
>
>
>> 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
From: James Dunlop <dunlop AT bnl.gov>
Date: Thu, Oct 29, 2015 at 10:29 PM
Subject: Fwd: 5000 pancakes
To: Thomas K Hemmick <hemmick AT skipper.physics.sunysb.edu>
Cc: James Dunlop <dunlop AT bnl.gov>
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
>
>
>
> 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
>
>
>
>
>
>> 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
Attachment:
check_5000folding.pdf
Description: Adobe PDF document
-
[Sphenix-tracking-l] Fwd: 5000 pancakes,
Thomas K Hemmick, 10/30/2015
- <Possible follow-up(s)>
- [Sphenix-tracking-l] Fwd: 5000 pancakes, Thomas K Hemmick, 10/30/2015
- [Sphenix-tracking-l] Fwd: 5000 pancakes, Thomas K Hemmick, 10/30/2015
-
[Sphenix-tracking-l] Fwd: 5000 pancakes,
Thomas K Hemmick, 10/30/2015
- Re: [Sphenix-tracking-l] Fwd: 5000 pancakes, Frawley, Anthony, 10/30/2015
Archive powered by MHonArc 2.6.24.