1. HCAL Database Goals for 2009
M. Narain
2/17/09
Mostly developed the plans during HCAL DB workshop on 1st CERN

2. HCAL requests to DB group
Availability of OMDS mirror on cern.ch network
development database – when available?
Request heartbeat capability from PVSS for DCS info stored in OMDS. We need this functionality to spot connection problems
snapshot of DCS at the beginning of a run
. CMS Solution ? Above two requests are probably needed by all subsystems as well.
Our experience has been that ssh tunnel from cern.ch to .cms network to connect to OMDS is only successfull 20% of the time. Are there any other methods to do this? OMDS mirror would alleviate some of this
We lack a tool to "browse" the tables/views in OMDS.
I used to use WBM for that, but this functionality is lost with the new version.
Writing from offline into DBs (now only possible via .cms cluster) ? E.g. HCAL channel status evaluated offline in a automatic way, needed for both online and offline.

3. HCAL conditions Currently written directly to ORCON.
Plan to store all HCAL conditions in OMDS:
generate the appropriate tables in OMDS
write code to fill all conditions into OMDS
write PopCon code to automatically transfer the conditions into ORCON (O2O)
Revise the conditions formats in order to better meet the requirements (for CMSSW31X)
Commission ZSThresholds to store the zero suppression thresholds (until now: dummy conditions)
Commission L1TriggerObjects to store conditions associated with LUT generation
Commission ChannelStatus to store information from DQM, DCS, other sources (until now: dummy conditions)
Prepare for usage of different response corrections by trigger and offline (either make two separate formats or use labels, TBD)
Maybe store complete logical map in ORCON
Selected DCS information in ORCON/OFF for DQM

4. Online DB - Plans Integrate and test new data types:
config snippets, firmware, vme monitoring logging and TTCrx phase settings;
Recently identified additional information to be stored in OMDS.
Mostly related to DQM and Detector monitoring
Also xdaq configs schemas need to be updated or extended.
HCAL hardware mapping; Logical Map – change schema
Integrate configuration key subsystem with RCMS;
Improve data usage reporting metrics for OMDS;
Improve the read performance of DCS monitoring data as a function of RUN number and DCS map version
Store DCS configuration in OMDS
Change in DCS data format
Visualization:
Evaluate WBM to be used at the main visualization tool for HCAL OMDS info.

5. HCAL Database Workshop
Gennadiy Lukhanin
Config key management
HTR v 1
CalibRuns
Key1
RBX v 1
Floating configuration alias used by RCMS
Internal configuration key, typically auto incremented
User defined configuration data types
Run Number
Key used
Calib #1001
Key1
Bookkeeping records 5
HCAL Database Workshop

6. Config key management (cont’d)
Gennadiy Lukhanin
Config key management (cont’d)
HTR v 1
CalibRuns
Key1
Alias switches to the new key (configurable option)
Key2
RBX v 1
A new key automatically created (configurable option)
RBX v 2
Run Number
Key used
Calib #1001
Key1
Calib #1002
Key2
New data loaded 6
HCAL Database Workshop

7. Detector Monitoring Define schema/tables in OMDS
Peds : identical to that for offline reco/HLT use
Use keys to clearly separate source (global, local, orbit gap) and type (monitoring, offline etc).
LED timing, RadDam etc
Discussion for defining these already started.
Twiki based on info from being iterated with the experts. Final definitions will be available for comments, but please comment now as well.