1 / 20

(I) MINOS Data Quality Software.

(I) MINOS Data Quality Software. Andy Blake Cambridge University Thursday December 7 th 2006. Data Quality Software. Summary of Current Data Quality Software:. Run selection . – good run lists. CandMorgue package . – “DataQualityReader” module.

daktari
Download Presentation

(I) MINOS Data Quality Software.

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. (I) MINOS Data Quality Software. Andy Blake Cambridge University Thursday December 7th 2006

  2. Data Quality Software Summary of Current Data Quality Software: • Run selection. • – good run lists. • CandMorgue package. • – “DataQualityReader” module. • – “CandDataQuality”, “CandDeadChip” candidates. • – “NtpSRDataQuality”, “NtpSRDeadChip” ntuple classes. • Detector status (HV/COIL). • – “DbuHvFromSingles”, “BfldDbiCoilState” database tables. • – “NtpSRDetStatus” ntuple class. • Spill server monitoring. • – “SpillServerMon” database table. • – “NtpSRDataQuality” ntuple class. Andy Blake, Cambridge University Data Quality Talk, slide 2

  3. Run Selection • Selection of far detector physics data. • – Run types 0x301 (physics), 0x4031 (modified physics). • – Run must contain >5 minutes data. • Data quality checks. • – Data should contain one or more “physics-like” events. • – Require complete ROP mask (all 16 crates reading out). • – Require some period of data with < 20 dead chips. • – Check for anomalous snarl or event rates. • – Keep track of CRL logs and end of week reports. • – Use feedback from physics analyses to refine run lists. • [N.B: only remove runs that are entirely bad]. • Results currently collated in doc-db #2067. • – lists of good runs compiled for Aug 1st 2003 → Aug 31st 2006. • Still working on developing and automating code. • – this would be an interesting training ground to learn about the • far detector and data, if anybody’s interested in working on this! Andy Blake, Cambridge University Data Quality Talk, slide 3

  4. Run Selection Results 2005 2006 + HV trips crate 15 out of readout (a.k.a “long weekend”) + HV trips crate 12 out of readout + HV trips crate 0 out of readout many HV trips (N.B: majority of bad runs occurred with beam off.) ALL RUNS = ALL PHYSICS SUBRUNS (run type 0x301,0x4031, >5 minutes). GOOD RUNS = GOOD PHYSICS SUBRUNS (after all data quality checks). Andy Blake, Cambridge University Data Quality Talk, slide 4

  5. CandMorgue Package • CandMorgue package contains “DataQualityReader” module which • extracts detector and data monitoring information from the raw data. • – Module runs at beginning of reconstruction chain. • – Watches raw data blocks, stores detector and data monitoring information, • and packages it up in “CandDataQualityHandles” (monitoring information • includes status of readout, Light Injection info, Spill Server info etc…). • – Produces list of “CandDeadChipHandles” detailing each bad channel • (channels might be too hot, too cold, busy, in readout error etc…). • – Assesses overall data quality for each event. • This information is copied to “NtpSRDataQuality” and “NtpSRDeadChip” • classes of SR ntuples (these classes are available in the cedar ntuples). Andy Blake, Cambridge University Data Quality Talk, slide 5

  6. SR Ntuples (I) NtpSRDataQuality NtpSRDataQuality ntuple class stores information recorded in CandDataQualityHandles. class NtpSRDataQuality : public TObject { public: Int_t trigsource; // trigger word Int_t trigtime; // trigger time Int_t errorcode; // snarl error code from RawDigitDataBlock Int_t cratemask; // number of crates enabled Int_t pretrigdigits; // number of pre-trigger digits Int_t posttrigdigits; // number of post-trigger digits Int_t snarlmultiplicity; // number of post-trigger digits in detector Int_t spillstatus; // state of SpillServer Int_t spilltype; // type of spill (real, fake etc...) Int_t spilltimeerror; // GPS error from SpillServer Int_t litrigger; // was there a nearby TMPT hit Int_t litime; // time of the TMPT hit Int_t lisubtractedtime; // (TMPT hit time) - (Trigger Time) Int_t lirelativetime; // Abs(LiSubTime) Int_t licalibpoint; // Current LI point Int_t licalibtype; // type of LI Int_t libox; // pulser box number Int_t liled; // LED number Int_t lipulseheight; // pulse height Int_t lipulsewidth; // pulse width Int_t coldchips; // number of cold chips Int_t hotchips; // number of hot chips Int_t busychips; // number of busy chips Int_t readouterrors; // number of readout errors from RawDigits Int_t dataqualityword; // overall quality (CandDataQuality::EDataQuality) ClassDef(NtpSRDataQuality,1)}; Trigger Info Raw Digits Spill Info LI Info Readout Info Andy Blake, Cambridge University Data Quality Talk, slide 6

  7. SR Ntuples (II) NtpSRDeadChip NtpSRDeadChip class stores information recorded in CandDeadChipHandles. class NtpSRDeadChip : public TObject { public: Int_t channelid; // Channel ID // FarDet: 108*crate+36*varc+6*vmm+3*vaadc+vachip // NearDet: 2560*crate+128*master+16*minder+menu Int_t plane0; // 1st associated plane Int_t plane1; // 2nd associated plane Int_t shield; // veto shield plane (Far Detector) Int_t errorcode; // Error Code Int_t status; // Status (CandDeadChip::EChipStatus) ClassDef(NtpSRDeadChip,1)}; Channel ID Plane Number Error Code Problem Andy Blake, Cambridge University Data Quality Talk, slide 7

  8. HV Status • DcsUser package contains “DbuHvFromSingles” table definition • and “HvStatusFinder” tool to store and look up the HV status. • – Summaries of TpSinglesSummaryBlocks contained in raw data. • – Filled using FillHvFromSingles module (CandMorgue package). • Each database entry contains: • – Supermodule. • – Number of cold chips. • – High Voltage status. • Table currently filled for Far Detector up to 1st September 2006. • HV status is also stored in “NtpSRDetStatus” branch of SR ntuples, • or can be inferred from “NtpSRDataQuality” branch of SR ntuples. Andy Blake, Cambridge University Data Quality Talk, slide 8

  9. Coil Status [A. Habig] • DcsUser package contains “BfldDbiCoilState” table definition • and “CoilTools” tool to store and look up the coil status. • – Summaries of the much larger DCS_MAG_FAR database table. • Each database entry contains: • – Supermodule. • – Coil current • – Coil status. • Table is filled automatically every night from the raw DCS table. • Coil status is also stored in “NtpSRDetStatus” branch of SR ntuples. Andy Blake, Cambridge University Data Quality Talk, slide 9

  10. Spill Server Status • SpillTiming package contains “SpillServerMon” table definition and • “SpillServerMonFinder” tool to store and look up spill server status. • – summaries of SpillServerMonitorBlocks contained in raw data. • Each database entry contains: • – Spill server status (has spill info been received?). • – Spill type (“reported spill” or “fake spill”). • – Spill times in Near and Far detector. • – GPS error (Near/Far GPS errors combined in quadrature). • – Spill window open/close times. • SpillServerMon Table currently filled up to 1st September 2006. • Important spill server info also stored in NtpSRDataQuality class. Andy Blake, Cambridge University Data Quality Talk, slide 10

  11. SR Ntuples (III) NtpSRDetStatus NtpSRDetStatus class stores information from DbuHvFromSingles and BfldDbiCoilState db tables. class NtpSRDetStatus : public TObject { public: // coilstatus is deprecated, used to be filled from BFieldCoilCurrent Short_t coilstatus; //magnetic coil status: -1(rev),0(off/unknown),1(forward) // dcscoilstatus is filled from BfldDbiCoilState, set to // ECoilStatus::kUnknown if table is unavailable for a given validity. Short_t dcscoilstatus; // mag coil status: enum'ed as DcsUser::ECoilStatus Float_t coilcurrent1; // coil current in supermodule 1 Float_t coilcurrent2; // coil current in supermodule 2 // HV status using TP singles info Short_t dbuhvstatus; // -1(unknown), 0(bad), 1(good) Int_t coldchips1; // cold chips in supermodule 1 Int_t coldchips2; // cold chips in supermodule 2 ClassDef(NtpSRDetStatus,3)}; COILSTATUS HVSTATUS Andy Blake, Cambridge University Data Quality Talk, slide 11

  12. Data Quality Software Model automation Implemented Fill DB Raw Data HWDB Future Work Database CandMorgue Spill Server Monitoring HV Status from Singles Coil Status CandDataQualityHandle CandDeadChipHandles access tools access tools access tools Reconstruction live time calculator SR Ntuples Andy Blake, Cambridge University Data Quality Talk, slide 12

  13. Summary • Substantial amount of data quality software now in place. • – CandMorgue package extracts information from raw data. • – Detector status database tables now created and filled. • – Data quality information stored in cedar ntuples. • Future Work: • – A few refinements will probably be needed as code is exercised. • – Need to develop and document run selection code. • – Need to automate much of my code. • Near detector data. • – The data quality code works okay for near detector data but often • doesn’t do much – could use input from a near detector expert. Andy Blake, Cambridge University Data Quality Talk, slide 19

  14. (II) Far Detector Performance Plots Andy Blake Cambridge University Thursday December 7th 2006

  15. (1) Snarl Rates 2004 2005 2006 Andy Blake, Cambridge University Data Quality Talk, slide 15

  16. (2) Hot Chips 2004 2005 2006 (N.B: Hot Chip = VA chip with singles >2,500 Hz) Andy Blake, Cambridge University Data Quality Talk, slide 16

  17. (3) Cold Chips 2005 2006 SM1 SM2 Andy Blake, Cambridge University Data Quality Talk, slide 17

  18. (4) GPS Timing Errors 2005 2006 Andy Blake, Cambridge University Data Quality Talk, slide 18

  19. Far Detector Live Time (I) • Calculate total live time by counting up timeframes in selected data. • – Do include: all physics data that passes run selection. • – Don’t include: any pedestal/cal-inject/special/test data • any HV/COIL trips in either super-module. • reported spill triggers with GPS error >1s. • – Note: unfortunately this calculation isn’t correlated with beam spills. Andy Blake, Cambridge University Data Quality Talk, slide 19

  20. Far Detector Live Time (II) HV trips readout, GPS error, HV trips. beam off “long weekend” May 1st 2005 Jan 1st 2006 Sep 1st 2006 shutdown Andy Blake, Cambridge University Data Quality Talk, slide 20

More Related