1 / 11

Condition/configuration db

Condition/configuration db. Demonstration using real example of the ATLAS TGC cond DB. Conclusion. Requirements from COOL: Allow us to store non-COOL tables in the same DB

ava-norman
Download Presentation

Condition/configuration db

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Condition/configuration db Demonstration using real example of the ATLAS TGC cond DB Enhancement of COOL

  2. Conclusion • Requirements from COOL: • Allow us to store non-COOL tables in the same DB • These tables will generally be static and/or have small data volume (Detector description and hierarchies as well as Configuration information) • We will be able to do joins between our tables and COOL tables • This will enable using the static tables in ATHENA in diagnostics • Have our tables maintained together with the COOL tables • Encode some payload fields as foreign keys • This will enable quick extract, e.g. for HW configuration Enhancement of COOL

  3. DB Goals • Record the time varying (HW / SW) non event data : == Conditions • Detector Configuration - used at the beginning of a run (sends about 150,000 parameters in our case) • Keep the detector structure, various constants, wiring maps etc.. • Store calibration parameters: delays, thresholds,… • Store alignment parameters • Hold the history information starting from the production through the tests, certification and commissioning • The same data is used for : • Detector operation, maintenance and diagnostics • Analysis, Calibration, Trigger simulation Enhancement of COOL

  4. Db client/server applications Requirements from condition database DCS : PVSS DAQ ATHENA is also used in online and for calibration Production Production Calibration, Offline, Online Tests Cond/Conf DB Certification Commissioning OO framework Enhancement of COOL

  5. Each path divides the detector differently (Layers, towers, 1/8th,1/12th,….) Example 1: search for all the ROI with a temperature>30 degrees Trigger DAQ CCI DCS Chambers 2 2 4 4 2 2 12, 23 Enhancement of COOL http://atlas-proj-tgc.web.cern.ch/atlas-proj-tgc/doc/CondConfDBCOOL.pdf

  6. Example: need to change the threshold (via the ps pack) for a given octant Trigger DAQ CCI DCS Chambers 2 2 4 4 2 2 12, 23 Enhancement of COOL http://atlas-proj-tgc.web.cern.ch/atlas-proj-tgc/doc/CondConfDBCOOL.pdf

  7. DB access methods • DCS : read/write directly SQL queries in the cond/conf db. The DCS which knows the exact structure of the detector gives the guideline of the structure of the db • DAQ : read/write directly SQL queries in the cond/conf db • (missing) OO/Offline/Online/calibration : need a general interface to avoid very specific user/code to directly reach the db Use of COOL tables and API is currently limited and difficult because some features are missing in COOL to solve the complexity of the problem: Example: List channel-IDs of chambers whose radiation dose in the last machine-test was > X. Enhancement of COOL

  8. dbo=DSN+user+pwd; dbrequest1="SELECT * FROM configuration where name='"+ConfName+"'"; rc1 = dbOpenConnection (dbo, conn1); if (!rc1) { rc1=dbOpenRecordset (conn1,dbrequest1,rs1); if (!rc1) { while (!rc1 && !dbEOF (rs1)) { rc1 = dbGetField (rs1, 0, oidconfiguration); // if (!rc1) DebugN("xdb: oid configuration: "+ oidconfiguration); rc1 = dbMoveNext(rs1); } } dbCloseRecordset(rs1); } dbCloseConnection(conn1); DCS : PVSS DAQ Direct SQL C++/occi Direct SQL Calibration, Offline, Online Cond/Conf DB OO framework Enhancement of COOL

  9. Possibility to declare and insert foreign key inside the tables Conditions Table Configuration Table each parameter (channel) needs his own record frequency in case of problem Channel Payload IoV Hierarchy Table • Possibility to query time, channel id (metadata) but also value (payload) Channel Enhancement of COOL

  10. DCS : PVSS DAQ Direct SQL Direct SQL OO Calibration, Online, Offline COOL Tables TGC tables COOL API Cond/Conf DB Enhancement of COOL

  11. Conclusion • Requirements from COOL: • Allow us to store non-COOL tables in the same DB • These tables will generally be static and/or have small data volume (Detector description and hierarchies as well as Configuration information) • We will be able to do joins between our tables and COOL tables • This will enable using the static tables in ATHENA in diagnostics • Have our tables maintained together with the COOL tables • Encode some payload fields as foreign keys • This will enable quick extract, e.g. for HW configuration • Otherwise we are forced to use private DB outside COOL Enhancement of COOL

More Related