1 / 11

Summary of first LHC logging DB meeting

Michele Floris. Summary of first LHC logging DB meeting. Outline. Joint LHC machine experiments meeting: Interfacing to the LHC logging database for postprocessing (offline analysis). Goals of this meeting: Establish a first inventory of use cases and potential users

belita
Download Presentation

Summary of first LHC logging DB meeting

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. Michele Floris Summary of first LHC logging DB meeting

  2. Outline • Joint LHC machine experiments meeting: Interfacing to the LHC logging database for postprocessing (offline analysis). • Goals of this meeting: • Establish a first inventory of use cases and potential users • Discussion on required functionality • How to continue this? • Talks: • Users (Machine + Experiments) • Logging and measurement service

  3. LHC Beam Instrumentation • Quite some development already • Want at least same feature/performance

  4. ALICE DIP DCS OCDB Post-processing/calibration should be done centrally Delay of publication? PROCESSING v1 API Logging Database raw What triggers the migration? Data format? Versions? Michele Floris

  5. ATLAS Value based queries  impossible • They also use DIP as primary data source Michele Floris

  6. CMS Michele Floris

  7. LHCb Current drawbacks • We are archiving everything on our own, including all beam and machine parameters, that we receive via DIP • advantage: we have the same access interface to ONE database • disadvantage: we always have to make sure we have everything and we clearly double the effort •  the tool should be interfaced to ANY database, each parameter or condition in the right database • We don’t have direct access to nominal settings and nominal parameters, like collimators settings, golden orbit, etc • BLM thresholds we have but we archive the whole set ourselves… • We don’t have access to the corrected and calibrated data • May also allow correlating the whole set of data with shifters’ names in experiment control room and CCC….  Federico Alessio

  8. f f FGC MK MS PIC WIC QPS ELEC TIM EAU BCT BLM BPM Cryo CIET Coll CV COMM BIC BETS Rad VAC SU Exp VAC CNGS f f f f f f f f f f f f f f f f f f f f f f f f Current Status > 300 extraction clients 0.4  2 million extraction requests per day PL/SQLfiltered data transfer 7 Days raw data ~20 Years filtered data ~ 800’000 signals ~ 300 data loading processes ~ 3.8 billion records per day ~ 105 GB per day  38 TB per year stored ~ 200’000 Signals ~ 50 data loading processes ~ 5.1 billion records per day ~ 130 GB per day  46 TB per year throughput MDB LDB Equipment – DAQ – FEC Equipment – DAQ – PLC Equipment – DAQ – PLC Forum on Interfacing to the Logging Database for Data Analysis

  9. Spring HTTP Remoting Spring HTTP Remoting TIMBER Custom Java Applications (currently > 30) 10g AS Data Extraction – Java API CERN Accelerator Logging Service MDB JDBC TS Data LDB JDBC TS Data metadata JDBC Metadata They will only provide a JAVA interface (already used by timber and some 30 applications)  We will need to implement a wrapper Forum on Interfacing to the Logging Database for Data Analysis

  10. Misc from discussion • DIP not guaranteed to be reliable (uptime < 100%) • Access to DB mandatory • 2 main use cases • Running conditions (few users, lots of data) • Direct access to logging DB • Offline analysis (many users, less data) Backfill of OCDB? • Central post-processing: commonly requested • Versions! Format? Same Logging DB? • Concurrent R/W: will also provide mirror DB? Michele Floris

  11. Most relevant variables • bunch/beam intensities • beam losses • beam positions • beam sizes (emittances) • collimator positions • some vacuum gauges • but also sporadically-measured quantities such as: • crossing angles • beta functions. Michele Floris

More Related