Condition/configuration db

7/9/2005 Enhancement of COOL 1

Condition/configuration db

Demonstration using real example of the ATLAS TGC cond DB


• Requirements from COOL:1. 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

2. Have our tables maintained together with the COOL tables

3. Encode some payload fields as foreign keys• This will enable quick extract, e.g. for HW configuration

Conclusion


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

7/9/2005 Enhancement of COOL 4Commissioning

DAQ

Calibration,Offline,Online

DCS : PVSS

Cond/Conf DB

OO framework

Db client/server applications

Requirements from condition database

ProductionTests

Certification

ProductionATHENA is also used in online and

for calibration


Trigger DAQ CCI DCS Chambers

Top TDAQ

Side

Quadrant

Octant Tower

1/24 Tower

Sector Tower

HipTW/S

SBIC

ROI

PPIC

ASD

3

3

64, 1483

17, 14, 10

6-8

0-2

Top TDAQ

Side

QuadrantROD crate

ROD

SSW

SBIC

PPIC

ASD

0-2

6-8

10, 11

Top TDAQ

Side

Quadrant

CCI/HSC

SSW

PS boardJRC

PPIC

HipT

SBIC

2

4

3

8

6

6, 8, 9

2,3

4-12

SCS

LCS

1/12 CAN bus

PS pack DCS-SPP

SBIC

ASD

AlignTemp

PPIC

HVLV

4-12

1-7

TGC Top

M wheels

1/12 wheel

1/24 wheel

1/24 Tower

Wheel Sector

Units

Detectors

W-S

ASD

I wheels

Octant

Units

Detectors

W-S

ASD

1- 7

1, 2

1, 4, 5

2

2

3

3

2

12 8

AlignTemp

2

2

4

2

12, 23

2

2

4

SCS

LCS

1/12 CAN bus

PS pack DCS-SPP

PS boardELMB, JRC

SBIC

Inner CAN bus

AlignTemp

Crate

PS board

PPIC

2

HVLV

4-12

1

0 - 4

10, 17

12

11, 27

1

M2 CAN bus

M2 board

AlignTemp

24

4

12

1

ThresholdCCMC

0-8

0-120-8

2, 3

Each path divides the detector differently (Layers, towers, 1/8th,1/12th,….)Example 1: search for all the ROI with a temperature>30 degrees

http://atlas-proj-tgc.web.cern.ch/atlas-proj-tgc/doc/CondConfDBCOOL.pdf



Trigger DAQ CCI DCS Chambers

Top TDAQ

Side

Quadrant

Octant Tower

1/24 Tower

Sector Tower

HipTW/S

SBIC

ROI

PPIC

ASD

3

3

64, 1483

17, 14, 10

6-8

0-2

Top TDAQ

Side

QuadrantROD crate

ROD

SSW

SBIC

PPIC

ASD

0-2

6-8

10, 11

Top TDAQ

Side

Quadrant

CCI/HSC

SSW

PS boardJRC

PPIC

HipT

SBIC

2

4

3

8

6

6, 8, 9

2,3

4-12

SCS

LCS

1/12 CAN bus

PS pack DCS-SPP

SBIC

ASD

AlignTemp

PPIC

HVLV

4-12

1-7

TGC Top

M wheels

1/12 wheel

1/24 wheel

1/24 Tower

Wheel Sector

Units

Detectors

W-S

ASD

I wheels

Octant

Units

Detectors

W-S

ASD

1- 7

1, 2

1, 4, 5

2

2

3

3

2

12 8

AlignTemp

2

2

4

2

12, 23

2

2

4

SCS

LCS

1/12 CAN bus

PS pack DCS-SPP

PS boardELMB, JRC

SBIC

Inner CAN bus

AlignTemp

Crate

PS board

PPIC

2

HVLV

4-12

1

0 - 4

10, 17

12

11, 27

1

M2 CAN bus

M2 board

AlignTemp

24

4

12

1

ThresholdCCMC

0-8

0-120-8

2, 3

Example: need to change the threshold (via the ps pack) for a given octant




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.


C++/occi

DAQ

Calibration,Offline,Online

DCS : PVSS

Cond/Conf DB

DirectSQL

DirectSQL

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);

OO framework


ConfigurationTable

HierarchyTableChannel

Channel

IoV

Payload

each parameter (channel) needs his

own record frequency in case of problem

•Possibility to query time, channel id (metadata) but also value (payload)

Possibility to declare and insert foreign key inside

the tables

ConditionsTable


DAQ

OOCalibration,

Online,Offline

DCS : PVSS

Cond/Conf DB

DirectSQL

DirectSQL

TGCtables

COOLTables COOL

API


• Requirements from COOL:1. 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

2. Have our tables maintained together with the COOL tables

3. 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

Conclusion

Documents

Condition/configuration db