SELECTING GOOD PHYSICS DATA' - PowerPoint PPT Presentation

1 / 19
About This Presentation
Title:

SELECTING GOOD PHYSICS DATA'

Description:

(i) total number of snarls or timeframes is sometimes a 'round' number. ... (i) There is very good agreement between the Cambridge and Fermilab run lists! ... – PowerPoint PPT presentation

Number of Views:53
Avg rating:3.0/5.0
Slides: 20
Provided by: Bla75
Category:

less

Transcript and Presenter's Notes

Title: SELECTING GOOD PHYSICS DATA'


1
SELECTING GOOD PHYSICS DATA.
Andy Blake Cambridge University Wednesday
February 8th 2006
2
Far Detector Run Selection
Run selection for atmospheric neutrino analysis
OFFLINE DATABASE
Fill in the gaps in DBU subrun summary table!
BEAM MONITORING SPILLTIMEND BEAMMONSPILL
RUN SUMMARIES DBUSUBRUNSUMMARY
Select physics runs. Remove data where beam
cannot be vetoed.
Data quality checks (raw data blocks and cosmic
muons) Select good runs!
LOW LEVEL PROCESSING DATA QUALITY CHECKS
RUN SELECTION
Andy Blake
Cambridge University
3
Run Types
  • Physics Data.
  • Select physics (0x301) and normal data
    (0x02) runs of gt5 minutes.
  • Generally suspicious of the short runs.
  • (i) total number of snarls or
    timeframes is sometimes a round number.
  • (ii) short runs are often used to test
    new DAQ software or components.
  • (iii) all test data before May 2004
    just labelled as normal data.
  • Modified Physics Data (0x4301).
  • Approx. 1500 runs have this bit set
    (several weeks live time).
  • Corresponds to data where run
    configuration has been changed.
  • (E4 trigger tests, LI configuration,
    swapped HV cards, or no change at all)
  • Its generally okay to use modified runs
    for physics analysis,
  • just use the other data quality checks to
    reject the bad data.

Andy Blake
Cambridge University
4
Aside the DBU database table
  • The DBUSUBRUNSUMMARY table contains several
    gaps!
  • 1200 runs have no entry at all in the database!
  • most are bad runs (e.g. the DAQ crashed
    before the run started)
  • but a significant number do correspond to
    good physics data.
  • almost all the gaps occur before 2005 so no
    beam data is affected.
  • 100 subruns can be recovered by searching for
    gaps.
  • Gap in middle of run
  • subrun 0 1 2 GAP 4 5 6 7
  • Gap at end of run
  • subrun 0 1 2 3 4 5 6 GAP
  • 300 subruns are on the Fermilab list but not in
    the database.

Andy Blake
Cambridge University
5
Beam Monitoring
  • Require Near Detector clock or Beam Monitoring
    to be up in
  • order to veto beam spills (or alternatively to
    tag beam spills
  • in the case of the beam analysis!)
  • Near Detector clock search for a valid
    entry in the
  • SPILLTIMEND table (N.B the Near Detector
    timing
  • system is almost always up!)
  • Beam Monitoring system search for a valid
    entry in
  • the BEAMMONSPILL table.
  • Spill Server Monitoring Block a cut on
    data with large
  • ND-FD GPS errors could also go here.
  • So far there appears to be 100 coverage of beam
    spills!

Andy Blake
Cambridge University
6
January 1st 2005 ?December 31st 2005
Beam Monitoring
Near Detector GPS clock
7
Data Quality Checks (1) Raw Data
  • Data should contain one or more physics
    events
  • correct trigger bit(s) set.
  • 10 lt digits lt 1000.
  • LI channels lt 500.
  • dead chips lt 20.
  • Data should be collected using complete ROP
    mask.
  • dead crates 0.
  • There should be no anomalous event rates.
  • require the rate of physics events to
    be less than 75 Hz.
  • These cuts have the following effects
  • removes runs where readout is incomplete
    or HV is down.

Andy Blake
Cambridge University
8
(1) Raw Data Dead VA chips
singles lt 50 Hz
August 1st 2003 ? December 31st 2005
require less than 20 dead chips
Andy Blake
Cambridge University
9
(1) Raw Data Dead VME crates
August 1st 2003 ? December 31st 2005
require all 32 half-crates to be working!
Andy Blake
Cambridge University
10
(1) Raw Data Event Rates
August 1st 2003 ? January 31st 2005
Raw Snarls
50 Hz LI Leaks
Andy Blake
Cambridge University
11
(1) Raw Data Event Rates
August 1st 2003 ? January 31st 2005
Physics Snarls
Andy Blake
Cambridge University
12
(1) Raw Data Event Rates
August 1st 2003 ? January 31st 2005
Physics Snarls
remove these runs!
require event rate less than 75 Hz
Andy Blake
Cambridge University
13
Data Quality Checks (2) Cosmic Muons
  • Data should contain one or more cosmic muon
    events
  • Hits in gt10 planes.
  • Hits in gt3 planes in each view.
  • Satisfies straight line fit (rms lt1 cm).
  • typically these events occur every 3
    seconds .
  • There should be no anomalous event rates.
  • require the rate of selected muons to be
    less than 1 Hz.
  • These cuts have the following effects
  • Select clean cosmics for Far Detector
    timing calibration.
  • Remove runs containing gross anomalies.

Andy Blake
Cambridge University
14
(2) Cosmic Muons Event Rates
August 1st 2003 ? January 31st 2005
Andy Blake
Cambridge University
15
(2) Cosmic Muons Event Rates
August 1st 2003 ? January 31st 2005
remove these runs!
require muon rate less than 1 Hz
Andy Blake
Cambridge University
16
Results (1)
2003
2004
2005
2006
RED some physics runs rejected after data
quality checks.
ALL RUNS ALL PHYSICS SUBRUNS (run type
0x02,0x301,0x4031, gt5 minutes). GOOD RUNS
GOOD PHYSICS SUBRUNS (after all data quality
checks).
Andy Blake
Cambridge University
17
Results (2)
August 1st 2003 ? December 31st 2005
The recent data looks very good!
Andy Blake
Cambridge University
18
Results (3)
Comparison of Cambridge and Fermilab run lists
  • Number of subruns during period August 1st 2003
    ? December 31st 2005

Cant see anything wrong with this data so far
84 short runs 33 bad runs 1 missing run!
99 agreement between lists!
NOTES (i) There is very good agreement
between the Cambridge and Fermilab run lists!
(ii) Most discrepancies occur before 2005 so
not much effect on beam analysis. (iii)
This does not include COIL/HV trips these must
be removed by the processing!
Andy Blake
Cambridge University
19
Conclusions
  • A detailed Far Detector run selection has been
    carried out.
  • These results could be used to fine-tune the
    current run list.
  • Remove the small number of bad runs from
    the list.
  • Hand-pick the short runs that contain
    useful data.
  • Add some of the extra runs if they are
    indeed okay!
  • Some prototype tools were used to carry out
    the run selection.
  • These could be developed for wider use
    if they seem useful!
  • Things that could be considered for next round
    of processing.
  • Remove COIL/HV trips at the timeframe
    level the Fermilab run
  • list contains many runs where part of the
    run needs to be vetoed.

Andy Blake
Cambridge University
Write a Comment
User Comments (0)
About PowerShow.com