ALICE Condition DataBase Magali Gruwé CERN PH/AIP Alice Offline week May 31 st 2005

ALICE Condition DataBase

Magali GruwéCERN PH/AIP

Alice Offline week

May 31st 2005

2 Magali Gruwé CERN PH/AIP May 31st, 2005

Outline

Introduction Current status

Reminder Very brief description of the Condition Database

Access

Remaining issues to be dealt with Feedback

Future


Status (I)

First implementation of the access classes to the condition database done and available See A. Colla’s talk

Use of the condition database access classes by detectors: ZDC: done ITS-SPD: See P. Nilsson’s talk Muon: See G. Martinez’s talk

Gathering information from other databases: Being looked at. Work to be done. See talk by P. Chochula for DCS

Alignment issues: See R. Grosso’s talk


Status (II)

May 17th : Distribution of a draft note describing the AliRoot

access classes to the condition database.

DraftAimed at describing the classes and explaining how

to use themNot supposed to be final (neither in form nor in

content)

May 20th : The AliRoot access classes are published on CVS

(implemented by Alberto Colla, following Thomas Kuhr’s first developments).

Further developments also ongoingSee Alberto’s talk


Reminder: database entry

A conditions database entry (object) is composed of: A TObject object

Detector specific and containing the data A metadata object:

Set of tags and pieces of information describing the data set, its validity and its application field

Name Run validity Version …


Reminder: data storage

Three different storage systems are considered: AliEn files:

Data are stored into ROOT files which are part of a distributed file system: AliEn

“Organized” local files:Data are stored into local ROOT files, with an

appropriate well defined directory structure and filename

Single local file:All data are stored into one single local file


Reminder: data storage

Class: AliRunDataStorage

Provides a simple interface to all run dependent data objects

Virtual interface to the database

Only one AliRunDataStorage instance at a time Could be an

AliRunDataFile (for a local file) AliRunDataOrganizedFile AliRunDataAlien (for an AliEn file)


Reminder: organized local files

Class: AliRunDataOrganizedFile

Each file is in a well defined subdirectory, defined by the metadata: [Period/]Detector/Type/DetSpecType

Each file has a well defined name, defined by the metadata: RunXXX-YYY_vV.root

XXX is the first run for which the data is validYYY is the last run for which the data is validV is the version of the data


Feedback

Many comments have been received On the concept of the classes On the implementation of the classes On the descriptive note (form and content)

Thank you to L. Aphecetche, T. Kuhr, P. Vande Vyvre, C. Holm, P.K. Skowronski, F. Carminati and B. Nilsen for their comments.

All useful. Some need clarification from our side Some will be included almost as is in next version Some require further thought and discussions


Issues/Worries/Questions

Granularity Run number Consistency checks AliRunDataStorage being a singleton Retrieved version AliEn versus local files versioning Tagging for production Run validity issue Other issues


Granularity issues

The data granularity is the run: Data varying faster than once per run should be fed

into histograms, arrays, or whatever object you fancy and stored once per run.

The LHC fill period, or beam period, tag is there for organization purpose. It is not meant for calibration data retrieving. Do we need?


Run number issue

Comment from P. Vande Vyvre: Different partitions running simultaneously, with one

run number counter for each partition After discussion, agreement was reached:

There will be a unique run number counter throughout all partitions and experiment lifetime: the run number is unique


Consistency checks issue

“What if a user renames a file in a way that two files with the same version exist for the same run?”

File names are automatically generated; version number is automatically incremented. There should be no two files with the same name in any directory.

But, to answer the question: currently the system gives an error.

However: Data should be stored in a file together with all its associated metadata. So it should always be possible to work out backwards what the filename, location and validity should actually be, in case someone messes things up.


Singleton issue (I)

Currently: AliRunDataStorage is a singleton. It can be either an AliRunDataOrganizedFile, an

AliRunDataFile or an AliRunDataAlien Problem/issue:

There is a need to have the possibility to use more than one data source (in case of testing calibrations for example):Some calibration data would come from an AliEn file

(as the production calibration file) while some other data would come from local calibration files for debugging purposes.


Singleton issue (II)

The issue is not new and has been thought about already:

Original plan (mentioned in previous talks already): Implement an AliRunDataCombination class (deriving

from AliRunDataStorage) to cover such cases.

Proposal by C. Holm (rather similar): Implement a singleton manager AliRunDataManager to

allow to have many instances of AliRunDataStorage

AliRunDataManager* runDataManager = AliRunDatamanager::Instance();runDataManager->AddStorage();runDataManager->AddStorage();…runDataManager->GetSomeData();


Retrieved version issue

Currently: “If there is no calibration or alignment data set

available with the specified version [specified, or required by the user], the highest possible (i.e. the closest preceding) version is retrieved”

More reasonable: If there are several file candidates but none

corresponding to the exact version number specified by the user, there should be an error. It is up to the user, not to an automatic procedure, to apply a recovery strategy if he wishes to.


AliEn versus local files versioning

When data is stored, new versions are automatically created (version number incremented by 1).

And, local file storage and AliEn storage are (of course) independent.

We could get:

In local files:

…/Run1_v1.root…/Run1_v2.root…/Run1_v3.root…/Run1_v4.root…/Run1_v5.root

In AliEn:

…/Run1_v1.root

…/Run1_v2.root…/Run1_v3.root


Calibration production tags

Once a set of calibration parameters has been debugged/tested, it should be “tagged” as calibration parameters for production

Production tag should probably contain information such as AliRoot version Year Cycle

A user could ask for “the production calibration parameters for all detectors for that particular run”: Different from asking for “the latest version” (which is the

default) Different from having to specify by hand which specific

version he wants for which parameter. Once more:

See Alberto Colla’s talk for current proposal


Run validity issue

Issue raised by C. Holm: Set the validity of calibration data to single run

numbers (not run ranges) It is then up to the calibration manager to look for

the closest valid calibration:“Closest” meaning:

Greatest run number, less than the reconstructed run number

Least run number, greater than the reconstructed run number

... depending on the policies chosen by

the detectors

We have to discuss that possibility amongst us…


Other issues

Naming of classes… we’ll find something better


Plans (I)

Condition Database Note: New version writing is ongoing, including:

Modifications/clarifications (where needed)Additional more general partsDescription of new classes/methods

Implementation: Comments received will be taken into account See Alberto’s talk


Plans (II)

Gathering data from “external databases”: Which data should be duplicated in the condition

database? How to access relevant data from external

databases?

Discussions are going on, first thoughts floating around…

To be continued…


Plans (III)

Detector use of the CDB: Very important to get feedback from users:

Please do try and comment on the current classes

Muon, ZDC and SPD: thank you. Now: try to get other detectors to try and comment

DataChallenge this year:We would like to check the calibration frameworkNeed detectors to participate, using the currently

proposed CDB services

Hope to get SDD starting soon Other detectors?

Hands-on session on Friday morning!!!

Documents

ALICE Condition DataBase Magali Gruwé CERN PH/AIP Alice Offline week May 31 st 2005