70 likes | 162 Views
HCAL Database Goals for 2009. M. Narain 2/17/09. Mostly developed the plans during HCAL DB workshop on 1 st February, @ CERN http://indico.cern.ch/conferenceDisplay.py?confId=51229. HCAL requests to DB group. Availability of OMDS mirror on cern.ch network
E N D
HCAL Database Goals for 2009 M. Narain 2/17/09 Mostly developed the plans during HCAL DB workshop on 1st February, @ CERN http://indico.cern.ch/conferenceDisplay.py?confId=51229
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.
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
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.
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 Bookkeeping records 5 HCAL Database Workshop
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 New data loaded 6 HCAL Database Workshop
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. • https://twiki.cern.ch/twiki/bin/view/CMS/HcalDetMonPedestalsV1 • https://twiki.cern.ch/twiki/bin/view/CMS/HcalDetMonLedLaserV1