mass^2 splitting issue in Run 19 19.6 GeV
Updated on Mon, 2020-09-28 14:37. Originally created by genevb on 2020-09-25 12:31.
The following is a list of possible topics to explore. Each topic is followed by a brief explanation of whether there is evidence that proves that topic not to be at fault. Topics are bright red if not fully answered, and dark red if believed to be answered.
-Gene
Possible cause topics:
- Issues in the new BTOF calibration
Zaochen sees the mass^2 splitting even with the old TOF calibration.
Florian see mass^2 splitting in ETOF too.
- Artifacts of dead TPC regions
Zaochen showed no phi dependence.
- Differences between the two TPC halves
Zaochen showed no notable eta dependence.
- Incorrect TPC drift velocities
Re-calibrated (there was a problem with some of the drift velocities in the database), data re-processed, mass^2 splitting did not go away. Only affected a few days anyhow and mass^2 showed no such variation.
- SpaceCharge luminosity dependence incorrect
Zaochen showed no luminosity dependence.
- SpaceCharge offset incorrect
Tried multiple values with no noticeable impact.
- SpaceCharge calibration not optimal for all runs
This is probably what we see in the day-by-day variations in <sDCA>, but the mass^2 observation has no such variation.
- Tracking codes for iTPC in library SL20c
Yuri demonstrated that (notably different) TFG tracking in .DEV2 shows the mass^2 splitting.
- Anything else in reconstruction in library SL20c
Zaochen looked at the ongoing Run 17 data production and it was fine.
- Mid-fill beta squeeze of the RHIC beams
Wasn't performed for Run 19 19.6 GeV data.
- VPD Vz cut in TPC alignment calibration
Changed, re-did the alignment, and did not resolve the issue.
- Problem with the reconstruction of iTPC hits specifically (as opposed to the old inner TPC)
Production samples without iTPC hits using (1) the alignment that was in place for Run 18, and (2) a more current Run 19 alignment, demonstrated that the new alignment specifically causes the mass^2 splitting (applying the Run 18 alignment reveals no splitting).
- Event-by-event fluctuations ... in anything (very short time scales that get averaged out over a run or day)
The fact that the mass^2 splitting went away with anything (e.g. the Run 18 alignment, outer-TPC-only test) shows this isn't the issue.
- TPC padrow 40 static field correction could be wrong somehow
The correction itself should be nowhere near large enough to cause this distortion, but it should be checked. Would have to be only that part of the correction affecting the inner TPC as the mass^2 splitting did go away when using the padrow 40 correction with the old Run 18 alignment when turning off the iTPC.
- Long bunches in the collider lead to early or late collisions that shift the TPC hits
Slightly wrong tracks could be contributing to poor BTOF timing resolution smearing, but no understanding of why it would bias mass^2 (unless it goes preferentially one way with respect to the T0 we're using?). The effect has been corrected for FXT in BES-II, but has yet to be addressed in beam-beam collisions.
- TPC supersector transverse alignment degeneracies
Track-by-track comparison of pT between 2018 and 2019 versions of the supersector alignment keeping longitudinal alignment unchanged show only small impacts.
- TPC supersector longitudinal alignment degeneracies
Track-by-track comparison of pT between 2018 and 2019 versions of the supersector alignment keeping transverse alignment unchanged show that this is responsible for the mass^2 splitting that we see!!! (see details below in the observations section)
Other observations
- No notable pathlength difference seen between positive and negative tracks for BTOF implies that the issue is incorrect TPC momentum.
- The amount of mass^2 splitting points to a pT distortion at the level of Δ(pT)/pT ≈ 0.02 * q * pT (i.e. ±2% per GeV/c of pT). This is much larger than the SpaceCharge distortion corrections we are applying for this data, and larger than the h-/h+ issues we wrestled with a decade ago (coefficient then was ~0.008).
- Using Yuri's Run 20 alignment parameters (that seem to work without mass^2 splitting in express production) did not resolve the issue, implying not a complete set of alignment parameters in offline (or codes, but codes may be ruled out by Yuri's SL20c vs. .DEV2 comparison).
- Increasing the nHitsFit cut from 15 to 25 or 35 does not improve the mass^2 splitting nor the BTOF timing resolution.
- When using only the outer TPC, the BTOF timing resolution is a little better than with both iTPC and outTPC, which means including the iTPC makes the momentum resolution worse instead of better.
- The mass^2 splitting does not show up in the express production of Run 20 9.2GeV, but the BTOF timing resolution is still much worse than expected. This could mean that the momentum resolution is still not good even if the mass^2 splitting issue is resolved.
- Looking at pT impacts (shifts) using a track-by-track analysis shows the following about the differences between the TPC supersector alignments used in Run 18 vs. the Run 19 versions:
-Gene
Possible cause topics:
- Issues in the new BTOF calibration
Zaochen sees the mass^2 splitting even with the old TOF calibration.
Florian see mass^2 splitting in ETOF too.
- Artifacts of dead TPC regions
Zaochen showed no phi dependence.
- Differences between the two TPC halves
Zaochen showed no notable eta dependence.
- Incorrect TPC drift velocities
Re-calibrated (there was a problem with some of the drift velocities in the database), data re-processed, mass^2 splitting did not go away. Only affected a few days anyhow and mass^2 showed no such variation.
- SpaceCharge luminosity dependence incorrect
Zaochen showed no luminosity dependence.
- SpaceCharge offset incorrect
Tried multiple values with no noticeable impact.
- SpaceCharge calibration not optimal for all runs
This is probably what we see in the day-by-day variations in <sDCA>, but the mass^2 observation has no such variation.
- Tracking codes for iTPC in library SL20c
Yuri demonstrated that (notably different) TFG tracking in .DEV2 shows the mass^2 splitting.
- Anything else in reconstruction in library SL20c
Zaochen looked at the ongoing Run 17 data production and it was fine.
- Mid-fill beta squeeze of the RHIC beams
Wasn't performed for Run 19 19.6 GeV data.
- VPD Vz cut in TPC alignment calibration
Changed, re-did the alignment, and did not resolve the issue.
- Problem with the reconstruction of iTPC hits specifically (as opposed to the old inner TPC)
Production samples without iTPC hits using (1) the alignment that was in place for Run 18, and (2) a more current Run 19 alignment, demonstrated that the new alignment specifically causes the mass^2 splitting (applying the Run 18 alignment reveals no splitting).
- Event-by-event fluctuations ... in anything (very short time scales that get averaged out over a run or day)
The fact that the mass^2 splitting went away with anything (e.g. the Run 18 alignment, outer-TPC-only test) shows this isn't the issue.
- TPC padrow 40 static field correction could be wrong somehow
The correction itself should be nowhere near large enough to cause this distortion, but it should be checked. Would have to be only that part of the correction affecting the inner TPC as the mass^2 splitting did go away when using the padrow 40 correction with the old Run 18 alignment when turning off the iTPC.
- Long bunches in the collider lead to early or late collisions that shift the TPC hits
Slightly wrong tracks could be contributing to poor BTOF timing resolution smearing, but no understanding of why it would bias mass^2 (unless it goes preferentially one way with respect to the T0 we're using?). The effect has been corrected for FXT in BES-II, but has yet to be addressed in beam-beam collisions.
- TPC supersector transverse alignment degeneracies
Track-by-track comparison of pT between 2018 and 2019 versions of the supersector alignment keeping longitudinal alignment unchanged show only small impacts.
- TPC supersector longitudinal alignment degeneracies
Track-by-track comparison of pT between 2018 and 2019 versions of the supersector alignment keeping transverse alignment unchanged show that this is responsible for the mass^2 splitting that we see!!! (see details below in the observations section)
Other observations
- No notable pathlength difference seen between positive and negative tracks for BTOF implies that the issue is incorrect TPC momentum.
- The amount of mass^2 splitting points to a pT distortion at the level of Δ(pT)/pT ≈ 0.02 * q * pT (i.e. ±2% per GeV/c of pT). This is much larger than the SpaceCharge distortion corrections we are applying for this data, and larger than the h-/h+ issues we wrestled with a decade ago (coefficient then was ~0.008).
- Using Yuri's Run 20 alignment parameters (that seem to work without mass^2 splitting in express production) did not resolve the issue, implying not a complete set of alignment parameters in offline (or codes, but codes may be ruled out by Yuri's SL20c vs. .DEV2 comparison).
- Increasing the nHitsFit cut from 15 to 25 or 35 does not improve the mass^2 splitting nor the BTOF timing resolution.
- When using only the outer TPC, the BTOF timing resolution is a little better than with both iTPC and outTPC, which means including the iTPC makes the momentum resolution worse instead of better.
- The mass^2 splitting does not show up in the express production of Run 20 9.2GeV, but the BTOF timing resolution is still much worse than expected. This could mean that the momentum resolution is still not good even if the mass^2 splitting issue is resolved.
- Looking at pT impacts (shifts) using a track-by-track analysis shows the following about the differences between the TPC supersector alignments used in Run 18 vs. the Run 19 versions:
- All TPC sectors have been rotated about the z axis ("gamma") by ~2 mrad (1.8±0.6). Without an external detector to use as a reference (e.g. the still-not-used GMT) it is difficult to tell the difference between such a rotation and transverse translations because tracks are predominantly radial in nature, so there are compensating shifts in the local x (along the pad row) and local y (radially inward/outward) directions of 0.064±0.065 cm and 0.17±0.07 cm respectively. It is not possible that all sectors got rotated and displaced so systematically during the iTPC installation, so it cannot be the case that both alignments are correct. However, these transverse rotations and displacements are not responsible for the large pT shits anyhow.
- All TPC sectors have been shifted in the z direction. There is a clear difference in the shifts between the east and west TPC sides with 0.48±0.03 cm and 0.40±0.03 cm respectively. These z displacements are what make the big difference in pT and mass^2 splitting when switching between the two alignments! It is very unlikely that the sectors are this much out of their intended position in z.
- Shifting the sectors in the z direction is degenerate with shifting the timing (T0) for the sectors (there are a few T0s that could be shifted)...with the notable exception that the z position of the sectors' gating grids can distort the electric field in the TPC. The correction for this distortion is usually small, but when the sectors are shifted by this much (nearly half a centimeter), the correction becomes large, of the order Δ(pT)/pT ≈ 0.06 * q * pT.
»
- genevb's blog
- Login or register to post comments