Proposal to bring Conditions DB into the LCG Applications area scope
Date: 7th May 2003
Version: 0.0
Status: Final
Editor: Pere Mato/CERN
1. Introduction
This is a proposal for discussion to bring the already ongoing Conditions Database activities and future ones into the LCG applications area scope. The idea is that the contents of this proposal will be presented to the LHC experiments for discussion and and to SC2 committee for approval.
Under the category of detector conditions data we designate all the data needed by the event processing applications related to the conditions to the experiment that are, in general, time varying. In addition to have a time validity interval associated to each piece of data, each data item may be available under different versions. Examples of detector conditions are: detector calibration, detector alignment, detector geometry, environmental parameters such as temperature, pressure (slow control), readout conditions, accelerator conditions, etc.
It seems natural due to the characteristics of the conditions data and the expected access patterns that we think in terms of a database technology to implement the persistent repository of conditions data. This is why we refer it as the Conditions DB.
2. Motivation
Three years ago a collaboration started between IT/DB group at CERN and the ATLAS and LHCb experiments to define a common interface for a “detector conditions database” and to provide an initial implementation of it[1]. The database interface (implementation independent) was defined in collaboration with IT/DB and the experiments. And, the initial implementation based on Objectivity was delivered. Last year, an implementation of the same interface set was developed again by IT/DB using Oracle. More recently, the experiment control system projects (ECS) from the LHC experiments in the framework of the joint JCOP project have shown a lot of interest by the Conditions DB as being the natural bridge to communicate time varying information (slow control parameters) from the online system to the offline data processing applications such as reconstruction, analysis programs. New implementations of the same set of interfaces are appearing (eg. MySQL) and proposals to evolve the interfaces to be more adequate for slow control applications are also under discussion.
There is a clear need to coordinate all these activities around the conditions database. If the common interfaces can be maintained will allow the experiments to share, not only the implementation of the database itself, but also the tools needed to manage, export and distribute the databases or slices of them to worldwide computing grid.
3. POOL Work Package Proposal
The proposal is to create a project context where the people from the different experiments (online and offline) can specify the requirements and the people providing implementations and tools around the Conditions DB can discuss and agree a common programme of work. The idea is not to create an independent LCG project but to create a new work package in the Persistency Project (POOL). The relations between the conditions data and the hybrid object persistency solution in development in POOL are obvious. It may even happen that the implementation used for the Conditions DB is based on big fractions of the POOL solution currently in development. The integration of the solution into the experiment application frameworks will be certainly facilitated if the Conditions DB activities are done in the context of the LCG applications area and re-using foundation and core services and using the available common software development infrastructure. In any case, it makes a lot of sense to develop the management tools around the conditions DB, which the development effort should not be underestimated, in common with all the LHC experiments.
3.1 Scope and Objectives
The objective is the development of the repository (database) of all time varying information with versioning and tagging capabilities. It may be required to have more than just one implementation available, each one adapted to be used in different running environments (disconnected local laptop, collaboration production centre, etc.). In addition, the work package should specify and develop at set of tools that should facilitate the management and distribution of conditions data.
Helping in the integration of the conditions DB into experiment offline software frameworks and in the experiment control systems should also be in the scope of the work package. On the contrary, running the conditions database service should not be in the work package scope.
3.2 Deliverables and Schedule
Here are some ideas of possible deliverables for the work package:
§ Conditions DB interface specifications document.
§ Database implementations using various technologies (MySQL, Oracle, etc,). Libraries implementing the agreed API which can be used directly in experiment applications. Adoption of existing implementations under the LCG umbrella.
§ Bindings to scripting tools like Python.
§ Conditions DB editor/browser to allow users to browse and modify the conditions database.
§ Conditions DB management tool to allow experiment calibration managers to perform management actions such as purge old versions, split data items, tag versions, re-locate conditions to physical files, etc.
§ Conditions DB replicator and slicer tools to allow production managers to replicate the totality or slices (by time, by version or by item) of the database into production centres and keep them synchronized.
§ Interface to the supervisory control and data acquisition system (SCADA) to be able to populate the database with slow control information.
§ Etc.
The schedule for the delivery of each of these example items should be discussed and agreed among the experiments based on their priorities.
3.3 Resources and Organization
The work package should be started immediately as soon as the experiments and the SC2 committee agree with this proposal.
The existing people from the various experiments and support groups working currently in Condition DB activities should be integrated in the proposed work package. It is important to ensure participation from both the offline and online experiment projects to minimize duplication of effort and establish good communication between projects.
One work package leader devoting a big fraction of his time is required to coordinate the work package itself and to interact to the POOL project leader.
OrganisationCERN – LCG Project / Title/Subject
Condition DB Proposal / Number
Owner / Approved by / Date 15/05/2003 / Version / Page 1
[1] http://wwwdb.web.cern.ch/wwwdb/objectivity/docs/conditionsdb/