Top

ROME was designed to be a general purpose framework for event based data analysis. This kind of analysis is typical for physics experiment, especially in particle physics.

Overview

What experimenters want to do is to analyze data for extracting physics results. However, in reality, we need to learn a lot for programming and need to write many code to implement something not directly for analysis (e.g., reading files, access the online system, creating data structure...)

The aim of ROME is to automatically generate code as much as possible for reducing the amount of manual programming by users.

In the ROME environment, users describe the design of the project (task structure, data structure, list of histograms and output files and so on) in a simple way in an XML file. ROME generates a complete set of files which can be compiled and used immediately. Starting from the complete set, users can implement the actual analysis algorithms in pre-defined functions. For the visualization, users can put ROOT GUI elements into the pre-defined graphical windows.

For the execution, the behavior of a executable can be steered with using a configuration XML file. Analysis is done with combining data and calibration database. The programming for reading XML and the database is done automatically by ROME (no manual coding is needed.) For MIDAS data format, the code for decoding online/offline data is also generated by ROME.

Universality

The framework should be usable by as many experiments as possible. Therefore, the framework must be experiment independent. There are some features like processing an event loop, which are the same for all kinds of these experiments. The implementation of these features can be completely experiment independent. But, a framework containing only this functionality, could only cover a small percentage of the requirements on a usual framework. However, the structure of a data analysis framework can be easily summarized. Out of such a summarization the code of a hole framework can be generated. The generated framework contains now all experiment specific features, like reading or storing data, accessing a data base, connecting to an online experiment and so on. The only part, that is still missing is the physics, thus, the calculations, which shall be performed on the data. This part can of course not be summarized.

Implementation in ROME

For the summarization of the structure of the data analysis framework, ROME uses an ASCII format XML. The XML file containing the summarization is called the framework definition file. It describes all the objects inside the desired framework. The structure of such a framework definition file is described in detail in the XML Definition File section of the users guide. A translation program called the ROMEBuilder translates this information into C++ classes. It also compiles and links this classes together, generates an executable and a documentation of the generated framework. Of course the generated program is a plain framework not doing any calculations. Therefore, the experimenter has to add then code to the pre-defined event functions. Only after this step and rerunning the ROMEBuilder a useful program will be generated. Please visit the 'Download and quick-start' page for a step by step instruction of building a framework with ROME.

Modularity

The framework should consist of exchangeable modules containing one step of the analysis. A module should be independent of all other modules and have a well defined interface. The interface should be the only connection to other modules. This way modules with the same interface can always be exchanged. It should also be possible to structure the modules.

Implementation in ROME

The modules inside ROME are ROOT tasks. ROOT tasks fulfill all requests mentioned above. The interface of the tasks are ROME folders. ROME folders are ROOT storage objects. These are the object where memory data is stored in, and they are the only ones. Therefore, the interface of the tasks are the data storage objects of ROME. This allows a maximum of flexibility.

Object oriented

The framework should deal only with objects, not with single or array of values. Furthermore, the objects should, whenever possible, match real objects (like sub detector components). An object naturally connects values, which belong together.

Implementation in ROME

ROME knows the following objects : tasks, folders, histograms, trees, steering parameters and midas banks. For a description of these objects, please visit the Objects in ROME section of the users guide. The usage of these objects is, inside certain guidelines, up to the user. However, using this objects ensures a minimum of object orientation.

User friendliness

The experimenter should write as less code as possible. Moreover, user code should also be as simple as possible. As discussed above, the experimenter should only need to write the physical calculation code. This is simple code which only needs basic syntax of a programming language. Writing C++ classes is not a simple job, this should be handled by the framework.

Implementation in ROME

Everything mentioned under 'Universality' contributes to a user friendly environment, since a lot of code is generated by the ROMEBuilder. The fact that the experimenter only has to add code to pre-defined event methods, ensures that the user code is as simple as possible, concerning the programming language syntax.

ROOT based

ROME is written in C++ and it is completely object oriented. It runs under Linux and Mac. It uses the ROOT libraries to perform the data analysis, the MIDAS library to collect data online and the MySQL (or MariaDB) or Sqlite3 library for SQL database access.

(Matthias Schneebeli), Ryu Sawada

e-mail: ryu.sawada@cern.ch