1. 1 Configuration Database David Forrest University of Glasgow CM24 @ RAL :: 31 May 2009

2. 2 Configuration Database  Brief overview of the database  Updated from last time: - Geometry - Cabling - Calibrations - API - Performance  Future Work

3. 3 Overview :: Scope  The configuration database deals with cabling, calibration, geometry and set value information ONLY  Its use cases are useful for offline analysis, reconstructing the configuration of the experiment  Eg “Give me the configuration of the experiment at 19:15 on 31 st May 2009”

4. 4 Overview :: Temporal Data  Imagine uploading some calibration valid for a given month.  Store the period of validity and label this the valid time.  Then later we find a better calibration for that same valid time. We want to keep both, with the same valid time.  We also store the time the information was given to the database, which is the transaction time.  Now we can get the most up to date calibration by default, but also recall the other calibrations by meta data.  Our database is bi-temporal  Example holds for geometry (eg misalignment) and cabling also. Not currently implemented for set values.

5. 5 Overview :: API  There are many applications which will read from and write to the database  The database should not make any impositions upon their design and implementation  When something is updated it would be easier to update code in one place rather than in many places, versions, etc  So we have an API, which stands for Application Programming Interface  The API is also independent of the reading and writing applications and the database management software.  My role is not to implement all client applications but to design, implement and document the DB and API, so that any number of developers can plug their own custom applications into it

6. 6 API-2 RAL Firewall Grid Users DB API DB G4MICE Database Developer Control Room Apps

7. 7 Overview :: Implementation  We use the Postgres 8.3 Database management software  The API is a server with code written in Java using JDBC. C++ code, etc, can of course connect to it!  All the client has to do is interpret the feedback which will be of a guaranteed agreed format  I have been building the full database up incrementally, testing and prototyping as I go along. It is based at RAL, and can be accessed remotely

8. 8 Updates :: Calibrations  It has been challenging to tie down all detector groups to a calibration format  So we won’t. The idea now is to have a flexible calibration format which does not require us to know the format of a calibration in advance  Calibrations can now be a vector of values of elements of different types – double floating point number, string, boolean, integer  Meta data included + Temporal overlap

9. 9 Calibrations - 2

10. 10 Updates :: Cablings  Just getting to grips with this recently  Take detectors as roots of cabling - unless theres a good use case for the configuration DB storing detector independent cabling  Previously had a fairly loose approach  We now have detector specific cabling schemes – are these complete (so far as is related to a real use case of the config DB)?  Every component of cabling should have a unique ID, often the serial number. This is unique not only over all components of same type, but over all components. Eg so a splitter can be assigned an ID number for each channel without knowing in advance the type of device it is connecting to.

11. 11 Cablings-2 Prelim – will likely have a couple of changes to TOF, KL, and arising from implementation issues.

12. 12 Geometry

13. 13 Updates :: Set Values  I know we want:  Magnet currents (quads, dipoles); RFCC currents; diffuser thickness; decay solenoid current(s); spectrometer solenoid currents; focus coil currents; target depth & delay

14. 14 Updates :: API  The API exists now, and sits at RAL  It really should be moved to a box which is visible to everyone. Any offers?  It currently takes a geometry encoded in XML and translates that into SQL and uploads it to the database  XML is standardised and extendable, and highly recommended as a means of communicating with the API, which has good XML parsing functionality already  In an ideal world, for writing data, just send an xml file and the API knows what to do eg if its geometry, calibration, cabling etc.

15. 15 Updates :: Testing  Geometry almost fully implemented, with valid time (but not transaction time yet) and full module hierarchy  I uploaded 60+ geometries and asked typical questions about the geometry at a given time. Valid time introduces no significant slow down to Postgres. Transaction time will increase complexity only slightly  This still has to be translated from SQL response to XML, and G4MICE reconstructing the hierarchy may or may not place further obligations on the database, but current results are promising

16. 16 Current State + Future Work  Geometry prototyping is going well  Would like to upload some calibrations next  Once cablings are fully prototyped, much of the hardest work will be done  We still need people to write code which sends requests to the API and digests response (no db knowledge required)  I am mainly hoping at this collaboration meeting to better analyse the seams with other systems, eg G4MICE, control room apps, EPICS, DAQ by meeting up with JSG, Malcolm, Pierrick, and others

17. 17 Temporal but not temperamental