1 / 9

Overview of BaBar Conditions Database Setup at SLAC: Federations and Data Flow Challenges

This presentation by Igor A. Gaponenko from Lawrence Berkeley National Laboratory focuses on the BaBar Conditions Database setup at SLAC. It discusses the logical arrangement of the database within the context of multiple "production" federations, including IR2, OPR, and REPRO. Each federation is responsible for specific types of conditions data, such as online calibrations and detector alignments. The talk also addresses the challenges of merging data between federations, automation of processes, and necessary synchronization mechanisms to ensure smooth operation.

doris
Télécharger la présentation

Overview of BaBar Conditions Database Setup at SLAC: Federations and Data Flow Challenges

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. The BaBar Conditions Database Setup at SLAC Igor A. Gaponenko Lawrence Berkeley National Laboratory ( IAGaponenko@LBL.Gov )

  2. Topics • This talk covers a specific setup of the BaBarConditions/DB at SLAC as of the date of this Workshop. • NOTE: The physical setup of Objectivity servers is excluded from the consideration. The accent is done on the logical layout of the database. • The multi-federations setup: • The “production” federations generate conditions data independently of each other: • IR2 • OPR, • REPRO • The “consumers” include the following federations: • Physics Analysis Federation at SLAC • users’ test federations at SLAC • federations at remote collaborations’ sites • Data flows between federations. • Some ideas on the technology which we use to split/assemble the conditions of multiple federations: • copy tools • merge tools • Problems…things2Do... Igor A. Gaponenko: The BaBar Conditions Database Setup at SLAC

  3. The Role of Federations • The role of each “production” federation (the type of data it owns/generates): • IR2 Federation • online calibrations • other conditions under which the events are taken • OPR Federation • detector alignments • original “Rolling Calibration” constants • REPRO Federation • updated “Rolling Calibration” constants • Each of these federations is “responsible” for managing of its own set of conditions. • See the tables on the next pages... • Other “consumer” federations have: • a superposition of all conditions data produced in the previous three federations Igor A. Gaponenko: The BaBar Conditions Database Setup at SLAC

  4. Statistics: Containers Igor A. Gaponenko: The BaBar Conditions Database Setup at SLAC

  5. Statistics: Databases (from OPR) Igor A. Gaponenko: The BaBar Conditions Database Setup at SLAC

  6. Data Flows between Federations copy copy IR2 OPR ANALBOOT2 copy copy & merge copy & merge copy into other federations REPRO Igor A. Gaponenko: The BaBar Conditions Database Setup at SLAC

  7. Application Application IR2 OPR DBID Number Link Index Object Object Index Link 1024 copy Read-Only Area 512 ooRef “link” copy 64K Read-Only Area 0 16 Igor A. Gaponenko: The BaBar Conditions Database Setup at SLAC

  8. Merge Tool Merge Tool Application Application OPR REPRO DBID Number Link Index Object Object Index Link 1536 2:read 3:merge 1:copy Read-Only Area 1024 3:merge 2:read 1:copy 64K Read-Only Area 0 16 Igor A. Gaponenko: The BaBar Conditions Database Setup at SLAC

  9. Problems…Things2Do • The merging of data between OPR and REPRO needs to be fully automated. • The basic tools are already in place. • But the synchronization mechanisms needed to run these tools are still required. They (mechanisms) are different for: • OPR to REPRO: • The solution is more or less trivial: use the bookkeeping information about the last operation stored in ORACLE database. • REPRO to OPR: • Trivial approaches do not work. The merging must “keep the pace” with the reprocessing using the lists of re-processed runs or something equivalent. • This work is in progress. Igor A. Gaponenko: The BaBar Conditions Database Setup at SLAC

More Related