Configuration Database for BaBar On-line

1. Configuration Database for BaBar On-line Rainer Bartoldus, Gregory Dubois-Felsmann, Yury Kolomensky, Andy Salnikovfor BaBar Computing Computing for High-Energy Physics

2. On-line Databases • Conditions database • Calibrations, geometry, alignment, etc. • Data accessed with the event time • Ambient database (simplified conditions) • Time history of the data-taking conditions (voltages, currents, temperatures, etc.) • Part of the on-line detector control • Configuration database • Details follow • Prompt Reconstruction databases • Support for multi-node calibrations • Electronic Logbook • Etc. Computing for High-Energy Physics

3. Configuration DB Requirements • Support configuration of the on-line hardware and software when data taking starts • Provide a way to reconstruct exact configuration used for any run taken in the past • Support both standard data taking with the full BaBar on-line and standalone subsystems running on their test-stands Computing for High-Energy Physics

4. Configuration Data • Configuration database keeps configuration data - detector and software settings for data taking • Run type dependent • E.g. physics vs. cosmics vs. calibration data taking • Accessed by some run ID (run number) • In general makes sense only during data taking, not well defined outside runs • Compare to conditions database with time-indexed data • Examples of the configuration data: • Hardware settings (voltages, thresholds, etc.) • Trigger settings (cuts, lines, etc.) Computing for High-Energy Physics

5. Configuration Objects • “Atom” of the configuration database: • Unit of management • Keeps related data, usually data to configure particular piece of hardware or software • Every configuration object has identity: • Class name – type of the object. • Secondary key – (optional, string) to distinguish objects of same type to be used for different purposes. • Objects of same type and secondary key share same storage (container in the database). • Configuration key – number, distinguishes different objects of the same type/secondary key, similar to version. • Once created objects never change. Computing for High-Energy Physics

6. Configuration Maps • Complete configuration is a potentially big set of all configuration objects needed to setup DAQ system. • Need to organize them to be able to treat as a single entity. • Configuration map – container object which has named links to configuration objects and/or other maps. Configuration maps are also configuration objects. • Maps are used to build configuration trees. Complete configuration is a single tree identified by the ID of its root configuration map. Computing for High-Energy Physics

7. Configuration Trees • Complete configuration is a single configuration tree and is identified by the ID of the root map object. • There is a number of active configuration trees, e.g. one tree is used for physics data taking, another for cosmics, etc. • Configuration trees can overlap, e.g. EMC configuration could be the same for both physics and cosmics. • Every object in the tree is identified also by its path name (e.g. /Dch/DchCalCycles) • See simple example on next slide. Computing for High-Energy Physics

8. Configuration Tree Example Computing for High-Energy Physics

9. Accessing Objects in a Tree • Given the root of the configuration tree clients can navigate to the specific configuration object using its path name. • On-line Run Control distributes the tree root ID to every participating DAQ entity. • There is a special configuration map which translates run type names (such as PHYSICS, COSMICS, etc.) to the corresponding tree roots. This runtype map is used by Run Control to obtain tree root ID for every run (see next slide) Computing for High-Energy Physics

10. Runtype Map Computing for High-Energy Physics

11. Building Configuration Trees • Configuration trees could be arbitrarily complex and they also evolve and change in time. Complicated by the fact that existing trees do not change, for every change new trees have to be built. • Parallel structure serving as a template for building trees, less restrictive (it can change), made with meaningful names, not numbers. These template trees are called alias trees. • Users do not modify configuration trees directly, all modifications are made to the alias trees. Special procedure exist to bring configuration trees up-to-date with the alias trees. Computing for High-Energy Physics

12. Alias Tree Structure Computing for High-Energy Physics

13. Implementation • Rather strict requirements on the quality of implementation: • Number of clients – order of 100. • Many clients accessing configuration data simultaneously during “configure” transition. • Part of the DAQ system, works in real-time environment. • Currently there is one implementation, built on top of the Objectivity/DB ODBMS. Features which are important for implementation: • Direct addressing of persistent objects, no SQL-like queries. • Support for inter-object associations. • Mapping to C++ classes. Computing for High-Energy Physics

14. Implementation (continued) • “BaBar standard” approach for persistent data accessed from a Framework code: • Persistent/transient separation, hides storage technology and details from client code. There is a transient class for each (or few) persistent. • “Proxy dictionary” used to access the data, proxies are responsible for locating persistent object in the database and converting it into transient representation. • Some clients have no direct access to persistent services (e.g. those in VME). There is an additional service built for these clients which uses “Reverse Dataflow” to ship configuration data to them. Computing for High-Energy Physics

15. Configuration Tools & Utilities • Two common tasks: • Create new configuration objects (leaves of the trees) • Build or modify configuration trees • Each type of leaf configuration objects is created with the dedicated utility, data are usually loaded from external sources (files). • Two utilities to control every aspect of the configuration and alias trees: • Command-line tool with the simple command language, can be easily used from scripts. • GUI tool (based on Qt/X11) with more intuitive interface, best for less experienced users. Computing for High-Energy Physics

16. CfgExplorer GUI Computing for High-Energy Physics

17. Conclusion • BaBar designed and implemented configuration database for its on-line system, which provides configuration services for the components of DAQ. • Configuration database successfully operates since the beginning of data taking in 1999, with minor modifications and additions later. • Current implementation is based on Objectivity/DB ODBMS. • Configuration database is a vital part of the BaBar DAQ system and proved to be sufficiently performant and reliable. Computing for High-Energy Physics