1 / 14

Muon Run Quality Assessment and Data Integrity Procedure

This procedure outlines the steps for ensuring high-quality data in muon physics analysis, including checking readout crates, verifying trigger cross-section, and consulting experts. Results from December 2001 to June 2002 are provided, along with run grades and missing runs. The talk also highlights the need for improved event-level data quality monitoring and addresses a wiring problem affecting data quality.

flynt
Download Presentation

Muon Run Quality Assessment and Data Integrity Procedure

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related