May 14, 2001 E. Gallas/Trigger Database 1

Status of the Trigger Database

Elizabeth Gallas, Rich Wellner, Vicky White

Fermilab - Computing Division

See my Trigger Working Page for this talk See my Trigger Working Page for this talk and all html links in this talk !!!and all html links in this talk !!!

D0 Database Coordination meeting May 14, 2001

May 14, 2001 E. Gallas/Trigger Database 2

Overall Status

• Unlike the announcement in the collaboration meeting April 27, 2001

Trigger Database is NOT ‘almost’ done

• Scope of project - unchanged since January– making of a triggerlist outline of tasks shown late last year

• Progress has been consistent but slower than expected

• Milestones in future:– start Level 2/Level 3 testing (L3 ‘RCP’)– Level 2/Level 3 trigger lists can be formed– include Level 1. Trigger Lists for simulator.– Online programming at every trigger level– tracking of FPGA code at Level 1 and Level 2– L1 detector/simulator in step for further changes

May 14, 2001 E. Gallas/Trigger Database 3

Making of a Trigger List• Insert ‘Trigger Objects’ and their parameters

– L1, L2, L3 filter and tool objects• Insert ‘Trigger Terms’ and their parameter values

– L1 and/or terms, L2 globals, L3 filters• ‘Terms’ are combined into ‘TriggerScripts’ at each trigger level• A ‘Trigger’ = unique combination of a L1,L2andL3 ‘TriggerScript’

– A Trigger is identified by a ‘Trigger Name’ which is <16 chars to be stored on the thumbnail

• Form a ‘Trigger List’ from one or more ‘Triggers’• Enter TM terms and L1 Calorimeter refsets passed by COOR• Enter L2 object dialog passed by COOR• Versioning:

– Increment L1 NEOTERM versions • interface to guide hardware expert through a series of inserts into NEOTYPE, NEOTERM,

NT_CHANGE, L1_BOARD, and L1B_COMPONENTS tables• create new trigger list based on those NEOTERMS

– Increment L2 object or L3 filter or tool object versions• Insert L3 Stream and/or rate information• Enter prescale sets for a specific trigger list• check validity of trigger list for use online• display trigger lists • display differences between two trigger lists

May 14, 2001 E. Gallas/Trigger Database 4

TDb - issues resolved since last time• Some changes in database and loaded data since last time

– Trigger Database design passed review• contains 38 tables

• 110 storage definitions

– integration instance now exists

– cutting scripts fixed in products, ready for production

– decided to use Database triggers for STAT_USED flags• addition of database AFTER DELETE triggers (12)

– 4 currently failing

• addition of database AFTER INSERT triggers (12) – 5 currently failing

• case insensitivity - decided not to make in generic db server -- Rich implemented in tdb server Get methods -- tested in client: working well (no performance issues)

• Streaming (L3)- current implementation should work for proposed model - though mapping algorithm still unclear

• user identification in records - decided to write log file - this has been implemented entirely on client side

• a trigger_db_server running on integration instance

• many more parts of db server and client code running,tested (more iterations required than anticipated)

May 14, 2001 E. Gallas/Trigger Database 5

TDb- work in progress

• Principle goal is to get L2 and L3 into testing mode: so what’s the holdup ??– testing database triggers to populate ‘Used Status’ flags– security and how to keep the server running– To make L2/L3 trigger lists, we need client/dbserver to:

• Insert/Update/Delete - OBJECTS - done

• Insert/Update/Delete - TERMS - done

• Insert/Update/Delete - SCRIPTS - final testing, fixes

• Insert/Update/Delete - TRIGGER_NAMES - early testing

• Insert/Update/Delete - TRIGGER_LISTS -

• UPDATE of ‘Current Status’ flags -

– identify L2 and L3 testers (one tool/filter developer, one administrator) and get them d0db accounts

– Rich wrote classes to return orderly exceptions (both database and triggerDbServer) from the dbserver -- still adding to client code

– L3 needs ‘RCP’s - Rich has db_server method for producing these files and command line interface -- working on client code, need to test on command line

– Scott Snyder has XML generator (works from command line) - working on integrating a version into client code, eventually into db_server

May 14, 2001 E. Gallas/Trigger Database 6

Get Ins Upd Del StatusCurrent? - - - needed

Objects # # # # complete

Terms # # # # complete

Scripts # O O testing

Trigger Names O O O testing

Trigger Lists

L2,L3 Trigger Lists, ‘RCP’ generationNeotype O O testing

Neoterm O O testing

CalDialog

L1,L2,L3 Trigger Lists, Simulator can useXposure

CrateAtt

Prescales

Full Online Trigger Lists including crates/devicesL2 PreP

L1Boards

Full Tracking of FPGA at Level 1 and Level 2SimTrackingL1 detector/simulation in step for further changes

May 14, 2001 E. Gallas/Trigger Database 7

TDb- more work in progress• Meetings/discussion on Run Summary Database

because it’s design must be complementary to TDb– Current Interfaces to Run Summary Database

• Jeremy’s RUNCTL

http://www-d0ol.fnal.gov/run/• Elizabeth MISWEB

http://www-d0.fnal.gov/~gallas/trig/rundb_misweb.html

– Suggested Changes to keep track by RUN of • Trigger Database (exposure groups, triggers)• Streams - by Filter, determined in TDb, but TDb does not know

how many physical streams are available at run time• Crates -the list of crates must be foreign keyed in from the

CRATE Configuration Tables

http://www-d0.fnal.gov/~gallas/trig/Run_Summary.html

• Discussion on Streaming Implementation - affects– Trigger Database

– Run Summary Database

– COOR

– Luminosity Database

– DataLogger

– SAM

http://www-d0.fnal.gov/~gallas/trig/Stream_Summary.html

May 14, 2001 E. Gallas/Trigger Database 8

Trigger Database - post-testing changes

• Database changes– Identifying which L1 Terms are beam structure related

– add proper Exposure Groups and Crates and their attributes/values in the download - bring Crates in by foreign key from Run/Crate Summary Db?

– Add table for the devices, their attributes and values associated with a trigger list

– L2 preprocessor versioning and how it will be used

– L1 firmware versioning - not time critical, but talking to L1 groups to decide how it will work (CTT)

– Do we transfer L2 and L3 data from integration to production ? We can if we want to.

– Adding more ‘special attributes’

• Much entry client/server code to write/debug to be compatible with the changes listed above