D0 Trigger Database Status

1
D0 Trigger Database Status

• Elizabeth Gallas
• Fermilab CD/D0CA
• Margherita Vittone,
• Vijay Murthi, and Steve White
• Fermilab CD/CEPA Db Software

D0 Trigger Board Meeting Friday Jan 28, 2005
2
Trigger Database

• Purpose
• Create, Modify, Store and Report
• all D0 Trigger Configurations in Run 2
• Generate configuration format xml
• for online and simulation
• Document
• TDB is the first place collaborators look to get
  an understanding of the D0 Trigger System
• Requirements
• Technical
• Generate a precise configuration for a complex
  device
• COOR document (Scott Snyder)
• D0 Trigger/Online Groups
• Interface
• Store and retrieve configuration information from
  a Database for a User.
• Functional
• Usable
• Documented

3
Trigger Database Statistics

• IN USE since December 2001
• all Global (Physics) and nearly all Special Runs
• an increasing number of Commissioning and
  Calibration configurations as functionality of
  trigger systems come online
• Contains nearly 100,000 records
• 340 Trigger Lists (3580 Triggers defined)
• single List can contain 1000s of parameters
• 236 Trigger Lists used online in gt18000 Runs
• All data is entered by people (10 certified)
• Trigger Lists are a unique combination of
  conditions which are designed individually to
  configure a complex system
• Nearly no duplicate records
• Once a trigger list element is created, other
  trigger lists can use it
• not large by database standards
• but implementation is complex, reflective of
  programmability of the D0 Trigger System.

4
Trigger Database Implementation

• D0 offline production database instance
  (d0ofprd1)
• About 40 Tables in Oracle
• About 25 Views in Oracle
• TriggerDbServer
• Like the SAM db servers a customized db server
• - interfaces using the TriggerDbServer
• Command line interfaces
• DeleteTemporaryElements.py
• CheckStatCurr.py
• CheckStatUsed.py
• clientDemo.py
• add_user.py
• rcpGen.py
• set_statUsed.py
• xmlgen.py
• GetBitNames.py
• GetRuns.py
• GetStuff3.py
• l3tooltype.py

5
TDB Status

• TDB meets some but not all of the requirements
  for its current capabilities
• The NOT ALL part wastes a considerable amount
  of expert time
• The system needs to be expanded
• D0 Trigger Steering Committee
• The system cannot be expanded until its
  deficiencies for current capabilities are
  addressed.
• Why the same expert is involved so doing so will
  exacerbate the existing problem
• We need help from CD to bring the project up to
  the design specifications
• Defined CD Project
• http//www-d0.fnal.gov/d0dist/dist/packages/trigdb
  _userweb/devel/www/TDB_Plan.html

6
Schedule for fixing/implementing Entry/Report
client and DbServer

• trigdb_status, l1dialogs
• 4 weeks
• tdb_objects, terms, L1dialogs, neoterms
• 7 weeks
• tdb_scripts, tn, tl, tldependency
• 5 weeks
• trigdb_objects, terms, scripts, triggernames,
  triggerlists
• 7 weeks
• trigdb_tltransformation (expert required)
• 4-8 weeks
• t(rig)db_L2pp
• 5 weeks
• t(rig)db_ed, dg
• 4 weeks
• TriggerDbServer
• convert from fnorb to omniorb

7
Schedule for Maintenance, Integrity and New
Functions

• Enforcing system constraints
• more checks insure correct configuration
• Performance Issues
• needed
• Machine Issues
• on order for Luminosity Database
• RunS and Trigger to move away from SAM
• Clean up program
• 2-4 weeks (implementation dependent)
• Changes to Level 1 Exposure Group Rules
• 2-4 weeks
• Level 1 Pseudoterm Implementation
• 2-4 months
• Trigger List to Release correspondence
• 4 weeks
• Run 2b Changes
• specification dependent
• Level 1 subdetector version tracking
• specification dependent

8
Who is working on what ?

• Help CD/CEPA Database Group
• Their expertise
• database,database server, python, cgi
• Margherita Vittone, Vijay Murthi
• TDB Entry/Report Interfaces
• learning TDB schema, business rules
• learning the existing implementation
• Steve White, Margherita
• Convert TriggerDbServer to omniorb
• Steve is the DB server expert
• (converted all other servers)
• Elizabeth
• Bug and data fixes, data entry
• Implementing expert features
• Testing above changes
• Certification for production

9
Summary

• Trigger DB Server
• Steve White (a few weeks)
• changes for conversion from fnorb to omniorb more
  pervasive than anticipated. Cannot cut new code
  to production until issues in server and client
  are resolved.
• Trigger DB Client(WebInterfaces)
• Margherita Vittone (part of part time)
• Vijay Murthi (lt½ time on TDB project)
• Both understand system to be tangibly
  contributing to the code base
• Their code will be in next prd release
• delayed by server changes
• Limited by Es time for testing etc
• Available time varies for all of us
• working on other projects
• Could accelerate project by getting more of their
  time (additional people adds startup)