The D0 Trigger Database: Status, and Plans

1
The D0 Trigger DatabaseStatus, and Plans

• Elizabeth Gallas
• Fermilab Computing Division /
• D0 Computing and Analysis Group

D0 Databases Taking Stock Meeting November 24,
2003
2
Trigger Database Design/Purpose

• Design reflective of Trigger system
• Three levels of decision making
• Symmetry/commonality exploited where possible
• complexity reflects trigger system complexity
• seemingly cryptic nomenclature reflective of
  trigger programming.
• Store
• all physics Trigger Lists used online in Run 2
• Bench mark Trigger Lists for Simulation
• Generate precise programming for trigger
  configuration for ONLINE and Simulation
• Trigger configuration format xml
• Extensible Markup Language (XML) universal format
  for structured docs and data on the web
• The trigger xml does not contain all the
  information stored in the trigger database,
  specifically wrt versioning, how one trigger list
  relates to another triggerlist, or descriptions.
• Report trigger configuration settings
• for use by offline analysis programs
• Et thresholds, eta ranges ...
• to the collaboration (web), with some
  documentation features
• not intended as a substitute for trigger
  subsystem documentation !

3
Trigger Database Implementation

• Implementation
• 43 Tables, 33 Views in Oracle
• 3 web based interfaces (next slide)
• 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
• Current Statistics (over 37k records)
• 226 trigger lists (1900 Triggers defined)
• single trigger list can contain 1000s of
  parameters
• 165 Trigger Lists used online in over 6000 Runs
• All data is entered by people (8 people trained)
• 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
Interfaces
http//www-d0.fnal.gov/trigger_meister/trigdb/
'SAM' type db server
5
Near Term To Do List

• Documentation
• Client methods
• Entry
• L2 Preprocessor module
• Status module allows
• Changes to Status flags
• Corrections to Descriptions
• Transformation module
• Upgrade for L2 preprocessors, L2 and L3
  tools/filters
• L1 Dialogs (L1 Cal programming)
• Report
• Neotypes and Neoterms module
• Trigger Lists Dependency
• Fix Interrelational dependencies
• Help (documentation)
• xml Generator
• Maintenance, Upgrades
• changing rules for exposure groups
• Additional programming for L2 preprocessors

6
Major New Functionality needed

• Expansion of Database/Server/Client
• Level 1 Pseudoterms
• Allows Level 1 subsystems to use true AND/OR
  logic with terms from multiple subsystems
• Involves changes to Neoterm and L1 Dialog
  programming (refset and framework bit assignment)
• Expansion in initial design relies more heavily
  on the database and database infrastructure
• Level 2 Forced Write/ Forced Unbiased
• Specifications remain incomplete
• Tying trigger lists to Releases
• Current status flags working now in the interim
• Additional changes will be needed in the
  Reporting interfaces to reflect these changes

7
Long Term To Do List

• Additional Entry/Report functions
• Implement short and long format reports
• Enable searches by date, user
• Methods for displaying differences between
  trigger elements
• Special crate parameter downloads
• Crate list downloads
• MISWEB Client
• Update as Run Summary Database
• Implementation of Rules checking
• Online downloads directly from DB
• Current ONLINE rules prohibit this
• Help / Documentation
• New methods
• L1 Simulation to Firmware mapping
• L1 Board and Board Component registry

8
Infrastructure Support

• Oracle switch to 9. -- Very smooth !
• Inconsequential error messages in export / import
  no problem, diagnosed quickly
• Database machine changes
• Production machine change
• minimal downtime
• Development machine change
• Left many utilities behind, some issues
  unresolved
• Ongoing Server infrastructure changes
• Usually dictated by changes needed for SAM
• not announced to other developers
• Thanks for continued support from Steve White and
  Anil Kumar especially in the absence of Jeremy
• Trigger Database last application using fnorb
• need time from Steve, who knows what to do
• Ongoing Trigger Database Views are slow
• Jeremy was working on Materialized Views remains
  incomplete
• code was not checked into cvs

9
Specific Requests for Help

• Continued support from the DB support group
• Steve, Anil, Diana, Nelly, Julie, Lauri
• Database (Oracle), db servers, web servers,
• ORB infrastructure
• SAM is in the process of converting from fnorb.
  This leaves Trigger_db_server as the last server
  still fnorb.
• Request that Steve White convert trigger db
  server to use omniorb
• Trigger Database Application
• Is a complex system
• Currently in operation but requires significant
  development to meet the needs of the experiment.
  One month of help from a new person does not
  help
• 3-6 months from someone who can develop new
  Trigger Application client and server modules.
• Past examples of significant contributions
• Rich Wellner original trigger db server
• John Weigand rewrote clientDemo, significant
  status flag development involving
  database/client/server
• Jeremy Simmons significant design and debugging
  help, developed the trigger database roles and
  jump started many modules still in development
• The developer can be anyone with some familiarity
  python, database and db servers

10
Trigger Database Entry Interface

• Entry Interface
• Used by experts to enter data.
• Used by anyone (on DØ) to read data.
• Currently the only interface with NEOTERM
  information (Level 1 And/Or Terms)
• Help button points to existing documentation.
• Has URL links into the Reporting Interface

11
Trigger Database Report Interface
12
Trigger Database - FAQs

• Why are there 3 interfaces ?
• there are different ways to access the database.
  Each interface has a specific function and/or
  takes advantage of the features available in that
  access mode
• Why is the TriggerDb in offline ?
• needed in offline simulator and online
• online security/access
• design requires one repository because of the use
  of name/version convention at many levels
• limited manpower
• How can I enter my own triggerlist?
• You will need assistance of a Trigger or
  Simulator Meister. They can help you
• Formulate a configuration,
• Enter it into the database
• generate/modify xml.