1. Configuration Database David Forrest 15th January 2009 CM23, HIT, Harbin

2. Contents Scope Design Concepts Implementation Remote Access Way Forward

3. Scope Configuration Database By configuration I mean everything that is related to the geometry of all components, and the calibration and cabling of sub detectors useful for reconstructing the conditions of a run Plus a wee bit of metadata associated with a run There should be very little overlap with DAQ etc

4. Design Concepts (1) Since CM22 a note has been written with some detailed draft of the design. This is intended in parts to inform and to prompt into action. There remains a clear need for more information from subdetector groups on what they anticipate requiring access to. You don’t have to be infallible, or a database expert (or know anything at all about databases) http://mice.iit.edu/micenotes/public/pdf/MICE0 228/MICE0228.pdf I provide this link here free of charge, all I ask for in return is feedback http://mice.iit.edu/micenotes/public/pdf/MICE0 228/MICE0228.pdf

5. Design for an Alien Spacecraft

6. Design Concepts (3) The point is, there is something called a ‘Run’. A run includes some meta data and has one or more configurations A configuration is the geometry (position, dimensions, rotation, etc) + Calibrations for detectors (not all shown here) + Cabling information

7. Design Concepts (4) So a run has a configuration, and many calibrations and cablings for each subdetector I need to know what form the calibrations take. For example I understand that each PMT in the TOF will have some vector of no more than ten floating point numbers, Malcolm has info re: tracker Would love to hear more from people, particularly regards other detectors

8. Design (5) : Temporal Access Use Case: “Give me a configuration for a specific time” There may be more than one configuration relevant for a given time Imagine a calibration valid only in May but improved later in July. We now have two calibrations valid for May (VALID TIME) Default behaviour – take the one that was updated the most recently, whilst maintaining the ability to view the old one (indexed by TRANSACTION TIME) So we have two timestamps: Valid time and transaction time This kind of idea is stolen from temporal databases and attached to relational, our db management system is well suited for this.

9. Implementation - I have scripts which generate the database structure and I make throwaway databases hosted at RAL for development, resembling that in slide 5 - The database is ‘relational’ and implemented using PostgreSQL 8.3 (open source) - There are access accounts for myself, Malcolm, Paul Kyberd and G4MICE

10. Remote Access We want to be able to reconstruct configurations in G4MICE Code has been written to read and write from the database from behind RAL firewall, has worked, awaiting some action by RAL to open a port for proper remote access using virtually identical program G4MICE application in development (awaiting RAL opening of port) to load VLPC data into G4MICE

11. Remote Access (2) - Access will need to support a variety of users with different versions of G4MICE and associated libraries. - There may be some version of G4MICE on the Grid, some other on my laptop, some other on yours, software in the control room etc etc - If something significant changes about the structure of the database I would rather not have to change code in all those places - In addition, it is not feasible to give RAL firewall access to all these addresses - So I imagine this being done through an API

12. Remote Access (3) (envisioned) RAL Firewall Grid Users DB API DB G4MICE Dev Control Room Apps* *Automatic Recording processes in the control room. Obviously has firewall access already. Direct access could be arranged. May also include Tom Roberts’ GUI

13. Future Work I want to read and write full geometries in the database using G4MICE I would like to hear even the most seemingly obvious things from det groups. Have heard something from TOF and Tracker but more appreciated