Here is the summary of the low luminosity running needs for Run 16 AuAu200:

• Two options:
  • 1x1 bunch fill, lasting ~1 hour (and overheads involved in having a dedicated fill)
  • Mis-steering at the end of a fill for ~3 hours 
• TPX, PXL, IST, SST, GMT on
  • Not critical, but on if available: BEMC and BTOF
• Magnetic field on
• Triggers:
  • |z_VPD| < 10 cm (300k events)
  • Level 2 "GMT hit", without |z_VPD| requirement
  • Other triggers that might be useful to physics to consume remaining collisions?
    • If nothing else, a minimum bias trigger without HFT detectors to accept the rest of the available DAQ bandwidth

Below are discussions of the details for the requirements of interest to specific subsystems that would use data from a dedicated low luminosity fill of the RHIC collider:

• Recap of Run 14 low luminosity running
  
  • Beams mis-steered at the end of fill 18400 (see below two plots of ZDC coincidence rate [Hz] vs. time [hours] for this fill), runs 15158046-15158049
  • ZDC coincidence rate started at ~1 kHz, but this resulted in vpdmb-10 rates of just "a few Hz", so it was raised to ~2-3 kHz (see ShiftLog note) to acquire vpdmb-10 (+ vpdmb-10-ssd) rates up to ~50-100 Hz (highest rates were at the end of the fill when mis-steering was the least)
  • Lasted ~2 hours (first half hour spent getting going), and recorded ~1.75M total events, of which ~450k were vpdmb-10 + vpdmb-10-ssd, in ~1.5 hours of acquiring useful data
  • SpaceCharge calibration of Run 14 data puts effect of SpaceCharge & GridLeak on projections to primary vertex of a few hundred microns per kHz of ZDC coincidence rate
  • 
• HFT (see Run 14 request):
  • Magnet on (magnet off too?)
  • PXL, IST, SST on
  • 300k events within |z_vertex| < 10 cm (can this number be divided by 2 now that PXL software bug is fixed?)
  • Mis-steered beams are detrimental: they cause the bulk of collision vertices to be outside the optimal |z_vertex| range for HFT tracking
    • Modestly higher collision rates are fine, so mis-steering is OK as long as statistics are accumulated within |z_vertex| < 10 cm
  • Trigger (file stream?) on |z_VPD| < 10 cm helps analyses
    • vpdmb-10 is already set up for Run 16
    • Run 14 also had vpdmb-10-ssd as SST acquired at slower rates
• TPC:
  • Magnetic field on
  • GMT on
    • It would benefit analyses to have a trigger (file stream?) using Level 2 requirement of at least one GMT module with a hit
    • The equivalent of ~500k minimum bias events is necessary to get sufficient statistics in the least-populated GMT modules
      • i.e. if a Level 2 requirement on GMT modules being hit keeps 50% of events, only 250k such triggers would be needed
      • At 2 kHz ZDC coincidence rate, the requirement should be met in ~5 minutes, so this will not be the driving factor in getting sufficient statistics
  • BEMC & TOF not critical (on if available, but not a dependency since pile-up should be absent)
  • Pile-up protected in the triggers is not necessary (pile-up should be absent)
  • Preferrentially a spread in z_vertex (to cover more of the TPC) so no |z_VPD| trigger cut
    • Mis-steered beams actually help distribute |z_vertex| to higher ranges
  • Collision (ZDC coincidence) rates preferrentially at ~1 kHz or less for SpaceCharge minimization (the Run 2014 low luminosity dataset was taken in the range 2 kHz - 3 kHz and may have had some SpaceCharge)
    • Could be achieved through mis-steering
• Collision rate considerations:
  • Without beam steering changes, the ZDC coincidence rate appears to fall off something like 20-25% per hour in Run 16
    • Expect only a factor of ~x2 change in maximum collision rate over the course of ~2 hours
  • Collision rates in Run 16 seem to peak near ~100 kHz without mis-steering, so it's fair to approximate the "per bunch" rate at ~1 kHz
    • e.g. A dedicated fill of 6x6 bunches would give ~6 kHz, while 3x3 bunches would give ~3 kHz, etc.
  • Collision rates at the end of ~8 hour fills are still ~40 kHz, so mis-steering at the end of a fill would need to drop the collision rate by ~x40 to get 1 kHz at the end of a fill, or by ~x20 to get 2 kHz
  • Because HFT statistics requirements are the event count driver, we want to maximize small |z_vertex| collision rates, which means minimize mis-steering
    • What fraction of collisions satisfy |z_VPD| < 10 cm as a function of mis-steering?
      • Rough numbers: perhaps 25% satisfy this for head-on beams, 15% for mis-steering enough to drop collision rate by x2
      • Run 14 finding: mis-steering to drop collision rate by ~ x14 (35 kHz -> 2.5 kHz) yielded ~50 Hz of vpdmb-10 triggers, which is 2% satisfying |z_VPD| < 10 if we assume the VPD coincidence to be 100% efficient
  • Options:
    • Optimal situation for minimizing a dedicated fill's length is to run the collider with 1x1 bunch, no mis-steering
      • Fill would start at ~1 kHz, and vpdmb-10 acquiring ~250 Hz (~25% satisfy the trigger)
      • With stochastic cooling, the collision rate would not see much change (would actually increase a little) within an hour
      • After ~1 hour, and realistically ~45 minutes of useful data acquisition, we would have over 600k vpdmb-10 events
      • Is there any benefit to anyone to run with more bunches, requiring us to keep the fill longer?
    • A dedicated fill of 6x6 bunches (if that's the easiest for the collider) actually takes longer and will have more SpaceCharge in the TPC
      • Mis-steer down to ~2 kHz ZDC coincidence rate, and would perhaps have ~100-200 Hz of vpdmb-10 (~5-10% satisfy the trigger)
      • After ~1.5 hours, and realistically ~70  minutes of useful data acquisition, we would have ~400-800k vpdmb-10 events
    • Using mis-steering at the end of a fill would avoid overheads/inefficiencies of running a dedicated fill, but will suffer more in acquisition rate to maintain low ZDC coincidence rates
      • Mis-steer from ~40 kHz ZDC coincidence down to ~2 kHz, and vpdmb-10 acquiring ~20 Hz (~1% satisfy)
      • After ~3 hours (adjusting steering to keep ~2 kHz), vpdmb-10 might be acquiring ~100 Hz 
      • After ~3 hours, and realistically ~135 minutes of useful data acquisition, we would have ~500k vpdmb-10 events

-Gene