Run 18 Calibration Datasets

 Below are the calibration dataset considerations for isobar needs in Run 18:

• EMC
  • emc-check runs once per fill (at the start)
    • For the purpose of EMC pedestals and status tables
    • 50k events
• TOF
  
  • VPD
    • Resolutions needs to be calibrated (for trigger) and confirmed to be similar for both species
• TPC
  • Laser runs
    • For the purpose of calibrating TPC drift velocities
    • Every few hours (as usual)
    • Either dedicated laser runs, or included in physics runs
    • ~5000 laser events
  • GMT inclusion in a fraction of events
    • For the purpose of understanding fluctuations in TPC SpaceCharge
    • Trigger choice is not very important, as long as it has TPX and during most physics running
    • Something around 100-200 Hz is sufficient (too much will cause dead time issues for the trigger)
  • Vernier scans
    • For the purpose of understanding backgrounds in the TPC that may be different between species
    • Once for each species under typical operating conditions
    • 4 incremental steps of collision luminosity, each step ~1 minute long and on the order of ~50k events (total = ~4 minutes)
    • TPX, BEMC, BTOF must be included
    • Minimum bias trigger with no (or wide) vertex z cut
    • You do not have access to view this node
  • Low luminosity fill IF a TPC shorted field cage ring occurs
    • Only one species needed (unimportant which)
    • Minimum bias trigger with no (or wide) vertex z cut
    • ~1M events
    • ZDC coincidence rates below 3 kHz
  • Old ALTRO thresholds run
    • For the purpose of TPC dE/dx understanding
    • Only one species needed (unimportant which)
    • ~2M events
    • Could be at the end of a fill, or any other convenient time during typical operations
  • Magnetic field flipped to A ("forward") polarity before AuAu27 data
    • For the purpose of acquiring sufficient cosmic ray data with both magnetic fields to understand alignment of new iTPC sector

-Gene

Run preparation Run VI (2006)

This page is meant to organize information about the calibration preparations and steps required for each subdetector for upcoming runs. Items with an asterisk (*) need to be completed in advance of data.

For the run in winter 2006, the plan is to take primarily pp data. This may lead to different requirements than in the past.

TPC

• * Code development for 1 Hz scalers.
• * Testing of T0/Twist code with pp data.
• * Survey alignment information into DB.
• Drift velocity from lasers into DB (automated).
• T0 calibration as soon as data starts.
• Twist calibration as soon as data starts (for each field).
• SpaceCharge and GridLeak (SpaceCharge and GridLeak Calibration How-To Guide) as soon as T0/Twist calibrated (for each field).
• Would like a field flip to identify origins of offsets in SpaceCharge vs. scalers.
• dEdx: final calibration after run ends by sampling over the whole run period, but initial calibration can be done once TPC momentum is well-calibrated (after distortion corrections).

FTPC

• HV calibration performed at start of data-taking.
• Temperatures into DB (automated)
• Rotation alignment of each FTPC done for each field (needs calibrated vertex from TPC[+SVT][+SSD]). There was concern about doing this calibration with the pp data - status???

SVT

• Steps for pp should be the same as heavy ion runs, but more data necessary.
• Self-alignment (to be completed January 2006)
• Requires well-calibrated TPC.
• Requires a few million events (a week into the run?)
• Would like field flip to discriminate between SVT/SSD alignment vs. TPC distortions.

SSD

• * Code development in progress (status???)
• Requires well-calibrated TPC.

EEMC

• EEMC initial setting & monitoring during data taking relies on prompt and fully automatic muDst EzTree production for all minias-only fast-only runs. Assume fast offline muDst exist on disk for 1 week.
• Initial settings for HV: 500k minbias fast-triggered events will give slopes necessary to adjust relative gans. Same 60 GeV E_T maximum scale as in previous years.
• Pedestals from 5k minbias events, once per fill.
• Stability of towers from one 200k minbias run per fill.
• Highly prescaled minbias and zerobias events in every run for "general monitoring" (e.g. correlated pedestal shift)
• Offline calibrations unnecessary for production (can be done on the MuDst level).
• "Basic" offline calibration from MIP response in 5M minbias fast events (taken a few weeks into the run)
• "Final" offline calibration from pi0 (or other TBD) signal requires "huge" statistics of EHT and EJP triggers to do tower-by-tower (will need the full final dataset).
• * Calibration codes exist, but are scattered. Need to be put in CVS with consistent paths and filenames.

BEMC

• * LED runs to set HV for 60 GeV E_T maximum, changed from previous years (status???).
• Online HV calibration from 300k minbias events (eta ring by eta ring) - requires "full TPC reconstruction".
• MuDsts from calibration runs feedback to run settings (status???).
• Pedestals from low multiplicity events from the event pool every 24 hours.
• Offline calibrations unnecessary for production (can be done on the MuDst level).
• "Final" offline tower-by-tower calibration from MIPs and electrons using several million events.

TOF

• upVPD upgrade (coming in March 2006) for better efficiency and start resolution
• Need TPC momentum calibrated first.
• Requires several million events, less with upVPD (wait for upVPD???)

Run preparation Run VII

There is some question as to whether certain tasks need to be done this year because the detector was not moved during the shutdown period. Omitting such tasks should be justified before skipping!

TPC

• Survey alignment information into DB (appears to be no survey data for TPC this this year)
• High stats check of laser drift velocity calibration once there's gas in the TPC: 30k laser events with and without B field.
• Check of reversed GG cable on sector 8 (lasers) once there's gas in the TPC: same laser run as above
• Drift velocity from laser runs (laser runs taken once every 3-4 hours, ~2-3k events, entire run) into DB (automated); check that it's working
• T0 calibration, new method from laser runs (same laser runs as above).
• Twist calibration as soon as data starts: ~100k events, preferrably central/high multiplicity, near start of running for each field
• SpaceCharge and GridLeak (SpaceCharge and GridLeak Calibration How-To Guide) as soon as T0/Twist calibrated: ~100k events from various luminosities, for each field.
• BBC scaler study for correlation with azimuthally asymmetric backgrounds in TPC: needs several days of generic data.
• Zerobias run with fast detectors to study short time scale fluctuations in luminosity (relevant for ionization distortions): needs a couple minutes of sequential, high rate events taken at any time.
• Need a field flip to identify origins of offsets in SpaceCharge vs. scalers as well as disentangling TPC distortions from silicon alignment.
• dEdx: final calibration after run ends by sampling over the whole run period, but initial calibration can be done once TPC momentum is well-calibrated (after distortion corrections).

FTPC

• HV calibration performed at start of data-taking (special HV runs).
• Temperatures into DB (automated)
• Rotation alignment of each FTPC done for each field (needs calibrated vertex from TPC[+SVT][+SSD]): generic collision data

SSD

• Pulser runs (for initial gains and alive status?)
• Initial alignment can be done using roughly-calibrated TPC: ~100k minbias events.
• P/N Gain-matching (any special run requirements?)
• Alignment, needs fully-calibrated TPC: 250k minbias events from one low luminosity (low TPC distortions/background/occupancy/pile-up) fill, for each field, +/-30cm vertex constraint; collision rate preferrably below 1kHz.

SVT

• Temp oscillation check with lasers: generic data once triggers are set.
• Initial alignment can be done using roughly-calibrated TPC+SSD: ~100k minbias events.
• Alignment, needs fully-calibrated TPC: 250k minbias events from one low luminosity fill (see SSD).
• End-point T0 + drift velocity, needs fully-calibrated SSD+TPC: same low luminosity runs for initial values, watched during rest of run.
• Gains: same low luminosity runs.

EEMC

• Timing scan of all crates: few hours of beam time, ~6 minb-fast runs (5 minutes each) for TCD phase of all towers crates, another 6 minbias runs for the timing of the MAPMT crates, 2 days analysis
• EEMC initial setting & monitoring during data taking: requests to process specific data will be made as needed during the run.
• Initial settings for HV: 200k minbias fast-triggered events will give slopes necessary to adjust relative gans, 2 days analysis
• Pedestals (for offline DB) from 5k minbias events, once per 5 hours
• Stability of towers from one 200k minbias-fast run per fill
• "General monitoring" (e.g. correlated pedestal shift) from highly prescaled minbias and zerobias events in every run.
• Beam background monitoring from highly prescaled EEMC-triggered events with TPC for at the beginning of each fill.
• Expect commissioning of triggers using EMC after one week of collisions
• Offline calibrations unnecessary for production (can be done on the MuDst level).
• "Basic" offline calibration from MIP response in 5M minbias fast events taken a few weeks into the run
• "Final" offline calibration from pi0 (or other TBD) signal requires "huge" statistics of EHT and EJP triggers to do tower-by-tower (still undone for previous runs).
• Calibration codes exist, but are scattered. Need to be put in CVS with consistent paths and filenames (status?)

BEMC

• Timing scan of all crates
• Online HV calibration of towers - do for outliers and new PMTs/crates; needed for EMC triggering. Needs~5 minutes of minbias fast-triggered events (eta ring by eta ring) at beginning of running (once a day for a few days) - same runs as for EEMC.
• Online HV calibration of preshower - matching slopes. Not done before, will piggyback off other datasets.
• Pedestals from low multiplicity events from the event pool every 24 hours.
• Offline calibrations unnecessary for production (can be done on the MuDst level).
• "Final" offline tower-by-tower calibration from MIPs and electrons using several million events

upVPD/TOF

• upVPD (calibration?)
• No TOF this year.

preparation Run VIII (2008)

This page is meant to organize information about the calibration preparations and steps required for each subdetector for upcoming runs.

Previous runs:

• Run preparation Run VI (2006)
• Run preparation Run VII

 

Red means that nothing has been done for this (yet), or that this needs to continue through the run.
Blue means that the data has been taken, but the calibration task is not completed yet.
Black indicates nothing (more) remaining to be done for this task.

 

TPC

• Survey alignment information into DB (appears to be no survey data for TPC this this year)
• Drift velocity from laser runs (laser runs taken once every 3-4 hours, ~2-3k events, entire run) into DB (automated); check that it's working
• T0 calibration, using vertex-matching (~500k events, preferably high multiplicity, once triggers are in place).
• Twist calibration as soon as data starts: same data
• SpaceCharge and GridLeak (SpaceCharge and GridLeak Calibration How-To Guide) as soon as T0/Twist calibrated: ~500k events from various luminosities, for each field.
• BBC scaler study for correlation with azimuthally asymmetric backgrounds in TPC: needs several days of generic data.
• Zerobias run with fast detectors to study short time scale fluctuations in luminosity (relevant for ionization distortions): needs a couple minutes of sequential, high rate events taken at any time.
• dEdx: final calibration after run ends by sampling over the whole run period, but initial calibration can be done once TPC momentum is well-calibrated (after distortion corrections).

TPX

???

FTPC

• HV calibration performed at start of data-taking (special HV runs).
• Temperatures into DB (automated)
• Rotation alignment of each FTPC done for each field (needs calibrated vertex from TPC[+SVT][+SSD]): generic collision data

EEMC

• Timing scan of all crates: few hours of beam time, ~6 fast runs (5 minutes each) for TCD phase of all towers crates
• EEMC initial setting & monitoring during data taking: requests to process specific data will be made as needed during the run.
• Initial settings for HV: 500k minbias fast-triggered events will give slopes necessary to adjust relative gans, 2 days analysis
• Pedestals (for offline DB) from 5k minbias events, once per fill
• "General monitoring" (e.g. correlated pedestal shift) from highly prescaled minbias and zerobias events in every run.
• Beam background monitoring from highly prescaled EEMC-triggered events with TPC for at the beginning of each fill.
• Expect commissioning of triggers using EMC after one week of collisions
• Offline calibrations unnecessary for production (can be done on the MuDst level).
• "Basic" offline calibration from MIP response in 5M minbias fast events taken a few weeks into the run
• "Final" offline calibration from pi0 (or other TBD) signal requires "huge" statistics of EHT and EJP triggers to do tower-by-tower.
• Calibration codes exist, but are scattered. Need to be put in CVS with consistent paths and filenames (status?)

BEMC

• Timing scan of all crates
• Online HV calibration of towers - do for outliers and new PMTs/crates; needed for EMC triggering. Needs~5 minutes of minbias fast-triggered events (eta ring by eta ring) at beginning of running (once a day for a few days) - same runs as for EEMC.
• Online HV calibration of preshower - matching slopes. (same data).
• Pedestals from low multiplicity events from the event pool every 24 hours.
• Offline calibrations unnecessary for production (can be done on the MuDst level).
• "Final" offline tower-by-tower calibration from MIPs and electrons using several million events

PMD

• Hot Cells (~100k generic events from every few days?)
• Cell-by-cell gains (same data)
• SM-by-SM gains (same data)

VPD/TOF

• T-TOT (~3M TOF-triggered events)
• T-Z (same data)

Run 12 CuAu200

Regarding the P14ia Preview Production of Run 12 CuAu200 from early 2014:

A check-list of observables and points to consider to help understand alayses' sensitivity to non-final calibrations

To unambiguously see issues due to mis-calibration of the TPC, stringent determination of triggered-event tracks is necessary. Pile-up tracks are expected to be incorrect in many ways, and they constitute a larger and larger fraction of TPC tracks as luminosity grows, so their inclusion can lead to luminosity-dependencies of what appear to be mis-calibrations but are not.

1. TPC dE/dx PID (not calibrated)
   1. differences between real data dE/dx peaks' means and width vs. nsigma provided in the MuDst
   2. variability of these differences with time
2. TPC alignment (old one used)
   1. sector-by-sector variations in charge-separated signed DCAs and momentum spectra (e.g h-/h+ pT spectra) that are time- and luminosity-independent
   2. differences in charge-separated invariant masses from expectations that are time- and luminosity-independent
   3. any momentum effects (including invariant masses) grow with momentum: delta(pT) is proprotional to q*pT^2
      1. alternatively, and perhaps more directly, delta(q/pT) effects are constant, and one could look at charge-separated 1/pT from sector-to-sector
3. TPC SpaceCharge & GridLeak (preliminary calibration)
   1. sector-by-sector variations in charge-separated DCAs and momentum spectra that are luminosity-dependent
   2. possible track splitting between TPC pad rows 13 and 14 + possible track splitting at z=0, in the radial and/or azimuthal direction
   3. differences in charge-separated invariant masses from expectations that are luminosity-dependent
   4. any momentum effects (including invariant masses) grow with momentum: delta(pT) is proprotional to q*pT^2
      1. alternatively, and perhaps more directly, delta(q/pT) effects are constant, and one could look at charge-separated 1/pT from sector-to-sector
4. TPC T0 & drift velocities (preliminary calibration)
   1. track splitting at z=0, in the z direction
   2. splitting of primary vertices into two close vertices (and subsequent irregularities in primary track event-wise distributions)
5. TOF PID (VPD not calibrated, BTOF calibration from Run 12 UU used)
   [particularly difficult to disentangle from TPC calibration issues]
   1. not expected to be much of an issue, as the "startless" mode of using BTOF was forced (no VPD) and the calibration used for BTOF is expected to be reasonable
   2. broadening of, and differences in mass^2 peak positions from expectations are more likely due to TPC issues (particularly if charge-dependent, as BTOF mis-calibrations should see no charge sign dependence)
   3. while TOF results may not be the best place to identify TPC issues, it is worth noting that BTOF-matching is beneficial to removing pile-up tracks from studies

Intrinsic resolution in a tracking element

Foreword: This has probably been worked out in a textbook somewhere, but I wanted to write it down for my own sake. This is a re-write (hopefully more clear, with slightly better notation) of Appendix A of my PhD thesis (I don't think it was well-written there)...

-Gene

_______________________

Let's establish a few quantities:

• E_intr : error on the measurement by the element in question
  
  • σ_intr² = <E_intr²> : intrinsic resolution of the element, and its relation to an ensemble of errors in measurement
• E_proj : error on the track projection to that element (excluding the element from the track fit)
  • σ_proj² = <E_proj²> : resolution of the track projection to an element, and its relation to an ensemble of errors in track projections
• E_track : error on track fit at an element including the element in the fit
• R_incl = E_intr - E_track : residual difference between the measurement and the inclusive track fit
  • σ_incl² = <(E_intr - E_track)²> : resolution from the inclusive residuals
• R_excl = E_intr - E_proj : residual difference between the measurement and the exclusive track fit
  
  • σ_excl² = <(E_intr - E_proj)²> : resolution from the exclusive residuals

Let us further assume that the projection from the track fit excluding the element E_proj is uncorrelated with the intrinsic error of the measurement from the element: <E_proj E_intr> = 0. This implies that we can write:


Our goal is to determine σ_intr given that we can only observe σ_incl and σ_excl.

To that end, we utilize a guess, σ'_intr, and write down a reasonable estimation of E_track using a weighted average of E_intr and E_proj, where the weights are w_proj = 1/σ_proj², and w_intr = 1/σ'_intr²:


Substituing this, we find...


Dropping terms of <E_intr E_proj>, replacing terms of <E_proj²> and <E_intr²> with σ_proj² and σ_intr² respectively, and multiplying through such that all terms on the right-hand-side of the equation have the denominator (σ'_intr² + σ_proj²)², we find


We can substitute for σ_proj² using σ_excl² = σ_intr² + σ_proj²:


And solving for σ_intr² we find:


This is an estimator of σ_intr. Ideally, σ_intr and σ'_intr should be the same. One can iterate a few times starting with a good guess for σ'_intr and then replacing it in later iterations with the σ_intr found from the previous iteration until the two are approximately equal.

_______

-Gene

SVT Self-Alignment

Using tracks fit with SVT points plus a primary vertex alone, we can self-align the SVT using residuals to the fits. This document explains how this can be done, but only works for the situation in which the SVT is already rather well aligned, and only small scale alignment calibration remains. The technique explained herein also allows for calibration of the hybrid drift velocities.

Miscellaneous TPC calibration notes

The log file for automated drift velocity calculations is at ~starreco/AutoCalib.log.

Log files for fast offline production are at /star/rcf/prodlog/dev/log/daq.

The CVS area for TPC calibration related scripts, macros, etc., is StRoot/macros/calib.

Padrow 13 and Padrow 40 static distortions

These two distortion corrections focus on static non-uniformities in the electric field in the gating grid region of the TPC, radially between the inner and outer sectors. This region has an absence of gating grid wires where the subsector structures meet, allowing some bending of the equipotential lines, creating radial electric field components. In both cases, the region of distorted fields is quite localized near the endcap and only over a small radial extent, but this then distorts all drifting electrons (essentially from all drift distances equally) in that small radial region, affecting signal only for a few padrows on each side of the inner/outer boundary.

Padrow 13 Distortion
For the original TPC structure, the was simply nothing in the gap between the inner and outer sectors. More about the gap structure can be learned by looking some of the GridLeak documentation (which is different in that it is dynamic with the ionization in the TPC. This static distortion was observed in the early operation of STAR when luminosities were low, well before the GridLeak distortion was ever observed. It was modeled as an offset potential on a small strip of the TPC drift field boundary, with the offset equal to a scale factor times the gating grid voltage, where the scale factor was calibrated from fits to the data. Below are the related distortion correction maps.

Padrow 40 Distortion
With the iTPC sectors, a wall was placed at the outer edge of the new inner sectors with conductive stripes on it to express potentials primarily to suppress the GridLeak distortion. It was understood that this would modify the static distortion, and in the maps below it is apparent that the static distortions became a few times larger with the wall, but in both cases only at the level of ~100 μm or less at the outermost padrow of the inner sectors. It is also worth noting that the sign of the distortion flipped with respect to Padrow 13.

This distortion correction is determined from the sum of 3 maps that represent the distortion contributions from (1) the wall's grounded structure, (2) the potential at the wall's tip [nominally -115 V], and (3) the potential on the wall's outer side [nominally -450 V]. Plots on this page were made using the nominal potentials.

Distortion correction maps:
The maps are essentially uniform in z, so the maps shown below focus only on the radial and azimuthal dependencies. Further, there is no distortion more than a few centimeters away from the inner/outer boundaries, and there is essentially a 12-fold symmetry azimuthally (though this is not strictly true if different wall voltages are used on different iTPC sectors), so the maps zoom in on a limited region of r and φ to offer a better view of the fine details. Also, the inner and outer edges of the nearest padrows are shown as thin black lines on some plots to help understand their proximity to the distortions.

Open each map in a new web browser tab or window to see higher resolution. Units are [cm] and [radian].

	Δ(r-φ) vs. r and φ	Δ(r) vs. r and φ
Padrow 13
Padrow 13 lines indicating locations of rows 13 and 14
Padrow 40
Padrow 40 lines indicating locations of rows 40 and 41

-Gene

RunXI dE/dx calibration recipe

This is a recipe of RunXI dEdx calibration by Yi Guo.

TPC Hit Errors

• Instructions
• Calibration results
• Hit errors in zero field

TPC T0s

Global T0:

• Instructions (as of 2012, calibrated along with Twist)
• Run 10 calibration
• Run 12 calibration

Twist (ExB) Distortion

 Run 12 calibration

Time Stamps

STAR   Computing	Tutorials main page
STAR Databases: TIMESTAMP
Offline computing tutorial

 

TIMESTAMPS

There are three timestamps used in STAR databases; beginTime This is STAR user timestamp and it defines ia validity range entryTime insertion into the database deactive either a 0 or a UNIX timestamp - used for turning off a row of data EntryTime and deactive are essential for 'reproducibility' and 'stability' in production. The beginTime is the STAR user timestamp. One manifistation of this, is the time recorded by daq at the beginning of a run. It is valid unti l the the beginning of the next run. So, the end of validity is the next beginTime. In this example it the time range will contain many eve nt times which are also defined by the daq system. The beginTime can also be use in calibration/geometry to define a range of valid values. EXAMPLE: (et = entryTime) The beginTime represents a 'running' timeline that marks changes in db records w/r to daq's event timestamp. In this example, say at some tim e, et1, I put in an initial record in the db with daqtime=bt1. This data will now be used for all daqTimes later than bt1. Now, I add a second record at et2 (time I write to the db) with beginTime=bt2 > bt1. At this point the 1st record is valid from bt1 to bt2 and the second is valid for bt2 to infinity. Now I add a 3rd record on et3 with bt3 < bt1 so that   1st valid bt1-to-bt2, 2nd valid bt2-to-infinity, 3rd is valid bt3-to-bt1. Let's say that after we put in the 1st record but before we put in the second one, Lydia runs a tagged production that we'll want to 'use' fo rever. Later I want to reproduce some of this production (e.g. embedding...) but the database has changed (we've added 2nd and 3rd entries). I need to view the db as it existed prior to et2. To do this, whenever we run production, we defined a productionTimestamp at that production time, pt1 (which is in this example < et2). pt1 is passed to the StDbLib code and the code requests only data that was entered before pt1. This is how production in 'reproducible'. The mechanism also provides 'stability'. Suppose at time et2 the production was still running. Use of pt1 is a barrier to the production from 'seeing' the later db entries. Now let's assume that the 1st production is over, we have all 3 entries, and we want to run a new production. However, we decide that the 1st entry is no good and the 3rd entry should be used instead. We could delete the 1st entry so that 3rd entry is valid from bt3-to-bt2 but the n we could not reproduce the original production. So what we do is 'deactivate' the 1st entry with a timestamp, d1. And run the new production at pt2 > d1. The sql is written so that the 1st entry is ignored as long as pt2 > d1. But I can still run a production with pt1 < d1 which means the 1st entry was valid at time pt1, so it IS used. One word of caution, you should not deactivate data without training! email your request to the database expert.   In essence the API will request data as following: 'entryTime <productionTime<deactive || entryTime< productionTime & deactive==0.' To put this to use with the BFC a user must use the dbv switch. For example, a chain that includes dbv20020802 will return values from the database as if today were August 2, 2002. In other words, the switch provides a user with a snapshot of the database from the requested time (which of coarse includes valid values older than that time). This ensures the reproducability of production. If you do not specify this tag (or directly pass a prodTime to StDbLib) then you'll get the latest (non-deactivated) DB records.   Below is an example of the actual queries executed by the API:   select beginTime + 0 as mendDateTime, unix_timestamp(beginTime) as mendTime from eemcDbADCconf Where nodeID=16 AND flavor In('ofl') AND (deactive=0 OR deactive > =1068768000) AND unix_timestamp(entryTime) < =1068768000 AND beginTime > from_unixtime(1054276488) And elementID In(1) Order by beginTime limit 1 select unix_timestamp(beginTime) as bTime,eemcDbADCconf.* from eemcDbADCconf Where nodeID=16 AND flavor In('ofl') AND (deactive=0 OR deactive>=1068768000) AND unix_timestamp(entryTime) < =1068768000 AND beginTime < =from_unixtime(1054276488) AND elementID In(1) Order by beginTime desc limit 1   For a description of format see .... TimeStamp

 

Proposal for Run IV

Procedure proposal for production and QA in Year4 run

Jérôme LAURET & Lanny RAY, 2004

Summary: The qualitative increase in data volume for run 4 together with finite cpu capacity at RCF precludes the possibility for multiple reconstruction passes through the full raw data volume next year. This new computing situation together with recent experiences involving production runs which were not pre-certified prior to full scale production motivates a significant change in the data quality assurance (QA) effort in STAR. This note describes the motivation and proposed implementation plan.

Introduction

The projection for the next RHIC run (also called, Year4 run which will start by the end of 2003), indicates a factor of five increase in the number of collected events comparing to preceding runs. This will increase the required data production turn-around time by an order of magnitude, from months to one year per full-scale production run. The qualitative increase in the reconstruction demands combined with an increasingly aggressive physics analysis program will strain the available data processing resources and poses a severe challenge to STAR and the RHIC computing community for delivering STAR’s scientific results in a reasonable time scale. This situation will become more and more problematic as our Physics program evolves to include rare probes. This situation is not unexpected and was anticipated since before the inception of RCF. The STAR decadal plan (10 year projection of STAR activities and development) clearly describes the need for several upgrade phases, including a factor of 10 increase in data acquisition rate and analysis throughput by 2007.

Typically, 1.2 represents an ideal, minimal number of passes through the raw data in order to produce calibrated data summary tapes for physics analysis. However, it is noteworthy that in STAR we have typically processed the raw data an average of 3.5 times where, at each step, major improvements in the calibrations were made which enabled more accurate reconstruction, resulting in greater precision in the physics measurements. The Year 4 data sample in STAR will include the new ¾ barrel EMC data which makes it unlikely that sufficiently accurate calibrations and reconstruction can be achieved with only the ideal 1.2 number of passes as we foresee the need for additional calibration passes through the entire data in order to accumulate enough statistics to push the energy calibration to the high Pt limit.

While drastically diverging from the initial computing requirement plans ( ¹), this mode of operation, in conjunction with the expanded production time table, calls for a strengthening of procedures for calibration, production and quality assurance.

The following table summarizes the expectations for ~ 70 Million events with a mix of central and minbias triggers. Numbers of files and data storage requirements are also included for guidance

Au+Au 200 (minbias)	35 M central	35 M minbias	Total
No DAQ100 (1 pass)	329 days	152 days	481 days
No DAQ100 (2 passes)	658 days	304 days	962 days
Assuming DAQ100 (1 pass)	246 days	115 days	361 days
Assuming DAQ100 (2 passes)	493 days	230 days	723 days
Total storage estimated (raw)	x	x	203 TB
Total storage estimated (1 pass)	x	x	203 TB

Quality Assurance: Goals and proposed procedure for QA and productions

What is QA in STAR?

The goal of the QA activities in STAR is the validation of data and software, up to DST production. While QA testing can never be exhaustive, the intention is that data that pass the QA testing stage should be considered highly reliable for downstream physics analysis. In addition, QA testing should be performed soon after production of the data, so that errors and problems can be caught and fixed in a timely manner.

QA processes are run independently of the data taking and DST production. These processes contain the accumulated knowledge of the collaboration with respect to potential modes of failure of data taking and DST production, along with those physics distributions that are most sensitive to the health of the data and DST production software. The results probe the data in various ways:

• At the most basic level, the questions asked are whether the data can be read and whether all the components expected in a given dataset are present. Failures at this level are often related to problems with computing hardware and software infrastructure.

• At a more sophisticated level, distributions of physics-related quantities are examined, both as histograms and as scalar quantities extracted from the histograms and other distributions. These distributions are compared to those of previous runs that are known to be valid, and the stability of the results is monitored. If changes are observed, these must be understood in terms of changing running conditions or controlled changes in the software, otherwise an error flag should be raised (deviations are not always bad, of course, and can signal new physics: QA must be used with care in areas where there is a danger of biasing the physics results of STAR).

Varieties of QA in STAR

The focus of the QA activities until summer 2000 has been on Offline DST production for the DEV branch of the library. With the inception of data taking, the scope of QA has broadened considerably. There are in fact two different servers running autoQA processes:

• Offline QA. This autoQA-generated web page accesses QA results for all the varieties of Offline DST production:

  • Real data production produced by the Fast Offline framework. This is used to catch gross errors in data taking, online trigger and calibration, allowing for correcting the situation before too much data is accumulated (this framework also provides on the fly calibration as the data is produced).

  • Nightly tests of real and Monte Carlo data (almost always using the DEV and NEW branches of the library). This is used principally for the validation of migration of library versions

  • Large scale production of real and Monte Carlo data (almost always using the PRO branch of the library). This is used to monitor the stability of DSTs for physics.

• Online QA. This autoQA-generated web page accesses QA results for data in the Online event pool, both raw data and DST production that is run on the Online processors.

The QA dilemma

While a QA shift is usually organized during data taking, the later, official production runs were encouraged (but not mandated) to be regularly QA-ed. Typically, there has not been an organized QA effort for post-experiment DST production runs. The absence of organized quality assurance efforts following the experiment permitted several post-production problems to arise. These were eventually discovered at the (later) physics analysis stage, but the entire production run was wasted. Examples include the following:

1. missing physics quantities in the DSTs (e.g. V0, Kinks, etc ...)

2. missing detector information or collections of information due to pilot errors or code support

3. improperly calibrated and unusable data

4. ...

The net effect of such late discoveries is a drastic increase in the production cycle time, where entire production passes have to be repeated, which could have been prevented by a careful QA procedure.

Production cycles and QA procedure

To address this problem we propose the following production and QA procedure for each major production cycle.

1. A data sample (e.g. from a selected trigger setup or detector configuration) of not more than 100k events (Au+Au) or 500k events (p+p) will be produced prior to the start of the production of the entire data sample.

2. This data sample will remain available on disk for a period of two weeks or until all members of “a” QA team (as defined here) have approved the sample (whichever comes first).

3. After the two week review period, the remainder of the sample is produced with no further delays, with or without the explicit approval of everyone in the QA team.

4. Production schedules will be vigorously maintained. Missing quantities which are detected after the start of the production run do not necessarily warrant a repetition of the entire run.

5. The above policy does not apply to special or unique data samples involving calibration or reconstruction studies nor would it apply to samples having no overlaps with other selections. Such unique data samples include, for example, those containing a special trigger, magnetic field setting, beam-line constraint (fill transition), etc., which no other samples have and which, by their nature, require multiple reconstruction passes and/or special attention.

In order to carry out timely and accurate Quality Assurance evaluations during the proposed two week period, we propose the formation of a permanent and QA team consisting of:

1. One or two members per Physics Working group. This manpower will be under the responsibility of the PWG conveners. The aim of these individuals will be to rigorously check, via the autoQA system or analysis codes specific to the PWG, for the presence of the required physics quantities of interest to that PWG which are understood to be vital for the PWG’s Physics program and studies.

2. One or more detector sub-system experts from each of the major detector sub-systems in STAR. The goal of these individuals will be to ensure the presence and sanity of the data specific to that detector sub-system.

3. Within the understanding that the outcome of such procedure and QA team is a direct positive impact on the Physics capabilities of a PWG, we recommend that this QA service work be done without shift signups or shift credit as is presently being done for DAQ100 and ITTF testing.

Summary

Facing important challenges driven by the data amount and Physics needs, we proposed an organized procedure for QA and production relying on a cohesive feedback from the PWG and detector sub-system’s experts within time constraints guidelines. It is understood that the intent is clearly to bring the data readiness to the shortest possible turn around time while avoiding the need for later re-production causing waste of CPU cycles and human hours.

Summary list of STAR QA Provisions

Summary of the provisions of Quality Assurance and Quality Control for the STAR Experiment

Online QA (near real-time data from the event pool)

• Plots of hardware/electronics performance
  • Histogram generation framework and browsing tools are provided
  • Shift crew assigned to analyze
  • Plots are archived and available via web
  • Data can be re-checked
  • Yearly re-assessment of plot contents during run preparation meetings and via pre-run email request by the QA coordinator
• Visualization of data
  • Event Display (GUI running at the control room)
• DB data validity checks

FastOffline QA (full reconstruction within hours of acquisition)

• Histogram framework, browsing, reporting, and archiving tools are provided
  • QA shift crew assigned to analyze and report
  • Similar yearly re-assessment of plot contents as Online QA plots
• Data and histograms on disk for ~2 weeks and then archived to HPSS
  • Available to anyone
  • Variety of macros provided for customized studies (some available from histogram browser, e.g. integrate over runs)
• Archived reports always available
  • Report browser provided

Reconstruction Code QA

• Standardized test suite of numerous reconstruction chains in DEV library performed nightly
  • Analyzed by S&C team
  • Browser provided
  • Results kept at migration to NEW library
• Standardized histogram suite recorded at library tagging (2008+)
  • Analyzed by S&C team
  • Test suite grows with newly identified problem
  • Discussions of analysis and new issues at S&C meetings
• Test productions before full productions (overlaps with Production QA below)
  • Provided for calibration and PWG experts to analyze (intended to be a requirement of the PWGs, see Production cycles and QA procedure under Proposal for Run IV)
  • Available to anyone for a scheduled 2 weeks prior to commencing production
  • Discussions of analysis and new issues at S&C meetings

Production QA

• All aspects of FastOffline QA also provided for Production QA (same tools)
  • Data and histograms are archived together (i.e. iff data, then histograms)
  • Same yearly re-assessment of plot contents as FastOffline QA plots (same plots)
  • Formerly analyzed during runs by persons on QA shift crew (2000-2005)
  • No current assignment of shift crew to analyze (2006+)
• Visualization of data
  • Event Display: GUI, CLI, and visualization engine provided
• See "Test productions before full production" under Reconstruction Code QA above (overlaps with Production QA)
• Resulting data from productions are on disk and archived
  
  • Available to anyone (i.e. PWGs should take interest in monitoring the results)

Embedding QA

• Standardized test suite of plots of baseline gross features of data
  • Analyzed by Embedding team
• Provision for PWG specific (custom) QA analysis (2008+)

 

Run 19 (BES II) QA

Run 19 (BES 2) Quality Assurance

Run Periods

• Au+Au at 19.6GeV
• Au+Au at 14.5GeV
• Fixed Target Au+Au (√s_NN = 3.9, 4.5, and 7.7GeV)

Detector Resources

BBC	BTOF	BEMC	EPD
eTOF	GMT	iTPC/TPC	HLT
MTD	VPD	ZDC

Other Resources

• Beam Use Request for Runs 19 and 20
  • PAC Recommendation for Runs 19 and 20

QA Experts:

• BBC - Akio Ogawa
• BTOF - Zaochen Ye
• BEMC - Raghav Kunnawalkam Elayavalli
• EPD  - Rosi Reed
• eTOF - Florian Seck
• GMT - Dick Majka
• iTPC- Irakli Chakaberia
• HLT - Hongwei Ke
• MTD  - Rongrong Ma
• VPD  -  Daniel Brandenburg
• ZDC - Miroslav Simko and Lukas Kramarik
• Offline-QA - Lanny Ray  + this week's Offline-QA shift taker
• LFSUPC conveners: David Tlusty, Chi Yang, and Wangmei Zha 
  • delegate: Ben Kimelman
• BulkCorr conveners: SinIchi Esumi,  Jiangyong Jia, and Xiaofeng Luo 
  • delegate: Takafumi Niida (BulkCorr)
• PWGC - Zhenyu Ye
• TriggerBoard (and BES focus group) - Daniel Cebra
• S&C - Gene van Buren

Meeting Schedule

• Weekly on Thursdays at 2pm EST
• Blue Jeans information:

  To join the Meeting:
  https://bluejeans.com/967856029
  
  To join via Room System:
  Video Conferencing System: bjn.vc -or-199.48.152.152
  Meeting ID : 967856029
  
  To join via phone :
  1)  Dial:
  	+1.408.740.7256 (United States)
  	+1.888.240.2560 (US Toll Free)
  	+1.408.317.9253 (Alternate number)
  	(see all numbers - http://bluejeans.com/numbers)
  2)  Enter Conference ID : 967856029
  

Run 20 (BES II) QA

Run 20 (BES 2) Quality Assurance

Run Periods

• Au+Au at 11.5GeV
• Au+Au at 9.2GeV
• Fixed Target Au+Au

Detector Resources

BBC	BTOF	BEMC	EPD
eTOF	GMT	iTPC/TPC	HLT
MTD	VPD	ZDC

Other Resources

• Run-20 iTPC QA Blog (by Flemming Videbaek) 
• Beam Use Request for Runs 19 and 20
  • PAC Recommendation for Runs 19 and 20

QA Experts:

• BBC - Akio Ogawa
• BTOF - Zaochen Ye
• BEMC - Raghav Kunnawalkam Elayavalli
• EPD  - Rosi Reed
• eTOF - Florian Seck
• GMT - Dick Majka
• TPC- Irakli Chakaberia, Fleming Videbaek
• HLT - Hongwei Ke
• MTD  - Rongrong Ma
• VPD  -  Daniel Brandenburg
• ZDC - Miroslav Simko and Lukas Kramarik
• Offline-QA - Lanny Ray
• TriggerBoard - Daniel Cebra
• S&C - Gene van Buren

Period 20a/b:

• LFSUPC conveners: Wangmei Zha, Daniel Cebra, 
  • delegate: Ben Kimelman
• BulkCorr conveners: SinIchi Esumi,  Jiangyong Jia, and Xiaofeng Luo 
  • delegate: Takafumi Niida (BulkCorr)
• PWGC - Zhenyu Ye

Period 20b/c:

• PWG Delegates
  • LFSUPC: Ben Kimelman, Chenliang Jin
  • BulkCorr: Kosuke Okubo, Ashish Pandav
  • • HeavyFlavor - Kaifeng Shen, Yingjie Zhou
    • JetCorr - Tong Liu,  Isaac Mooney
    • Spin/ColdQCD : Yike Xu
• PWGC - Rongrong Ma

Meeting Schedule

• Weekly on Fridays at noon EST/EDT
• Blue Jeans information:

  Meeting URL
  https://bluejeans.com/563179247?src=join_info
  
  Meeting ID
  563 179 247
  
  Want to dial in from a phone?
  
  Dial one of the following numbers:
  +1.408.740.7256 (US (San Jose))
  +1.888.240.2560 (US Toll Free)
  +1.408.317.9253 (US (Primary, San Jose))
  +41.43.508.6463 (Switzerland (Zurich, German))
  +31.20.808.2256 (Netherlands (Amsterdam))
  +39.02.8295.0790 (Italy (Italian))
  +33.1.8626.0562 (Paris, France)
  +49.32.221.091256 (Germany (National, German))
  (see all numbers - https://www.bluejeans.com/premium-numbers)
  
  Enter the meeting ID and passcode followed by #
  
  Connecting from a room system?
  Dial: bjn.vc or 199.48.152.152 and enter your meeting ID & passcode
  

Run 21 (BES II) QA

Run 21 (BES 2) Quality Assurance

Run Period(s)

• RHIC Run Schedule
• Au+Au at 7.7GeV
• Fixed Target Au+Au

Detector Resources

BBC	BTOF	BEMC	EPD
eTOF	GMT	iTPC/TPC	HLT
MTD	VPD	ZDC

Other Resources

• Run-21 iTPC QA Blog (by Flemming Videbaek) 
• Beam Use Request for Runs 21-25
  • PAC Report, incl. recommendations for Run 21

QA Experts:

• BBC - Akio Ogawa
• BTOF - Zaochen Ye
• BEMC - Raghav Kunnawalkam Elayavalli
• EPD  - Joey Adams
• eTOF - Philipp Weidenkaff
• GMT - 
• TPC- Flemming Videbaek
• HLT - Hongwei Ke
• MTD  - Rongrong Ma
• VPD  -  Daniel Brandenburg
• ZDC - Miroslav Simko and Lukas Kramarik
• Offline-QA - Lanny Ray
• TriggerBoard - Daniel Cebra
• Production & Calibrations - Gene Van Buren

Period 21:

• PWG Delegates
  • LFSUPC: Chenliang Jin, Ben Kimelman
  • BulkCorr: Kosuke Okubo, Ashish Pandav
  • HeavyFlavor - Kaifeng Shen, Yingjie Zhou
  • JetCorr - Tong Liu,  Isaac Mooney
  • Spin/ColdQCD : Yike Xu
• PWGC - Rongrong Ma

Meeting Schedule

• Weekly on Fridays at noon EST/EDT
• Zoom information:

  Topic: STAR QA Board
  Time: This is a recurring meeting Meet anytime
  
  Join Zoom Meeting
  https://riceuniversity.zoom.us/j/95314804042?pwd=ZUtBMzNZM3kwcEU3VDlyRURkN3JxUT09
  
  Meeting ID: 953 1480 4042
  Passcode: 2021
  One tap mobile
  +13462487799,,95314804042# US (Houston)
  +12532158782,,95314804042# US (Tacoma)
  
  Dial by your location
          +1 346 248 7799 US (Houston)
          +1 253 215 8782 US (Tacoma)
          +1 669 900 6833 US (San Jose)
          +1 646 876 9923 US (New York)
          +1 301 715 8592 US (Washington D.C)
          +1 312 626 6799 US (Chicago)
  Meeting ID: 953 1480 4042
  Find your local number: https://riceuniversity.zoom.us/u/amvmEfhce
  
  Join by SIP
  95314804042@zoomcrc.com
  
  Join by H.323
  162.255.37.11 (US West)
  162.255.36.11 (US East)
  115.114.131.7 (India Mumbai)
  115.114.115.7 (India Hyderabad)
  213.19.144.110 (Amsterdam Netherlands)
  213.244.140.110 (Germany)
  103.122.166.55 (Australia)
  149.137.40.110 (Singapore)
  64.211.144.160 (Brazil)
  69.174.57.160 (Canada)
  207.226.132.110 (Japan)
  Meeting ID: 953 1480 4042
  Passcode: 2021
  

Run 22 QA

Weekly on Fridays at noon EST/EDT

Zoom information:
=========================
Topic: STAR QA board meeting

• Friday, Oct 15, 2021. 12pm BNL Time
  • Run-by-Run QA code introduction (Yu Hu)

• Friday, Oct 22, 2021. 12pm BNL Time
  • List of variables from different groups
    • Daniel: centrality
    • C​​h​​enliang: LF
    • A​​s​​h​​ish: bulk cor 
    • A​​s​​h​​ik: FC​V​
    • Kai​feng: HF
    • T​​o​​n​​g: jet cor

• Friday, Oct 29, 2021. 12pm BNL Time
  • Run-by-run QA for centrality determination in Au+Au Collisions at BES-II 19.6 GeV (First Look, Ashik)
  • Classification of Different QA Variables proposed by PWGs (Rongrong Ma)
  • Discussion

• Friday, Nov 5, 2021. 12pm BNL Time
  • Review of the bad run list for 19.6GeV (Daniel Cebra)
  • Run-by-Run QA for centrality determination in 19.6GeV (Ashik)
  • Discussion

• Friday, Nov 12, 2021. 12pm BNL Time
  • Update on 19.6GeV QA after removing injection runs (Ashik)
  • Update on 19.6GeV QA for centrality determination (Li-ke Liu)
  • Au+Au 7.7 GeV QA (Vipul Bairathi)
  • Maker for Bad Runs (Xiaoyu Liu)
  • Progress on BES-II Data QA

• Friday, Nov 19, 2021. 12pm BNL Time
  • Progress on BES-II Data QA
  • Offline QA from ColdQCD group

• Friday, Dec 3, 2021. 12pm BNL Time
  • Progress on BES-II Data QA  (Ashik)
  • Run22 Offline QA 

Run23 QA Volunteers

General TPC QA: Lanny Ray (Texas)

PWG      Volunteers
  CF        Yevheniia Khyzhniak (Ohio)
              Muhammad Ibrahim Abdulhamid Elsayed (Egypt)

  FCV     Han-Sheng Li (Purdue)
             Yicheng Feng (Purdue)
             Niseem Magdy (SBU)
              

 LFSUPC   Hongcan Li (CCNU)

    HP      Andrew Tamis (Yale)
              Ayanabha Das (CTU)
 

Run23 QA helpers