Implementing a modular framework in a conditions database explorer for ATLAS

Transcription

1 Journal of Physics: Conference Series Implementing a modular framework in a conditions database explorer for ATLAS To cite this article: J Simões et al 2008 J. Phys.: Conf. Ser View the article online for updates and enhancements. Related content - Large scale access tests and online interfaces to ATLAS conditions databases A Amorim, L Lopes, P Pereira et al. - First use of LHC Run 3 Conditions Database infrastructure for auxiliary data files in ATLAS L Aperio Bella, D Barberis, W Buttinger et al. - ATLAS offline data quality monitoring J Adelman, M Baak, N Boelaert et al. This content was downloaded from IP address on 02/03/2018 at 04:42

2 Implementing a Modular Framework in a Conditions Database Explorer for ATLAS João Simões 1, António Amorim 1, João Batista 1, Lourenco Lopes 1, Ricardo Neves 1, Paulo Pereira 1, Serguei Kolos 2 and Igor Soloviev 3 1 SIM and FCUL, University of Lisbon, Campo Grande, P Lisbon, Portugal 2 University of California, Irvine, California , USA 3 Petersburg Nuclear Physics Institute, Gatchina, St-Petersburg RU , Russia jalmeida@mail.cern.ch, Antonio.Amorim@sim.fc.ul.pt Abstract. The ATLAS conditions databases will be used to manage information of quite diverse nature and level of complexity. The usage of a relational database manager like Oracle, together with the object managers POOL and OKS developed in-house, poses special difficulties in browsing the available data while understanding its structure in a general way. This is particularly relevant for the database browser projects where it is difficult to link with the class defining libraries generated by general frameworks such as Athena. A modular approach to tackle these problems is presented here. The database infrastructure is under development using the LCG COOL infrastructure, and provides a powerful information sharing gateway upon many different systems. The nature of the stored information ranges from temporal series of simple values up to very complex objects describing the configuration of systems like ATLAS TDAQ infrastructure, including also associations to large objects managed outside of the database infrastructure. An important example of this architecture is the Online Objects Extended Database BrowsEr (NODE), which is designed to access and display all data, available in the ATLAS Monitoring Data Archive (MDA), including histograms and data tables. To deal with the special nature of the monitoring objects, a plugin from the MDA framework to the Time managed science Instrument Databases (TIDB2) is used. The database browser is extended, in particular to include operations on histograms such as display, overlap, comparisons as well as commenting and local storage. 1. Introduction With the advent of large distributed acquisition systems in HEP, the problem of sharing and accessing the data, and in particular the non-event data, became specially relevant. While specific client server solutions were developed and successfully deployed [1], the usage of relational databases [3] and commercial object databases [12] was pursued as a better solution in terms of data management, including facilities such as load sharing and transaction locking. The interfaces to relational database systems made wide usage of BLOB 1 data whose structure could only be understood by the client applications that were embedded in a particular framework. Browsing the database using a unified application that could understand, in particular, objects produced by different versions of the framework, thus becomes rather difficult. 1 Binary Large OBject. c 2008 IOP Publishing Ltd 1

3 The usage of commercial object databases, while having the advantage of making the database infrastructure aware of the object structure, had an object structure that was generally coupled to the C++ programming language, and usually required compiling code to access different objects in the database also making database browsing in general very cumbersome. While the usage of commercial object-oriented databases was generally abandoned in favor of ROOT-based [8] frameworks, relational database systems play a very important role in supporting new experiments such as ATLAS/LHC [5]. The ROOT framework development has been directed into making an important part of the object schema available to the applications, even without recompiling the client code. Object managers, like the LCG/POOL [11] that is used in ATLAS, also put a strong emphasis on managing the object schema information. On the other hand, the present relational database interfaces for conditions data, such as LCG/COOL [18], were only supposed to store simple data types or BLOB objects, thus making it more difficult to create a unified data browser for COOL. The management of generalized science objects in a relational database infrastructure was the main drive behind the motivation for the development of an interface to deploy a run-time plugin architecture to different database interfaces, including COOL, and direct connections to Oracle, MySQL and PostgreSQL. Besides mapping the usual hierarchical folder view, time interval and version tag management, the TIDB2 interface defines database fields for extended types like arrays, ROOT objects, ATLAS online configuration objects (OKS) [13] and types in other science domains. The interface plugin for the specific type provides all required object information to the client application, including the Database Browser, managing inclusively the schema evolution of the science objects that is managed by special schema evolution tables. These run-time plugins are implemented through abstract interfaces. The KTIDBExplorer general database browser was developed by making sistematic usage of the TIDB2 modular framework, keeping most of the functionality available in the database interface, instead of embedding it in the necessary complexity of a GUI application. The architecture of the KTIDBExplorer application also involves defining abstract interfaces to data presentation plugins that are invoked when TIDB2 unwraps a special science object like a ROOT histogram. This extension mechanism was extensively used in the KTIDBExplorer application that defines and implements not only abstract interfaces to connections to databases and files, but also supports extended ROOT and online configuration (OKS) objects in the database. The application is aware of the relations between database objects, allowing the exploration of associations (links). The core application, whose GUI is built on the Qt toolkit [16] C++ API version 3.3, displays the hierarchical folder view and powerful table widgets with panels for selecting the database queries. 2. Data from ATLAS Online and Offline frameworks The ATLAS online and offline framework processing chains use very diverse data formats for different purposes. It is a challenge for any interactive tool, designed to access data from both frameworks, to be aware of the object schema infrastructure. A good example to motivate the interest of providing the means for interactive database object browsing can be described as follows. Athena class persistency is assured by POOL, but the classes OIDs are stored in an Oracle-backended COOL database with file name and path. These classes are accessed by Converter services for data manipulation, therefore Athena users wishing to track down this information must handle different technologies proficiently. Another example, described more detail on section 2.4, stems from accessing online monitoring histograms, shared as online objects whose data payload is effectively stored in disk or tape filesystems. 2

4 2.1. Athena/GAUDI Athena [4] is the ATLAS framework for event processing and analysis, both prompt (online) and delayed (offline), built on the GAUDI [6] architecture kernel originally developed by CERN s LHCb experiment. As the GAUDI Athena architecture distinguishes between algorithm objects and data objects, the users develop their algorithms on top of a skeleton-based application which easily communicates and reutilizes other user code. The Athena framework internally defines the data schema through the mapping of the transient classes performed by Athena Conversion services. This schema definition resorts to the COOL interface to store simple data types or POOL OIDs. For more complex types, the POOL persistency API also provides object type introspection through ROOT I/O classes. However, the persistency media used by POOL, such as the CASTOR [9] tape management system used for offline object storage, typically have architectures that are not conceived for using in an object browser but rather as a batch job framework Online Configuration Databases The ATLAS TDAQ system is configured using the TDAQ Online Kernel Support (OKS) service, which stores the configuration data instances as XML files. In addition, the object interface provided by these databases is much more powerful than the ones from typical RDBMSs. Such infrastructure can be applied to all data that is infrequently updated during each run. For offline event reconstruction, the configuration data used online must also be known. The replication of this data for offline use is described elsewhere; see [2] for details of a solution implemented with the TIDB2 API mentioned in section 3 onward The online Control bus and the Information Service The ATLAS online software framework is the common layer for the communication between the local controller software systems belonging to the ATLAS Trigger and DAQ hardware frontends. The ATLAS Information Service (IS) [14] is the online software component used by a number of ATLAS online services (Run Control, Message Reporting System, Process Manager, Message Reporting System, Error Reporting System, etc.) to share information between applications in the distributed environment of the ATLAS TDAQ. In turn, IS runs on top of the Interprocess Communication (IPC), a CORBA implementation-independent layer to allow the communication between the services running on the online network. The IS framework provides a C++ API that allows services to exchange information with the IS repository The ATLAS Monitoring Data Archive An initial estimate [19] for the payload of the generated histogram data is o(10)gbyte/run. Concurrently, this has led to the requirement that the histogram data be collected and bundled in a way that they are available in the framework at the end of each run and archived away after a predefined time has elapsed. For this reason, the Monitoring Working Group of the ATLAS TDAQ has proposed and is developing the Monitoring Data Archive (MDA). The purpose of the MDA service is two-fold. On one hand it serves the TDAQ online infrastructure by managing the collection of all relevant Data Quality parameters and histograms pertaining to each run. The service runs as a set of online framework processes which are triggered at the end of each run. The Collection and Cache (CoCa) service is part of the MDA project and manages the archival of data from the online environment, into the CASTOR mass storage filesystem, after a specified holding time. On the other hand, the MDA service provides the TDAQ community a means to retrieve run information for analysis of the run conditions. The MDA configuration specifies the amount of time and dataset size required for archiving the data offline. 3

5 Whereas reasonably small data (such as numbers and strings) can be directly stored in a database without appreciable effect on storage performance, the histograms are not kept therein due to their big payload, but instead are stored on the online filesystem environment until a predefined Time-To-Live interval has elapsed. They are then moved to the CASTOR magnetic tape filesystem, using gigabyte-sized compressed files containing ROOT files with histograms. The MDA online database keeps histogram parameters such as the Interval of Validity (IOV), the filename of the dataset keeping the histogram, and the location of the dataset, i.e. whether it resides at the online infrastructure or was already moved to the offline infrastructure. The MDA database is instantiated both in the online and the offline infrastructure, with the populating data referring to the Monitoring data payload held by the respective infrastructure. 3. The TIDB2 Concepts The T ime managed science I nstruments Database (TIDB2) is a C++ Application Programming Interface (API) designed for time-based instrumental databases with support for science object persistence. In this sense, TIDB2 implements features also found in other science databases, particularly the C++ and SQL-free LCG/CORAL API and the time-based COOL API which is layered on top of CORAL [15]. TIDB2 shares the following features with the COOL and CORAL implementations: provisioning of a common, abstract interface to different RDBMSs such as MySQL, PostgreSQL and Oracle; organization of database tables as a folder hierarchy; replacement of SQL by a transient table for data storage and retrieval; and ability to manage objects by Interval of Validity (IOV), version and tag values. TIDB2 further extends these capabilities with additional features: a common plugin interface to manipulate extended object types in a database; automatic association of simple table columns to object parameters; management of the extended objects schema and its evolution. The TIDB2 interface can extend its capabilities by creating new plugins. Programming interface wrapper libraries for C, Fortran and ROOT Cint are also available. The ROOT Cint library binds TIDB2 tables to ROOT TTree objects. In the TIDB2 core, a table instance is defined by a row object that describes the table s schema. In turn, the rows with which the table is filled are defined by field class instances, each of these being described by a set of properties which includes the type of object to be stored a simple object such as a number of a string, or an extended object managed by a TIDB2 base class which is inherited by the implementation of the respective object handling class (e.g. array, ROOT, OKS, or Earth Sciences objects). A set of DBMS plugins classes, inheriting from a single TIDB2 core class, implements the connection with different database backends (COOL, 2 Oracle, MySQL, PostgreSQL) and conceals the SQL implementation behind a common interface. The only time the user chooses the DBMS to be used is upon creating or establishing a database connection. Concerning COOL encapsulation by TIDB2, this APIs folders and tables correspond to COOL Foldersets and Folders respectively. COOL also defines three fields two corresponding to the each record s IOV and a third, an integer, as a Channel Identifier. The TIDB2 since and till fields map COOL s IOV information, and the TIDB2 chid field used in the COOL connection plugin maps to the corresponding COOL field. 2 The COOL relational layer is implemented with the CORAL API. 4

6 TIDB2 supports the storage of tables whose schemas may incorporate IOV information for each record. In such case, TIDB2 can use its own infrastructure for managing the IOVs by default, or can use COOL when accessing a database that uses this backend. Upon the insertion of a table record i, TIDB2 assigns an IOV represented by [s i, + [, with the integer value of s i equal to the representation of the current time and the open-ended maximum t i encoded by a special value. When inserting a new value for the same object, with index i+1, the previous IOV is closed to [s i, t i [, and the new object version will be tagged with an IOV given by [s i+1, + [, with s i+1 = t i. Thus, different versions of an object can coexist in the table, each with a set of IOVs which may overlap with other objects IOVs The TIDB2 API TIDB2 s flexibility stems from its possibility to allow the creation of plugins for handling both new types of data connections as well as data types, and the use of these plugins through its inherited base classes. The most significant classes in the TIDB2 API are (see figure 1): TIDBTable, TIDBRow, TIDBField and TIDBConnection. The TIDBTable class relates to the remaining TIDB2 classes through at most one object from the generic connection class TIDBConnection, the TIDBTableAttr describing the table hierarchical position in the database folder set and the type of table (e.g. a table with IOVtagged values would have a ddtype attribute described by a tidbtableid enumerator), and an internal TIDBRow object describing the set of fields specific of this table. The class TIDBTableX inherits from TIDBTable and extends its functionality by, most notably, implementing table schema evolution. The TIDBConnection class inherits from TIDBConnectionPLG, which provides a set of virtual classes to be used as an interface for different methods implemented in specific database connection plugins (not shown in figure 1); for example, the COOL connection plugin is implemented by the TIDBConnectionCOOL class, whereas the MySQL connection plugin is implemented by TIDBConnectionMySQL. The connection plugins methods implement technology-specific query facilities for database operations such as opening or closing a database connection, creating or dropping a table, obtaining the list of available tables, etc.. Consequently, the TIDB2 API can perform the most common operations of time-based database while hiding the DBMS backend SQL structure. Additional SQL queries can be submitted through a database connection using a sql virtual method, which must be implemented in the plugin used for each specific case. The table record container is described by the TIDBRow class. Its instances contain a finite number of TIDBField instances for each data field. The type of data held by a TIDBField object is described by a TIDBBaseType, which contains the data representation and the type of data indicated by a tidbtype enumerator. In case of an extended data type, such as a ROOT object, the tidbtype enumerator indicates a special value and a TIDBTypeEx object is used instead to manipulate the BLOB. The TIDBField and TIDBRow classes also overload operators to allow insertion of extended objects to submit to databases. One of the significant features of TIDB2 is the special C++ streamer << that fills TIDBRows and processes the scientific objects as needed. This operator automatically casts the data to the appropriate type. For example, if we have the TIDBRow object MyRow, constructed from schema information of a TIDBTable object table with three integer-type columns, the following code can be used: TIDBRow MyRow(table) << 1 << "2" << 3.0; The row object could then be streamed into a TIDBTable and refilled with new data. To establish a database connection through TIDB2, the user should provide a string which 5

7 Figure 1. UML class diagram for the TIDB2 classes. To unclutter the figure, the classes members and methods were omitted, as well as the plugin classes inheriting from TIDBConnectionPLG and TIDBTypeEx; see [7] for a more detailed diagram. TIDB2 plugin mysql oracle cool cool TIDB2 connection string mysql://dbhost:dbname:username:password oracle://dbhost:dbname@dbinstance:username:password cool://oracle@dbservice:dbname:username:password cool://oracle@dbservice:dbname:schemaowner/username: Table 1. Examples of TIDB2 connections strings usable with KTIDBExplorer, for three TIDB2 database connection plugins. The use cases differ essentially by type of plugin, whose name is identified by the substring left of the :// separator. describes the connection details in the following format: dbproto : //dbserver : dbname : dbuser : passwd (1) The table 1 gives some examples of TIDB2 connection strings following format (1). The substring dbproto designates the TIDB2 plugin name (e.g. mysql in case of a MySQL database connection, or cool in case of a COOL connection) loaded by TIDB2 at runtime. The dbserver substring describes the machine name or network address of the database server. For COOL connections, dbserver has the form proto@db, with proto as the COOL backend instance (e.g. oracle) and DB as a the database backend identifier (not the hostname). The dbname substring identifies either: the database name, in the case of COOL, MySQL or PostgreSQL connections; or, in case of an Oracle connection, a string formatted as name@instance where name is the Oracle database name and instance its running instance. Finally, the dbuser and passwd are used to authenticate the client against the database server. 4. The KTIDBExplorer database browser The KTIDBExplorer application is a generic database browser for TIDB2-managed databases. Because TIDB2 can provide a backend for COOL-managed databases, KTIDBExplorer can also browse COOL databases. The GUI is implemented with Trolltech s Qt C++ toolkit, and therefore can be ported into different operating systems supported by this toolkit. The browser can use a number of specific plugins to interact with TIDBTypeEx extended objects in a TIDB2 database. If such a visualization plugin is not implemented, it falls back to using a default BLOB plugin to display the values of the TIDBTypeEx object members. Figure 3 represents the main use cases for KTIDBExplorer as a UML diagram. The browser GUI represents an hierarchy of the saved database connections and database tables. The remaining GUI space is used to display the tables contents as Qt QTable objects. KTIDBExplorer uses Qt primitives to graphically represent the objects IOVs in a TIDB2 table, as shown in figure 5. The browser natively supports the visualization of arrays through a specific visualization plugin, as well as objects created with foreign APIs such as OKS objects, ROOT histograms and objects from other scientific areas such as the GRIB format used in Earth Sciences. If the object is unhandled by KTIDBExplorer, it displays the object contents using a special blob plugin as default. 6

8 Figure 2. TIDB2 components diagram. The central TIDB2 classes are implemented in C++, and additional language components are available. The TIDB2 plugins implement the access interface to RDBMs (bottom right) and extended objects (top right). Figure 3. UML use cases diagram for KTIDBExplorer. Figure 4. The KTIDBExplorer GUI. The left pane shows the configured DB connections as a hierarchy of database technologies, servers and databases, branching into the database tables. A database connection dialog box is shown, together with an open database table and an embedded window representing an extended object from the table. Figure 5. The KTIDBExplorer GUI. For tables containing IOV-tagged objects, KTIDBExplorer can display a representation of the objects IOVs using solely Qt primitives (main area, bottom left). A ROOT histogram stored in the exhibited table is also shown, as an embedded Qt widget in its own window; the histogram drop-down menu is inherited from the respective ROOT class The KTIDBExplorer GUI development The usage of the Qt toolkit to implement the KTIDBExplorer GUI has allowed a successful porting of KTIDBExplorer from the Linux development environment into Microsoft Windows, through the Cygwin [10] framework; see figure 6. This also required porting TIDB2 to the same environment, as well as assuring the availability of the database backend client libraries (e.g. MySQL). The creation of visualization plugins is done by implementing a new class inheriting from 7

9 Figure 6. KTIDBExplorer running natively in a Microsoft Windows environment. The interface was ported using the Qt toolkit and compiled in a Cygwin framework. Figure 7. KTIDBExplorer as the basis for an implementation of the NODE GUI. The embedded Qt windows show the application of KTIDBExplorer s ROOT visualization plugin, with one ROOT TCanvas for an embedded window holding a ROOT histogram. KTIDBExplorer s KTIDBExplorerPLG class. The virtual methods of this class should be implemented for each visualization plugin, in order to allow a uniform usage of class methods to access the plugins with the browser. The plugins should resort to the TIDB2 API to extract the extended object from the corresponding TIDBTable row where they are held. For example, the ROOT plugin, which additionally inherits from the QWidget Qt class, implements the KTIDBExplorerPLG::show() method to allow the visualization of a ROOT object inheriting from the ROOT TH1 histogram class. The visualization plugins should also implement their specific Qt graphical interfaces by defining GUI-usable classes inheriting from the Qt QWidget class The NODE Monitoring Histograms Archive browser The NODE application is the browser being developed specifically to allow MDA database navigation and histogram visualization. Its implementation is based on KTIDBExplorer, mainly as a result of the underlying TIDB2 framework showing adaptability for past tasks. NODE extends KTIDBExplorer s initial functionality by also allowing a GUI for insertion and querying of histogram-related time-tagged comments. The comment-handling infrastructure of NODE was proposed and discussed, and is presently in development. NODE uses KTIDBExplorer s ROOT plugin for visualization of histograms (see figure 7). This plugin implements a Qt canvas for embedding the ROOT histogram object. Because it also inherits from ROOT classes, the ROOT canvas manipulation is available. This allows, for example, to perform simple histogram fittings using ROOT s drop-down menu items. The development of NODE has also directed the development of the KTIDBEXplorer ROOT plugin towards additional functionalities, such as setting up an histogram as reference for comparison with others, overlapping a displayed 1-dimensional histogram with a reference previously chosen, after appropriate rebinning of the reference copy, or plotting the difference between the histogram and a reference to simplify comparison. In addition, the visualization plugin allows the user to save a private copy of individual histogram objects. 8

10 5. Conclusion Many components of the ATLAS software architecture use objects of very different characteristics. This makes it difficult to design a data visualization tool that easily explores the databases and display its objects. The concise knowledge incorporated in the design of the modular TIDB2 library has produced a highly adaptable and unique tool for serving the requirements of managing time-tagged science objects databases. It becomes a matter of the developer to create the necessary plugins to allow access to different database backends and to handle the different science objects to be managed. TIDB2 s modular design ideas were also applied in its accompanying KTIDBExplorer database browser, which has a core GUI class set and ancillary extended type visualization plugins. The choice for the C++ multi-platform Qt toolkit has demonstrated that this browser can be ported to platforms other than the originally-developed Linux architecture. The actual deployment of TIDB2 and KTIDBExplorer is then dependent on the availability of an implementation of the required library backends for database access and object manipulation. We are currently using TIDB2 as an abstraction layer for database access, particularly in the interface of data storage and browsing of COOL databases. This is patent in KTIDBExplorer and a number of software projects [2] we are developing for the ATLAS TDAQ. Although KTIDBExplorer has demonstrated that it s functionally capable to be used as a COOL database browser, we intend to design and conduct a program in the near future to assess our software s intrinsic performance and scalability as well as its relation with the interfacing APIs. 6. Acknowledgement The authors gratefully acknowledge the support from their respective institutes. This work is partially funded by the portuguese Foundation for Science and Technology (FCT) grant number POCI/FP/63948/2005 and POCI/FP/81940/2007. References [1] Amorim A, Amaral V, Marconi U, Steinbeck S, Tomé A, Vagnoni V, Wolters H 2001 Computer Physics Communications [2] Amorim A, Lopes L, Pereira P, Simões J, Soloviev I, Burckhart D, Von Der Schmitt J G, Caprini M, Kolos S 2007 Proc. Int. Conf. Computing in High Energy and Nuclear Physics (CHEP2007). [3] Angelos B, Arisawa T, Harmann F, Ho N, Ikado K, Jones S, Maeshima K, Pordes R, Stadie H, Veramendi G, Wenzel H, White S, Yoh J 2000 Proc. Int. Conf. Computing in High Energy and Nuclear Physics (CHEP2000). [4] ATLAS collaboration 1995 ATLAS Computing Technical Design Report, section 3.3. Preprint: CERN/LHCC [5] ATLAS collaboration 1999 ATLAS Detector and Physics Performance Technical Design Report (vol. I). Preprint: CERN/LHCC / [6] Barrand G et al 2000 Proc. Int. Conf. Computing in High Energy and Nuclear Physics (CHEP2000). [7] Batista J, Amorim A, Brandão M, Kolos S, Neves R, Pereira P, Simões J, Zema P F 2007 Proc. 15th IEEE NPSS Real Time Conference (RT2007). [8] Brun R, Rademakers F 1996 Proc. AIHENP 96 workshop, Lausanne, Sep. 96, Nucl. Instr. Meth. Phys. A See also [9] CASTOR project homepage [10] Cygwin homepage, [11] Düllmann D 2003 Proc. Int. Conf. Computing in High Energy and Nuclear Physics (CHEP2003). [12] Gaponenko I, Brown D, Quarrie D, Frank E, Gowdy S 2000 Proc. Int. Conf. Computing in High Energy and Nuclear Physics (CHEP2000). [13] Jones R, Mapelli L, Ryabov Y, Soloviev I 1997 Proc. 10th IEEE Real Time Conference (RTI97). [14] Kolos S [15] Papadopoulos, I, Chytracek, R, Düllmann, D, Govi, G, Shapiro, Y, Xie, Z 2006 Proc. Int. Conf. Computing in High Energy and Nuclear Physics (CHEP2006). [16] Qt toolkit homepage, [17] Soloviev I 2002 ATLAS DAQ Technical Note

11 [18] Valassi A, Front D, Clemencic M, Schmidt S A, Moosbruger U 2006 Proc. Int. Conf. Computing in High Energy and Nuclear Physics (CHEP2006). [19] Zema P F 2006 CERN EDMS preprints document , version