D. Menasce M. Rovere

1. DEBBIE : the interface to the CMS Pixel Detector configuration DB I.N.F.N. Milano Bicocca CERN D. Menasce M. Rovere (dario.menasce@mib.infn.it) (marco.rovere@cern.ch) Overview The configuration DB and the web interface The Pixel configuration Database holds all the data necessary for calibration and initialization of the CMS Pixel Tracker detector. Given the complexity of both the detector and the corresponding configuration database tables, it has been deemed necessary to provide an interface to the system for expert users as well as un-experienced shifters. A web-based client (such as Firefox) turned out to be a good choice for several reasons discussed in detail below. Important aspects of the project include Ajax transactions between client and server, very sophisticated SVG-based graphics and extensive use of the public domain Extjsjavascript-framework to provide a desktop look-and-feel to the interface itself. The backbone is based upon Oracle. The Overall Architecture The CMS Pixel Detector consist of a barrel, arranged in three layers, and four disks in the forward-backward region for a total of over 66M channels, as shown below. An important feature of this layout is the intrinsic father and child relationship between its basic components: for e.g., a disk contains several blades, which in turn contain plaquettes, each holding about 12 ROCs (Read-Out-Chips: there are ~15k of these) and finally pixel cell elements (~66M). We leveraged upon this natural hierarchy to implement a sophisticated graphic navigation tool to allow users to locate data pertaining any possible pixel cell using at most five clicks from the highest level in the hierarchy (the whole pixel tracker). Fig. 2 shows an example of the described hierarchy, from a complete disk to the single pixel cell. A single Pixel Detector Configuration (PDC) consists in a rather complex set of data (loaded into tables of a centralized Oracledatabase), which describe the complete status of the detector at any given time. The status is a mixture of topological data (such as the electronic connections between the read-out and the detector), calibration (Readout Chip and Opto-electronic input analog levels) as well as initialization data (such as the 26 values of each ROC DAC setting to control individual chip behaviors[1]). Since individual numeric values may change over time, but not necessarily all at the same time, each component of a given configuration (called KOC, Kind-Of-Condition) is assigned, for reference, a unique numerical key as well as an alias name. A PDC is then defined as a unique recipe of KOCs: the resulting PDC is also assigned a unique numeric key (called the Global Key), an alias (a string), an author and a user-defined comment for later reference. Every item has also attached a date timestamp to it. The DB repository Our architecture relies on a DB backend (implemented by other collaborators and based upon Oracle) consisting in two instances of a DB schema, a development one and a production one (both located at CERN, the latter behind the P5 firewall in the CMS building). The DEBBIE client (browser) interacts with the DB backend by means of a C++ multithreaded server application, written in the context of the xdaq[2] framework, capable of read/write transactions with the DB, and, at the same time, acting as a web-server agent to collect users request, providing mixed-data type answers for graphical rendering on a client web-browser. The clients are regular internet browsers (such as Firefox), capable of interacting with the server by means of Ajax transactions. The transaction provides all the elements necessary for rendering of the requested data and for navigation in general. An innovative aspect of this project is the adoption of SVG[3] (Scalar Vector Graphics) images to provide interactive graphical content and of the EXTJS[4] JavaScript framework for very complex interactive widgets to display and edit large amounts of DB quantities. Being SVG a superset of XML, these images are fully scriptable and their aspect can be modified programmatically on the client side (leveraging on the Javascript interpreter of the browser itself) with a minimal amount of data interchange (highly efficient for interactivity). Implementation and Features Figure 4 shows the PDC browser: users have at their disposal, on a single page, all the tools needed to locate, inspect and modify a particular configuration in the repository. The complex widget (implemented using EXTJS) has been optimized for quick DB transactions: only as much data as fitting the current page is actually fetched and displayed (saving both network bandwidth and local JavaScript processing time). Powerful filters are in place to select configurations by numeric key, by alias (using POSIX regular expressions) or by date (thanks to a flexible calendar drop-down menu) and, finally, the columns layout is fully user customizable. The PDC browser also provides navigation buttons to further explore and edit configurations, as shown below in figure 5. Once a particular configuration key/alias has been chosen, some of its defining KOCs are loaded in the server’s memory and a navigation starting page is presented to the user (Fig. 6A, below): the navigation is organized in such a way that configuration data pertaining any component of the detector can be reached from the top level in, at most, five clicks. Upon a click an Ajax transaction is issued to the xdaq server. This, in turn, parses the request and responds to the client by sending back the required data (in a variety of formats, from plain ASCII, to XML to JSON). It is then up to the client to manipulate those data, by suitable JavaScripts uploaded to the browser along with the data in order to provide a suitable rendering (highlight some components according to their current status, apply color coded maps to graphically render data distributions or just create complex editable widgets to hold data for editing). The mixture of SVG graphics and EXTJS nested components creates an ideal environment to help users navigate across vast amounts of data with an intuitive, fully interactive, graphics interface, making wise use of network resources by local caching of data. To this extent a significant part of the code is devoted to a smart partial caching of the data server-side, since it is often necessary to fetch data chunks from the DB which are not rendered by the client for that particular request. Having them already in the cache, though, considerably speeds up navigation later on. Detector Partitioning During calibration and even physics data runs, it is sometimes necessary to set specific parts of the detector into particular states, such as noInit (do not even initialize the ROCs pertaining to the specified partition) or to noHits (initialize the detector and turn the bias on, but do not read-out data above threshold). The pattern of components to be set to a particular state can be pretty complex to express synthetically: in order to help users to specify such a pattern with the minimum number of steps possible, we implemented, two possibilities. The first, called hyerachical, allows users to set all the ROCs which are children of a particular component to be set to a specified state: this makes use of the father-child relationship naturally featured by the detector and implemented in a suitable container class in the xdaq server. The XML language turns out to be an optimal choice to communicate such relational data between client and server, since the syntax allows to naturally preserve such hierarchy which will be directly mapped to the underlying graphics by the rendering engine. The second, called patterned, makes use of free-form regular-expression searches on the names of the requested components, names which have been designed to reflect the complete detector’s hierarchy in their own syntax. Synoptic Views A comprehensive view of the configuration data is also available: the synoptic maps allow for point-and-click display of various data distributions geographically localized across the detector’s surface (as unfolded cylinders in the barrel’s case, or a layout of the two-sided disks, all in a single page). Topological maps The detector is interconnected with several intermediate electronic components: the complete connection map is graphically browsable, from a topological,instead of a geographical point of view, by means of additional synoptic views, which we called TopoMaps (one for the Forward and one for the Barrel). These maps represent the logical connection paths between all components. ROOT Histograms An important feature of the interface is the ability of handling local caches of histogram plots: users can navigate across them without need of reloading them each time. They are contained in tabbed widgets whose visibility can be easily toggled (figure 9). References [1] The control and readout systems of the CMS pixel barrel detector, D. Kotlinski et al, Nuclear Instruments and Methods in Physics Research A 565 (2006) 73–78 [2] xdaq: https://svnweb.cern.ch/trac/cmsos [3] SVG: http://www.w3.org/Graphics/SVG/ [4] EXTJS: http://www.extjs.com Fig 1. Fig 4. Fig 7. Fig 2. Fig 5. Fig 8. Fig 6. Fig 3. Fig 9. A