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

2 Magali Gruwé CERN PH/AIP May 31 st, 2005 Outline  Introduction  Current status  Reminder  Very brief description of the Condition Database Access  Remaining issues to be dealt with  Feedback  Future

3 Magali Gruwé CERN PH/AIP May 31 st, 2005 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

4 Magali Gruwé CERN PH/AIP May 31 st, 2005 Status (II)  May 17 th :  Distribution of a draft note describing the AliRoot access classes to the condition database.  Draft  Aimed at describing the classes and explaining how to use them  Not supposed to be final (neither in form nor in content)  May 20 th :  The AliRoot access classes are published on CVS (implemented by Alberto Colla, following Thomas Kuhr’s first developments).  Further developments also ongoing  See Alberto’s talk

5 Magali Gruwé CERN PH/AIP May 31 st, 2005 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  …

6 Magali Gruwé CERN PH/AIP May 31 st, 2005 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

7 Magali Gruwé CERN PH/AIP May 31 st, 2005 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)

8 Magali Gruwé CERN PH/AIP May 31 st, 2005 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 valid  YYY is the last run for which the data is valid  V is the version of the data

9 Magali Gruwé CERN PH/AIP May 31 st, 2005 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

10 Magali Gruwé CERN PH/AIP May 31 st, 2005 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

11 Magali Gruwé CERN PH/AIP May 31 st, 2005 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?

12 Magali Gruwé CERN PH/AIP May 31 st, 2005 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

13 Magali Gruwé CERN PH/AIP May 31 st, 2005 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.

14 Magali Gruwé CERN PH/AIP May 31 st, 2005 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.

15 Magali Gruwé CERN PH/AIP May 31 st, 2005 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->GetSomeData();

16 Magali Gruwé CERN PH/AIP May 31 st, 2005 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.

17 Magali Gruwé CERN PH/AIP May 31 st, 2005 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

18 Magali Gruwé CERN PH/AIP May 31 st, 2005 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

19 Magali Gruwé CERN PH/AIP May 31 st, 2005 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…

20 Magali Gruwé CERN PH/AIP May 31 st, 2005 Other issues  Naming of classes… we’ll find something better

21 Magali Gruwé CERN PH/AIP May 31 st, 2005 Plans (I)  Condition Database Note:  New version writing is ongoing, including:  Modifications/clarifications (where needed)  Additional more general parts  Description of new classes/methods  Implementation:  Comments received will be taken into account  See Alberto’s talk

22 Magali Gruwé CERN PH/AIP May 31 st, 2005 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…

23 Magali Gruwé CERN PH/AIP May 31 st, 2005 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 framework  Need detectors to participate, using the currently proposed CDB services  Hope to get SDD starting soon  Other detectors?  Hands-on session on Friday morning!!!