Muon Run Quality Assessment and Data Integrity Procedure

1. Muon Global Run Quality • Purpose: • If we hope to do physics analysis we have to develop procedures for proving that the data is high quality. • Part of the Procedure • Results from December, 2001 through June 30, 2002. Tom Diehl

2. Procedure • See D0Note 3938 • Use runs query database to produce a list of runs that were taken with trigger %global%. • Verify whether or not all readout crates were part of the run. • Read muon, captain, and daq logbooks for signs of problems or fixes. Check examine plots. • Check the trigger cross section, the number of muon triggers, and the fraction of events which came from muon triggers in each run. • Check with experts from all muon subsystems. • Input from folk looking at Reco output. • Grade the Runs A-F, S. • Working on automation, of course. Tom Diehl

3. Run Grades • A or B is not applicable, yet (we haven’t reached “physics capable”). Getting closer! Recently ID’d a controls problem. • C is grade for runs with no known missing modules, high voltage problems, serious sync problems (temp.), etc … • D if not a C so long as the data determination of eff’ys using “Tight” and “Loose” muons could provide a measurement of the eff’y of all of the components of muon local tracking criteria. • E or F if there was no hope. Muon not readout. Toriod magnet off. Muon triggers removed from run or Detector Crates Missing. Not grading runs E grade anymore. • S is for special runs that are from “%global%” trigger lists. Tom Diehl

4. Results by Runs Dec/Jan Feb March April May June A+B 0 0 0 0 0 0 C 129 77 77 69 87 17 D 234 42 103 54 34 42 E+F 120 52 28 29 70 1 S x x x 11 0 0 Tom Diehl

5. What’s Missing (and Why no A or B Runs?) • It occasionally happens that something breaks in the middle of a run but data continues to be collected. • Example: hv trip, magnet failure, pulsers come on … • We need the connection between Alarms and Coor that stops data-taking when things go bad. • When things fail and cannot be reset – we end the run and start a new one. • This is how we avoid needing to grade runs at the run part level. • Also, it happens that our pipelined-buffered front ends occasionally fail in such a way that an event is read-out but the data is bad. See Dennis talk. Tom Diehl

6. Summary • The Muon Good Run lists hang off the WZ Physics Group Web page and Stefan Soldner has transferred that information to the RUNS QUALITY DATABASE. • To obtain the acceptance/efficiency you need to either stick to C-quality or measure the detector inefficiency introduced by whatever made the run a D-quality run. Same will be true for A vs. B. • We need some Event-Level Data Quality words in the Thumbnail. Tom Diehl

7. END OF TALK • Slides after this are in storage Tom Diehl

8. Bad Events • It happens that our pipelined-buffered front ends occasionally fail in such a way that the event is read-out but the data is bad. • Example: front-end is “out-of-sync” (reads out the wrong event). • We (muon, anyway) flag these in the raw data for each front-end. But we don’t collect it anywhere. • I think we should have a couple of chunks which contain warning and fatal markers summarizing data integrity for ALL of the detectors. • Maybe one bit for each subsystem? • The chunks should be in the Thumbnail. Tom Diehl

9. Run by Run Muon Triggers • Use Lum Database run reports (by Michael B.). • Bad run if s(mu1ptxaf_fz)<1.1e4 in 40+ events OR • if # muon triggers = 0 in 40+ events. I don’t know what happened to these short runs (consec.) Cal special runs w/ muon trigs prescaled Tom Diehl

10. Results #2 (by events) Dec/Jan Feb March April A+B 0 0 0 0 C x 3.4M 4.3M 2.0M D x 3.6M 7.0M 3.3M E+F x 3.5M 1.0M 0.7M This is for a large fraction of the runs to which I assigned a grade. Some runs are missing from M.B.’s lists. Tom Diehl

11. Comments on the Procedure • Logbook documentation has improved since February. • Fraction of runs for which we get Examine plots has increased. • Many %global% runs are missing from the Luminosity Database Run Reports. Tom Diehl

12. What’s Coming Up • I intend to continue to maintain this list • I intend to improve the procedures so that it continues to become easier and (hopefully) less based on expert-level information. • Suggestions welcome. Tom Diehl

13. HV Wiring Problem • Tight muons require at least one PDT/MDT hit in B or C layer. • I connected pairs of PDT B&C layer detectors to the same HV module. For example, 122 & 222. • When 122 shorts, we have to temporarily disable 122 & 222, creating a B+C hole that isn’t in the MC. Worse, we don’t measure the efficiency using A+BC segment tracks (I don’t know if one-hit scintillator B/C hits can make a segment in p11 or later Reco versions). • Such data is E/F quality. • In June shutdown we will rewire the HV on CF PDTs. Tom Diehl

14. D0 Upgrade 222 122 Tom Diehl