• Started on: 2007-07-01
• Field area: High Energy Physics
• Cientific coordenator:
• funding:
• url: http://www.sim.fc.ul.pt/sim_pt/ATLAS_projectos

The project team has a long-standing collaboration in the Trigger and DAQ system for the ATLAS experiment. Our continuous participation has accumulated expertise, understanding and deep involvement in the problems and challenges facing the ATLAS TDAQ, in particular in what relates to the database systems technologies. This work is complemented by efforts on the FLT electronics and the online alignment procedures relevant for the HLT.

The main tasks that reflect our responsibilities are:

1. Within the Monitoring and Configurations groups, the official support and extension of the interface for the storage at the central conditions databases of the information available online - ONASIC and ONASIC2.
2. Within the Monitoring group, the development finalization, the deployment and the support for the visualization tool for the ATLAS monitoring DB archive: NODE.
3. Within the FLT electronics group, the continuation of the deployment and testing of the programing electronics of the routing module for the ATLAS central trigger processors.
4. Within the Inner Detector and HLT communities, the continuing development and deployment of the ATLAS/ID calibration streams for TDAQ facilities.
5. Within the online Database group, the further consolidation of the group´s tool for object embedding and visualization tools for LCG/COOL databases: TIDB.

This project concentrates the Portuguese efforts associated with the collaboration in the ATLAS TDAQ system. It was felt that a separate evaluation of the different components of the collaboration with ATLAS would increase the dynamism of the different teams while avoiding the possible conflicts in deciding on the sharing of resources.

The team includes several students that have been with us for several years.

The Time-based Instrumental DataBase (TIDB) is an Application Programming Interface which developed from the the expertise gathered with the creation and operation of a Conditions database interface. The TIDB core provides the main interface for managing time-oriented data, and its functionalities are implemented by a collection of purposely-developed runtime plug-ins which are loaded on-demand. These plugins are comprised of two sets, one for database interaction and another for special object interaction. The first set implements the database backend abstraction layer, to allow a seamless integration with the LCG/COOL database backends as well as other commercial and open-source database interfaces such as Oracle, MySQL and PostgreSQL, as well as the implementation of object Interval of Validity and of table name hierarchy. The second plugin set provides the means to interact with special objects (such as ROOT histograms or OKS database objects) stored as Binary Large Objects in the database backend. The TIDB plugin set gives access to very useful funcionalities, such as table schema evolution or special object streams (which allow object readout and automatic filling of homonym database table fields).

The TIDB library is available as a C++ API, also with C and Fortran interfaces, with very minimal compilation and linkage requirements; a basic ROOT interface implementation is also available. It is the basis of several of our projects described throughout this Report and that have gathered significant interest within the TDAQ community, namely: ONASIC, OKS2COOL, DBStressor, KTIDBExplorer and NODE. The first four have already been tested and deployed, and the fifth project is under development.

Our group is responsible for the maintenance and setup of the ATLAS Oracle COOL databases where both Conditions and Configurations data is stored.

Since the integration or both ONASIC and OKS2COOL in the TDAQ s/w releases, the following technical runs have produce large amounts of data stored in these databases.

A testbench to evaluate ATLAS database infrastructure is now fully functional, using the DBStressor set of tools which has been ran on LXSHARE cluster for the ATLAS production and Integration databases, As DBStressor is now been fully extended to support a generic test bench facility for both LCG/COOL and TIDB2 (Oracle, MySQL, LCG/COOL, PostGresSQL) read accesses, the evaluation of the core module of our main applicatons will be undergoing.

Along with the evaluation being made on the ATLAS Point1 infrasctructure, we have succefully completed the setup of a testbed based on one private host running Scientific Linux 4.5 (syncronized with both LXSHARE and ATLAS P1 clusters) and which periodically checks out the source code of all TDAQ packages and then builds localy the realese, by compiling all the packages using CMT tools. This will allow to sistematicly prepare an image file with all TDAQ up to date s/w for deploying on the GRIDPT cluster resource, making therefore possible to run evaluation tests in esclusive mode more frequently.

Since June 2006 we are developing the software package "InDetAlignStream", which will allow the selection and gathering of all the information needed to compute the first alignment/calibration contants -- i.e., the Inner Detecter Alignment and Calibration Stream. This software will process the Express Stream, which successively looks for tracks suitable for the alignment requirements, builds a list of ROBs with hit information from this tracks, passes the track list to EventFilter (EF) for partial event building, and writes to stream.

All this chain was tested in the recent Full Dress Rehearsal 1 (FDR1) with excellent results.

The TDAQ Monitoring Working Group (MWG) is developing and testing the Monitoring Data Archive (MDA), a framework to archive the ROOT histograms generated by the TDAQ Online software. Our team has taken the task to provide the MWG with a graphical tool to display the histograms stored by MDA. To this effect, we have chosen KTIDBExplorer as the implementation basis for the histogram display tool, the oNline Objects extended Database browsEr (NODE). KTIDBExplorer uses Qt for implementing its graphical user interface and the TIDB2 application programming interface which we develop and maintain. TIDB2's ability to connect to COOL databases also makes NODE a tool to navigate the contents of those databases.

We have implemented a plugin set for TIDB2 and KTIDBExplorer as the means to develop the interaction with the MDA. This system was tested on its storage functionality since the latest Milestone M5 general TDAQ tests in early November 2007, but is still lacking a functional application interface with which we can interact. However, we have already implemented a TIDB2/KTIDBExplorer plugin set to interact with the CASTOR file storage infrastructure which will be used by MDA for offline histogram archival.

ONASIC has been completely and successfully migrated, deployed and evaluated into ONASIC2, now using TIDB2 as a middle layer.

This task also implied a follow up through written documentation, tutorials and several meetings done to approach the users to this tool.

After which, the development of the onasic on the fly configuration has been studied and developed to meet directly the sub-detectors needs.

The full deployment of ONASIC2 has been done for the ATLAS TDAQ Technical run of Jan/2008 where onasic_oks2cool has been setup as a service within the initial TDAQ partition, for which, previously we've performed a exhaustive code review making onasic_oks2cool a safe application to be a central service in the tdaq core infrastructure.

Regarding OKS2COOL, as with ONASIC, it has also been migrated into OKS2COOL2 now using TIDB2 as a middle layer, and integrated in the tdaq initial partition infrastructure. It has been succefully used on the ATLAS Technical runs since Jan/08. Since then, also some important performance enhancements have been made, increasing OKS2COOL2' relyability.

Main future plans are:

1. The development of a more complete and wide configuration of the ONASIC2 application from the Online Configurations Database via DAL(Direct Access Library)
2. The joint development with KTIDBExplorer of a proper visualization plug in for the IS Complex Objects.
3. For the OKS2COOL2 the reverse interface, COOL2OKS has now became needed, and it's design will include some enhancements of the OKS2COOL2 database organization to cope with the database size increase with avoiding future scalability issues.

The integrations of our team in the ATLAS Trigger Algorithms Performance and Menus group (TAPM) was sucessfully accomplished by joining the B physics trigger group. Within this workgroup, the channel proposed to study was the B mesons decay into a and those to a electron-positron pair (). As for the trigger system, the selection of such events is performed on the second and third trigger levels, called HIgh Level Trigger (HLT) wich are only software based (opposite to the first level (L1) wich is hardware based) and are respectively called Level 2 (L2) and Event Filter (EF). There was a study for the L2 previously done wich pointed out the main variables needed to be tuned. This algorithm consisted on the verification of a single muon with GeV from L1, and later on a second stage, a electron pair tracks selection if perform on the electromagnetic calorimeter for matching the mass (among other cuts performed in the mean steps). For the event filter, an analysis for defining the variables to be tuned is being carried out, and for such, a large amount of data is needed to be reconstructed so that the statistical error can be acceptable. For performing such a heavy event reconstruction effort, a GRID approach is also being studied.