Post on 14-Dec-2015
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
3 Magali Gruwé CERN PH/AIP May 31st, 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 31st, 2005
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
5 Magali Gruwé CERN PH/AIP May 31st, 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 31st, 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 31st, 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 31st, 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 validYYY is the last run for which the data is validV is the version of the data
9 Magali Gruwé CERN PH/AIP May 31st, 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 31st, 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 31st, 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 31st, 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 31st, 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 31st, 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 31st, 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->AddStorage();…runDataManager->GetSomeData();
16 Magali Gruwé CERN PH/AIP May 31st, 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 31st, 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 31st, 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 31st, 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 31st, 2005
Other issues
Naming of classes… we’ll find something better
21 Magali Gruwé CERN PH/AIP May 31st, 2005
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
22 Magali Gruwé CERN PH/AIP May 31st, 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 31st, 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 frameworkNeed detectors to participate, using the currently
proposed CDB services
Hope to get SDD starting soon Other detectors?
Hands-on session on Friday morning!!!