Run Coordinator View of Level 2

M. Tartaglia ( .html by J. Linnemann)

What did we do right?? (mostly)

• Real-time Monitors
• L2 Graphics/status reports
• COOR/TRGR STATUS reports

• Long-term Monitor
• Run Summary Ntuple (and GM trigger rates display) was THE most useful online product
  • Parsing the run summary is a silly and difficult way to do this, but hard to change run summary to make Ntuple dirctly
  • Therefore must plan ahead for what is needed
  • best luminosity is most important (automate storekeeper lum determination)
• For Run II: Bunch-by-bunch variations, monitioring, etc?
• Store Modelling could have used more effort
  • fell on Meisters or volunteers
  • luminosity load-levelling may be the future
• Simulator very good for efficiency, trigger development
  • not so good for backgrounds: need Mark and Pass data
  • rather complicated to use correctly (library releases)
  • Code releases complicated by online/offline Operating system differences
  • Downloads should be tested during scraping (ie before we lose luminosity if we fail)

What did we have trouble with (that should be done again)

• GM-server had a lot of potential but
  • under-utilized, orphan program (single maintainer)
  • neither CPU nor host link was the bottleneck
• Trigger Meister Documentation weak
• Determining actual bandwidth allocation/usage hard
  • lack of tools to determine overlaps
• More experts needed for problem-hunting after trigger changes (eg subtle L1.5 bug)
• Slow RECO turnaround on special projects
  • especially for trigger improvement studies
  • must have fast RECO feedback path for special runs
• Slow turnaround on efficiency measurements
  • especially ELE_TRK: not until after running
  • candidate for use of histogramming in L3?
• Should have at least one or two graduate students (with a stake in the outcome) apprenticed to the TCB reps in each physics group
• Automate Express-line W-Z cross section
  • never really got done
  • more in-depth analysis needed
  • will want this in Run II
• useful to have special runs which need only part of detector prepared in case of subsystem failure
• TCP Reps and Meisterdom can and should be done better!
  • Share the load and training among TCB reps: 2 reps and n grads/group
  • TCP reps should ``certify'' more than just concepts!
    • create own special run configs from templates maintained by Meister
    • be responsible for finding problems in new trigger lists
  • want a Meister whose job is to orchestrate:
    • documention of the trigger meister tools and methods
    • responsible for pre-download simulation
    • implement new lists
    • online rate tests and studies
    • monitoring, trending, documenting trigger rates
    • not be final arbiter of trigger conditions (committee? convenors?)
    • should not be a TCB rep
    • no more than 1 meister from any physics group

What was not worth doing again?

• What data did we take that will never be analyzed?
• Did we use INSPILL peds and pulsers?

New issues for Run II

• Track and Object spatial matching efficiencies
• 36 bunches to worry about