- genevb's home page
- Posts
- 2024
- 2023
- 2022
- September (1)
- 2021
- 2020
- 2019
- 2018
- 2017
- December (1)
- October (3)
- September (1)
- August (1)
- July (2)
- June (2)
- April (2)
- March (2)
- February (1)
- 2016
- November (2)
- September (1)
- August (2)
- July (1)
- June (2)
- May (2)
- April (1)
- March (5)
- February (2)
- January (1)
- 2015
- December (1)
- October (1)
- September (2)
- June (1)
- May (2)
- April (2)
- March (3)
- February (1)
- January (3)
- 2014
- 2013
- 2012
- 2011
- January (3)
- 2010
- February (4)
- 2009
- 2008
- 2005
- October (1)
- My blog
- Post new blog entry
- All blogs
Initial SpaceCharge for Run 24 pp200
Updated on Wed, 2024-05-01 09:12. Originally created by genevb on 2024-04-30 23:31.
I processed data from these runs during the early days of acquiring pp200 data, while it was still considered low luminosity, using this chain:
"pp2024a,StiCA,BEmcChkStat,QAalltrigs,-hitfilt,-evout,SCScalerCal"
I highlighted a few runs in red and blue because beam conditions were notably different for those runs while the collider had auto-leveling implemented, as can be seen in this plot of bbcx vs. time for fill 34388 with those runs highlighted by color:
Sidenotes: The blue runs had very limited total statistics, so they used a smaller input sample of tracks for measuring SpaceCharge than the other runs (~400-600 vs. 1500). The red run had very few valid vertices and required processing a much larger number of events in order to obtain the desired track statistics (~26k vs. ~600-1400).
The expectation at this time of low luminosity in particular is that the SpaceCharge should vary rather linearly with bbcx (note that zdcx varies rather linearly with bbcx in this data, so the same could be said of zdcx). Here are plots of the measured SpaceCharge (sc) vs. bbcx on the left, and then sc/bbcx versus the index of the above runs (1-13) on the right:
If SpaceCharge truly were linear with bbcx, then the right plot above should be flat representing a constant ratio. Both plots demonstrate the non-linearity, but the right plot shows more clearly that the first 4 runs of fill 34388 are truly much different from the other runs, with much higher measured SpaceCharge than their bbcx rates alone would predict.
Running the calibration macro gives this fit result for SpaceCharge when telling it to use the scaler combination bbcx:bbcyb:bbcbb :
... alternatively written as:
Sidenotes: The highlight colors were chosen to match the colors Akio used for these three RICH scalers at the 2024-04-30 ops meeting. The origin of the offset is unknown, but may be related to TPC misalignment and/or static distortions.
This is essentially saying that what we interpret as SpaceCharge (via sDCA measurements) appears to have greater sensitivity to contributions from the beam backgrounds than from collisions! More poignantly, it is telling us that the SpaceCharge model we use for this data is unlikely to be correct as backgrounds are unlikely to induce the same distribution shape of ions in the TPC as collisions. And those backgrounds appear to contribute proportionally most when the collider has/had auto-leveling turned on.
Referring to this formula as "bbcFit", here are plots of the measured SpaceCharge (sc) vs. bbcFit on the left, and then sc/bbcFit versus the index of the above runs (1-13) on the right, now showing a much more linear correlation, with what was the worst outlier in the plots above (the red point) becoming a typical point in the plots below:
Under the assumption that the bbcx component of the SpaceCharge fit above is "good", and the bbcyb & bbcbb components of the fit are "bad" in the sense that we are probably misinterpreting and therefore inappropriately correcting for them, I will try to make an estimate of an appropriate allowable limit on those components.
Additionally, I will work with the assumption that we want sDCA accuracy of ~1 mm to get good physics. Roughly speaking, with GridLeak being negligible these days, the ratio is approximately:
1 mm sDCA ≈ 0.002 C/ε0 of SpaceCharge
That would suggest we might put a limit at a contribution of 0.002 to measured SpaceCharge from these backgrounds:
However, I think it is fair to say that even if the model for correcting SpaceCharge from these contributions is wrong, it is probably in the right direction as all SpaceCharge is generally going to introduce positive charge distributed somewhere in the TPC volume, generating electric fields that point inwards. So some margin for being wrong is allowable, perhaps close to a factor of x3 (I realize that this is some significant hand-waving at this point, but it's just meant to be a guideline estimate anyhow). So I stipulate that under the current beam conditions, we want to maintain something like:
bbcbgnd = bbcbb + 1.7 * bbcyb < 200 kHz
Here is a plot of this quantity for runs taken since day 120 (fill 34383) as of this posting, versus day = (t-1703995200)/(24*3600) for unix timestamp t, with runs that concern me highlighted in red. These are the beginning of run 25120001, plus much of 25121058. Note that run 25122009 was close to, but under this limit.
-Gene
Setup
I processed data from these runs during the early days of acquiring pp200 data, while it was still considered low luminosity, using this chain:
"pp2024a,StiCA,BEmcChkStat,QAalltrigs,-hitfilt,-evout,SCScalerCal"
| fill | run |
|---|---|
| 34373 | 25118031 |
| 34383 | 25120001 |
| 25120002 | |
| 25120005 | |
| 25120007 | |
| 25120009 | |
| 34388 | 25121001 |
| 25121002 | |
| 25121003 | |
| 25121004 | |
| 25121007 | |
| 25121016 | |
| 25121030 |
I highlighted a few runs in red and blue because beam conditions were notably different for those runs while the collider had auto-leveling implemented, as can be seen in this plot of bbcx vs. time for fill 34388 with those runs highlighted by color:
Sidenotes: The blue runs had very limited total statistics, so they used a smaller input sample of tracks for measuring SpaceCharge than the other runs (~400-600 vs. 1500). The red run had very few valid vertices and required processing a much larger number of events in order to obtain the desired track statistics (~26k vs. ~600-1400).
Evaluation of Measured SpaceCharge
The expectation at this time of low luminosity in particular is that the SpaceCharge should vary rather linearly with bbcx (note that zdcx varies rather linearly with bbcx in this data, so the same could be said of zdcx). Here are plots of the measured SpaceCharge (sc) vs. bbcx on the left, and then sc/bbcx versus the index of the above runs (1-13) on the right:
If SpaceCharge truly were linear with bbcx, then the right plot above should be flat representing a constant ratio. Both plots demonstrate the non-linearity, but the right plot shows more clearly that the first 4 runs of fill 34388 are truly much different from the other runs, with much higher measured SpaceCharge than their bbcx rates alone would predict.
Running the calibration macro gives this fit result for SpaceCharge when telling it to use the scaler combination bbcx:bbcyb:bbcbb :
sc = (1.0 +/- 0.08357)*(1.53e-08*(bbcx-(3.61e+04 +/- 1.978e+04))+(5.326e-08*(bbcyb))+(3.142e-08*(bbcbb)))
with GL = 0.50 +/- 0.00
... alternatively written as:
sc = -5.52e-04 + 1.53e-08 * bbcx + 5.326e-08 * bbcyb + 3.142e-08 * bbcbb
Sidenotes: The highlight colors were chosen to match the colors Akio used for these three RICH scalers at the 2024-04-30 ops meeting. The origin of the offset is unknown, but may be related to TPC misalignment and/or static distortions.
This is essentially saying that what we interpret as SpaceCharge (via sDCA measurements) appears to have greater sensitivity to contributions from the beam backgrounds than from collisions! More poignantly, it is telling us that the SpaceCharge model we use for this data is unlikely to be correct as backgrounds are unlikely to induce the same distribution shape of ions in the TPC as collisions. And those backgrounds appear to contribute proportionally most when the collider has/had auto-leveling turned on.
Referring to this formula as "bbcFit", here are plots of the measured SpaceCharge (sc) vs. bbcFit on the left, and then sc/bbcFit versus the index of the above runs (1-13) on the right, now showing a much more linear correlation, with what was the worst outlier in the plots above (the red point) becoming a typical point in the plots below:
Estimating an appropriate limit
Under the assumption that the bbcx component of the SpaceCharge fit above is "good", and the bbcyb & bbcbb components of the fit are "bad" in the sense that we are probably misinterpreting and therefore inappropriately correcting for them, I will try to make an estimate of an appropriate allowable limit on those components.
Additionally, I will work with the assumption that we want sDCA accuracy of ~1 mm to get good physics. Roughly speaking, with GridLeak being negligible these days, the ratio is approximately:
1 mm sDCA ≈ 0.002 C/ε0 of SpaceCharge
That would suggest we might put a limit at a contribution of 0.002 to measured SpaceCharge from these backgrounds:
SCbgnd = 5.326e-08 * bbcyb + 3.142e-08 * bbcbb
SCbgnd < 0.002
... or ...
bbcbgnd = bbcbb + 1.7 * bbcyb < 6.3e4 Hz
... or ...
bbcbgnd = bbcbb + 1.7 * bbcyb < 6.3e4 Hz
However, I think it is fair to say that even if the model for correcting SpaceCharge from these contributions is wrong, it is probably in the right direction as all SpaceCharge is generally going to introduce positive charge distributed somewhere in the TPC volume, generating electric fields that point inwards. So some margin for being wrong is allowable, perhaps close to a factor of x3 (I realize that this is some significant hand-waving at this point, but it's just meant to be a guideline estimate anyhow). So I stipulate that under the current beam conditions, we want to maintain something like:
bbcbgnd = bbcbb + 1.7 * bbcyb < 200 kHz
Here is a plot of this quantity for runs taken since day 120 (fill 34383) as of this posting, versus day = (t-1703995200)/(24*3600) for unix timestamp t, with runs that concern me highlighted in red. These are the beginning of run 25120001, plus much of 25121058. Note that run 25122009 was close to, but under this limit.
-Gene
»
- genevb's blog
- Login or register to post comments