1 / 8

The D0 Trigger & Runs Database Status

The D0 Trigger & Runs Database Status. Elizabeth Gallas Fermilab Computing Division / D0 Computing and Analysis Group. D0 Database Taking Stock Meeting November 15, 2004. Trigger Database. Purpose: Create, Modify, Store and Report all D0 Trigger Configurations in Run 2

chione
Télécharger la présentation

The D0 Trigger & Runs Database Status

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. The D0 Trigger & Runs Database Status Elizabeth Gallas Fermilab Computing Division / D0 Computing and Analysis Group D0 Database Taking Stock Meeting November 15, 2004 Elizabeth_Gallas D0_Trigger_Database

  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 Elizabeth_Gallas D0_Trigger_Database

  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 over 75000 records 326 Trigger Lists (3300 Triggers defined) • single List can contain 1000s of parameters • 228 Trigger Lists used online in ~15000 Runs All data is entered by people (9 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. Elizabeth_Gallas D0_Trigger_Database

  4. 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 Elizabeth_Gallas D0_Trigger_Database

  5. 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 • streamXmlGen.py • Web based interfaces: • TDB Entry Interface (about 15 modules) ** • TDB Report Interface (about 15 modules) • TDB MISWEB Interface • Documentation • Web based html or via TDB Report Interface. Elizabeth_Gallas D0_Trigger_Database

  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 Elizabeth_Gallas D0_Trigger_Database

  7. Schedule for Maintenance, Integrity and New Functions • Enforcing system constraints • as needed • Performance Issues • as needed • Machine Issues • ??? (if needed) • 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 • Additional COOR functionality • specification dependent • configuration of secondary DAQ • specification dependent • General User use of Entry interface • 6 months • Online streaming • already consumed 5 FTE years Elizabeth_Gallas D0_Trigger_Database

  8. The Plan • Get help from CD • CD has expertise-can accelerate the project • database, • database server, • python, and • cgi • Margherita, Elizabeth • working on first items in Project schedule • learning TDB schema, business rules • learning the existing implementation • Steve • convert TriggerDbServer to omniorb • many TriggerDbServer changes to come with upcoming Schema changes • Steve, Dennis Box • look at TDB Report Interface to improve design and implementation Elizabeth_Gallas D0_Trigger_Database

More Related