Andrea Valassi Pere Mato Conditions Database Andrea Valassi Pere Mato

Overview of components Framework design issues: The Algorithms need not talk directly to the CondDB. Within the Gaudi framework, CondDBSvc is the service responsible for updating the Transient Detector Store with data from the CondDB. Software responsibilities: LHCb-related issues are: CondDBSvc design and interface to CondDB; data format specification. CondDB is being developed by CERN IT division implemented in Objectivity Framework Services DetData Svc CondDB Svc DetPers Svc Algorithms Det Elem Calib Slow Conditions database Align Transient detector store

Overview of functionalities Data blocks real condition data (alignment...) + metadata (validity time, version, ...) classified in «folders» according to SD and type: e.g. /Ecal/Module1/Calib each folder contains the several data block versions for a given validity time Tagging global tags (à la CVS) identify a consistent set (1 block per validity time) e.g. «ProductionCondDB», «MyTestCondDB» Browsing of data in each folder horizontally: along the validity time axis, according to a given global tag vertically: along the version axis, for a given validity time Database management physical partitioning foreseen for different data taking years (and SD ’s?) management of database files and write/read transactions

Data identification and versioning

Open issues in the design HOW to store/retrieve condition data: framework design of CondDBSvc (independent of data type) synchronisation of Transient Detector Store used by the Algorithms detector data identification truly LHCb-specific: separation of Align/Slow/Calib or Vdet/Ecal/Hcal/Rich... general to CondDB-design: versioning over multiple validity time ranges interface and needed functionalities/features for the CondDB general to CondDB-design, involves feedback to IT WHAT to store as condition data: may be different for Alignment, Calibration, SlowControl... may vary from SubDetector to SubDetector uniform implementation: store condition data as XML strings?

Interface to IT’s CondDB Good collaboration and feedback with IT DB group Stefano Paoli, Dirk Duellmann in discussion with other experiments (Atlas, Compass...) Parallel requirement documents: from LHCb (Pere, february 2000) from IT (Stefano, june 2000) Open discussion on functionalities and interface versioning schemas over multiple time validity ranges global tag assignment database browsing database management support of multiple storable data types simple (XML strings) and complex (class instances, e.g. as Objectivity ooRef)

Plans and timescales Plans for CondDB from IT Work plan for CondDBSvc current effort on collecting our requirements first reasonable prototype could be ready in a couple of months from now Work plan for CondDBSvc use cases and requirements from SubDetectors concentrate at first on one data type: Alignment identify example SD(s) with condition data to store and algorithms to use it: Velo? design and integrate software in the framework, test on the example(s) iterate feedback to IT My personal plans... no time to work on it effectively before mid-August getting started with Gaudi at first (DetDataSvc, DetPersSvc, XML...) Summing up: prototyping of CondDBSvc around  October to December